Re: how to make Debian less fragile (long and philosophical)
On Tue, 17 Aug 1999, Paul Michael Tevis wrote:
> I forget exactly how this works. Does Linux only maintain one in-memory
> copy of read-only data (i.e. the code and ro segments of an executable)?
> I know that various OS's do this, and I don't remember if linux does. If
> so, then dynamically linking won't save you any RAM, since the library
> code would be ro anyway. If not, then it might.
The problem is that the libraries aren't readonly because they in turn
have dependencies on other libraries. During the fixup stage, the loader
definitely has to write to those mmap'd locations. Looking quickly through
the source shows that ldso uses MAP_PRIVATE on the mmap call. The only way
libraries could be shared is with children, then. Forked children would
share the page no matter what because of copy-on-write, and forked+exec'd
children would presumably have the old mmap's clobbered.
It would be a neat hack if certain mmap's could be marked with something
that says "don't clobber me on an exec", the pointers could be kept in a
cache somehow. That would allow libraries like libc to be truly shared
among children.
Maybe it does it already. I dunno. It's interesting, regardless.
> More importantly, I think most of us following this thread have come to
> the conclusion that static linking is something that some people would
> very much like to do, and probably for good reason. Making that
> possible/easy would definitely make Debian more robust and widely
> deployable, which is a Good Thing (at least in the eyes of most of the
> people on this list).
I'm definitely on the "static build" side, although the existence of sash
alleviates the issue somewhat (I didn't know about it before). However, I
don't know that any "side" can claim to speak for "most of the list" at
this point.
Reply to: