Eric J. Korpela writes:
>
>
> > it's not free (libre) like ELKS, but have a look at minix. It's fully
> > able to recompile itself, so you can spend all the time you want abusing
> > that old hardware.
>
> But it's barely functional under 640K. If fact I seem to remember not
> being able to compile it in 640K.
>
> Anyone know how much of cc1 is libc? Maybe it's time for shared libraries?
>
> Implemenation idea:
>
> Shared library file format is the same as object file format, except
> no static data is allowed in the file, just code. When creating a
> shared library, code is moved to filename.so. Static data and a bunch of
> far call stubs are moved into a static library filename.a. This library
> is linked with code normally. The only unresolved symbol in the program
> are the code segments of the shared libraries.
>
> A system call would be resonsible for loading the shared library (if
> not already loaded) and would return its code segment. The program loader
> would need to call this for each of the shared libraries and write their
> code segments into the proper places in the program.
>
> The biggest problem is that this would require the shared libraries not
> be moved in memory when they are in use. To prevent fragmentation,
> perhaps a garbage collector could be called when the libraries are loaded.
>
This sounds like a workable implementation, though I think we should put
priority on getting the ammount of data used by processes down as this is
currently where most of the memory is going. The only other thing is that
most binaries currently use a tiny fraction of libc, whereas if the whole
of the libc code was in the dynamic libc, then we would have more memory
taken uyp by code. Maybe its time we split libc up into libtermcap,
libsocket etc? Or maybe the shared libc codesegment should only contain
some of the code libc functionality?
In any case I think the libc.so file should be in linked format, not object
file format.
Al
