[222] in Release_Engineering
Re: Notes for a Proposal for a shared global library on the IBM RT/PC.
chariot@ATHENA.MIT.EDU (chariot@ATHENA.MIT.EDU)
Mon Aug 22 14:52:42 1988
The proposal above is *much* more complicated than strictly
necessary for the purposes the shared libary would be used for. My
original purpose goes more like this:
Reserve one segment of virtual memory for the library. It is
read-only and contains the library contents which are loaded in at
kernel boot time (there are any number of ways of doing this without
using another system call). All the executables on the system packs
(and ONLY those executables) are linked not with the standard libraries
but instead with "stub" libraries which contain only the read-write
"things" of the libraries and the address of the read-only "things" in
the library. ("things" means variable/function/...)
This is all that needs to be done. Note that no symbol tables
are required either for the executables or the library. Note also that
no new magic numbers are required. Also, execution speed will be
greatly increased for two reasons. One: load time is much faster
due to smaller executable size. Two: since the library is now being
shared, multiple copies are not needed which means less paging to keep
the smaller working set in memory.
Needless to say, this proposal has one major disadvantage over
the more elaborite proposal: In order for the executables to run without
core dumping, they must have been compiled with the library of the
current kernel. I.e., a 6.0A pack binary will crash on a machine
running a 6.0B kernel. HOWEVER, this is not a disadvantage if kernels
and packs are always released in sync (this is supposably the case...)
and only binaries on the packs are compilied to take advantage of the
library. Since this hack really exists only for the purpose of saving
space on the packs and root, this is not a limitation.
This does mean, however, that users will be unable to get the
space/speed savings of using the library. Tough luck. The reason for
prefering this proposal over the more elorobite one is the KISS
principal, pure and simple. Trying to deal with symbol tables and jump
tables, major kernel hacking and new magic numbers just for a temporary
1-2 year hack is not worth it for the marginal benifits. More anyone
implements the more elorobite proposal I would like some good arguments
why the above proposal will not work or is not aqequite.
- Mark
