[K42-discussion] K42 pieces

[Patrick G. Bridges]

Thanks for the extra info, Bryan. Very useful stuff. A few questions:

> Dilma may correct me, but I think baseServers also supports NFS and  
> ramfs filesystems.

It does.

> exec.so isn't really linked with the application (dynamically or  
> otherwise).  It's a self-contained module that is injected into  
> each address space at a fixed address.

Gotcha. Just looked over that code.

> So far I've been talking about pure Linux applications.  The  
> story's a bit different for native K42 applications that want to  
> use K42 services directly.  For such programs, exec.so is still  
> loaded at the same location as it always is.  The app doesn't  
> really link to it directly, but instead links with -lk42sys.   
> libk42sys.so is a magic shared object that has no code or data of  
> its own but supplies all the same symbols as exec.so, and causes  
> all those symbols to be mapped to the corresponding addresses in  
> exec.so.

Hmm, I don't see how this happens - libk42sys.so.1 is about 6-7 megs  
in size and includes everything from a stripped exec.so on powerpc as  
far as I can see. How do we prevent ld.so from loading in all the  
symbols and data from libk42sys.so again and instead use the parts of  
exec.so already in the image?

Anyway, since exec.so doesn't need to be relocatable and libk42sys.so  
only needs to be able to vector into it, could we change the build  
system to generate exec.o as a fully resolved object, and then  
generate a dummy shared object with the right generated .got and .plt  
sections needed to allow a pure k42 app to vector into it?

-Patrick