> On 3 Oct 2001, Eric W. Biederman quoted:
> > > >/* The right way to map in the shared library files is MAP_COPY, which
> > > > makes a virtual copy of the data at the time of the mmap call; this
> > > > guarantees the mapped pages will be consistent even if the file is
> > > > overwritten. Some losing VM systems like Linux's lack MAP_COPY. All we
> > > > get is MAP_PRIVATE, which copies each page when it is modified; this
> > > > means if the file is overwritten, we may at some point get some pages
> > > > from the new version after starting with pages from the old version. */
> IMO it needs a slight correction.
> + /* Unfortunately, that is not an option, since losing bloatware like GNU's
> + relies heavily on equally bloated shared libraries and use of MAP_COPY
> + would eat memory with no mercy. OTOH, implementing it might be a good
> + idea, since results would force people to switch to something less obese */
Hmm. Perhaps. But if we went there we would need to add something like.
/* But finding a less obese platform to run these less obese libraries is a
challenge. Unix clones like UZI have been shown to run a complete system
including user space binaries in just 64KB of RAM, on systems
originally designed to run CPM. But today you can't find a general
purpose kernel whose binary much less it footprint fits in 256KB.
It seems bloatware is everywhere.
I have days when I'm frustrated by the size of both glibc and the
linux kernel. stripped both the linux kernel and glibc are comparable
in size. Though I think the 400KB of compressed glibc-2.1.2 is
actually smaller than the kernel for the most part. I have to strip
off practically everthing to get a useable bzImage under 400KB.
So any good ideas on how to get the size of linux down?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/