l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kernel Interface Page Dumping Server


From: Marcus Brinkmann
Subject: Re: Kernel Interface Page Dumping Server
Date: Wed, 7 May 2003 13:04:50 +0200
User-agent: Mutt/1.5.3i

On Wed, May 07, 2003 at 11:19:20AM +0200, Espen Skoglund wrote:
> [Marcus Brinkmann]
> > [...] I am not sure if there is a real need for our own libl4 or if
> > the official one is the one to use.  For now I am doing this for my
> > personal gain (learning by doing), and because a lot of the concepts
> > I am using in libl4 are directly relevant to glibc hacking that is
> > ahead on the road for us.
> 
> You should be able to just ust the inline functions in the official
> header files.  Also, if you only use the KernelInterface() syscall you
> will not need to link with some external library.

That's right.  I used the special "extern inline" semantics from gcc, which
allow you to have a function inlined if optimization is enabled, and ignored
if not.  Then you can have a non-inlined version of the function in the
library as well, in case it is referenced by pointer or the user just
doesn't want the function to be inlined for some reason.

I allow any of the three pointer parameters to l4_kernel_interface to be 0,
so you can select which of api_version, api_flags and kernel_id you really
want.  If you do this using a constant, gcc will eliminate the dead code and
the resulting assembler is really crisp and lean.

> The only reason for
> needing the libl4 is to patch up references to the syscall stubs
> provided in the KIP (or some other page in memory).  For a real
> system, this should be taken care of by ld.so (or its equivalent).
> That is, the dynamic loader identifies the system call stub addresses
> in the KIP and uses these addresses instead of the stub functions in
> libl4 (which should be declared as a weak symbols).

Hmm, this is interesting.  I was thinking about having it in the glibc
startup function.  Having them set up in ld.so directly is even better.
It sounds just a tiny bit hackish though.  If you define the KIP address
system wide for all tasks, you could also avoid the need for such a fixup
and compile the addresses statically into the program.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]