RE: shared text, shared libs again

[Sven Karlsson <sven@it.lth.se>]

Hi there!

This all sounds very much identical with Fenix shared libs. Like you I
have worked a bit
with most of the shared libs systems out there. It is possible to adapt
the Fenix shared
libs source codes to work with MiNT. I also would very much like to see
that the shared libs
formats of Fenix and a future MiNT shared lib scheme to be identical so
that Fenix can be 
compatible with MiNT.

Fenix libs work like this:

The application needs to open the lib in order to use it. It should also
close libs that it doesn't
use. When opening the lib two pointers are returned. One at (address
table) pointer and one
local pointer which points to an arbitrary datastructure shared by the
lib and the application.
The library is opened by using a library name which is similar to a
filename. Indeed it is
often just that, the name of an executable file. The local pointer might
not be used by the
library and thus it might be NULL. The organization of the local data is
library dependent.

When calling the lib the application gets a function pointer from the at
which is a vector of
pointers and calls the library function using this function pointer
directly. It pass the local
pointer as the first argument always. This means that the local pointer
is sort of equivalent
with the a this pointer in object oriented programming. The shared lib
is run in the calling
application's context and address space.

In Fenix there is also possibleto let the library to be a separate
process and call functions 
in that process by letting threads migrate. This is how os calls is done
in native Fenix code.
This also means that you can easily add kernel services in Fenix. The
added services are 
run as normal user mode processes! The migration of the thread is
performed by the kernel
which also checks that the application is allowed to run the particular
function and of course
that the function is valid.

Also in Fenix you can have supervisor mode library functions. These are
also run by the kernel
and the kernel checks that the application is allowed to run the
function very much the same
way as the os calls described above. This is how for instance the
supervisor parts of device
drivers are handled. There is no other way in Fenix to get into
supervisor mode. In fact no part
of Fenix except parts of the devicedrivers (actually lowlevel device
drivers which I call resources)
and the microkernel itself is run in supervisor mode. All the other
parts are user level processes.
(including of course signal handlers).

Anyway, I think this is a scheme that is both safe and fast. It has been
designed to be safe
even in systems without memory protection and it has also been designed
to be fast on all
680x0 proessors including 000, 040, 060, and ColdFire processors.

Howard, you are very much welcome to discuss library schemes with me and
some other programmers. I can mail you the current draft of the Fenix
lib spec if you want.

Regards
 Sven

> -----Original Message-----
> 
	... deleted loads of text ...  

> Anyone else have ideas on making this all work?