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 15:31:48 +0200
User-agent: Mutt/1.5.3i

On Wed, May 07, 2003 at 02:41:40PM +0200, Espen Skoglund wrote:
> > 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.
> 
> Since the compiler can inline the functions and detect that certain
> words (local variables) are assigned to but then ignored, the compiler
> should also be able to eliminate these assignments.  The result should
> be the same, and we avoid cluttering the code witch special checks.

OTOH, you clutter the caller code with unused variables.  But as the kernel
interface system call is not supposed to be invoked directly by an
application anyway, it's not a big deal either way.

Why does the convenience interface require passing a pointer to the KIP
around?  As the KIP location can not be changed during the lifespan of an
address space, it should be sufficient to query it once and cache it in a
global variable and just use that for all these functions.  The
up-front initialization that is then required can be done in the dynamic
linker as well.  I guess you might worry about synchronization, but then in
any non-trivial program there is a large amount of startup initialization
anyway.

> Your solution is also semantically incorrect.  It might very well
> happen that an application supplies a pointer to a word at addres zero
> (although I admit that this is pretty unlikely :-).

Now, that is evil.  Point taken.  :)

[About the KIP load address:]

> Compiling it statically into the program is inflexible.  If the KIP is
> located at a high address it effectively prevents small spaces from
> ever being used.  If it is located at a low address it might have
> other consequences that we can not yet foresee.  The only way to allow
> for complete future flexibility is to allocate the KIP dynamically.

Mh, ok.  Thanks for the explanation.

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]