: I am very interested by the
: possibility of loading .o files as modules, both into the kernel and into
: user applications. As a means of loading drivers in nanoGUI and microwin
: this sounds great.
I have very nearly completed the .o loader this weekend. It reads
in any number of .o and .a files, and builds import/export symbol tables, and
then loads any text/data segments that are needed, and relocates all the bits
using segment or symbol relative offsets. I am currently working on some
severe memory usage issues, relating to reading in libc.a. This is going to
be cool!
:
: I am not sure this could be made to work usefully as a means to build
: shared libs. It would still mean that the address space of the process
: has to contain all the code and data of the library which eliminates the
: possibility of sharing memory between processes, so the only advantage is
: the size of binary files on disk, which is not much of a concern.
:
I've thought this through to some degree, and yeah, I kinda
came up with the same thoughts, that we might only get binary file
sizes down, which isn't much of a benefit, considering the work.
There are several issues, though that need more discussion, because
a dynamic loading technology could still considerably enhance the approach
to applications development, in a good way. Currently, the biggest
problem with shared libraries on 8086 and bcc is that the compiler can't
produce position-independent code (ala -fPIC) so that even the code segment
requires data relocations, and thus can't be shared. So each process has it's
own copy. Well, thats still not all that bad, because it means that ELKS could
have different modules (including kernel modules) execute as .dlls rather than having
everything always linked together. Portions of the kernel or other programs
could be replaced by merely replacing the .dll (.o), rather than recompiling
everything.
I think this is one of the most basic features of newer, more advanced operating
systems.
What I'm working toward is adding developmental technologies, so that
more advanced programming methodologies could be used in building applications
for both linux, windows, and ELKS. This requires shared libs. For instance, the
Microwindows goal of loading application code and data works nicely under linux,
and it'd be nice to have it under ELKS. It is, however, alot of work rewriting all the
tools for each platform. That's why I'm currently designing around bcc and as86,
rather than rewriting them.
Another big issue is that, in order to load modules, it would be nice to
be able to load data and tell ELKS that we want that data to be thought of as
a text segment. In addition, there is quite a bit of "temp" data (symbol tables, etc)
that would be nice to free and have the image look like a normal text+data+bss.
Also, there are issues with _end, etc for the C library. I think I have most
of this sorted out, but it still will use alot of process memory. I think
the development advantage is still there, however.
Greg
