[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to make Debian less fragile (long and philosophical)



* Steve Willer said:

> > 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
Yes, but the pages are ro after the fixup stage?

> 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.
But all processes are children of INIT, so all of them share the code loaded
or pre-loaded at the init stage. And all the shared librarie's code which is
used by the programs is mmapped to the memory space of every executed
program, thus the processes share those segments although it might look like
they have their own copies of the code.

> 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.
You can use pre-loading to achieve that, AFAIK.

> > 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.
sash has its limitations, one of them being the limited script support -
many POSIX-compliant scripts won't run with it. Another is the lack of ar
which is needed to unpack .debs by hand. Also, sash isn't very comfortable :))

marek

Attachment: pgpWUMMye89W0.pgp
Description: PGP signature


Reply to: