[K42-discussion] Self-contained programs and alternative dispatcher implementations

[Bryan S Rosenburg]

I've committed changes to the K42 loader code to support self-contained 
K42 programs (statically linked programs that contain their own copies of 
the K42 library).  Programs that want to use alternative dispatcher 
implementations should be built this way.  For now, we identify a 
self-contained program with a hack -- we set the OS/ABI byte of the ELF 
ident field to decimal 42 (ascii '*').

I've also made a few changes to disentangle the DispatcherDefault 
dispatcher implementation from the rest of the K42 library, making it 
somewhat easier to experiment with alternative implementations.  There's a 
silly new test program in the altDispatcher subdirectory of kitchsrc/usr. 
The Makefile there mechanically creates an alternative dispatcher by 
copying the files that make up DispatcherDefault and globally renaming 
DispatcherDefault to DispatcherAlt.  It then builds a self-contained 
hello-world program using the alternative dispatcher implementation. 
Neither the program nor DispatcherAlt do anything the least bit 
interesting.  They're there just to show what needs to be done to create a 
program with its own dispatcher implementation.

These are only first steps toward really supporting customized 
dispatchers.  I can think of two more missing pieces.  First, we've done 
very little to isolate the Thread object from the rest of the library. 
While only a few files actually access the internals of thread objects, 
Thread.H is included directly or indirectly in nearly every module in the 
system.  We need to bind the thread object implementation more closely to 
the dispatcher implementation and isolate it from the rest of the system. 
Second, we need to provide a more flexible mechanism for obtaining field 
offsets for use in assembler files.  Any non-trivial alternate dispatcher 
implementation is likely to change the layout of both the 
DispatcherDefault object and the Thread object, so the assembler files 
that are part of the implementation will not be able to use the field 
offsets currently generated in asmConstants.H.

- Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20051213/39ab30bf/attachment.htm