[Top][All Lists]

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

Re: drivers for l4 (2)

From: Espen Skoglund
Subject: Re: drivers for l4 (2)
Date: Mon, 24 Mar 2003 21:22:09 +0100

[Daniel Wagner]
> For actually bootstrapping the resource manager (rmgr) with some
> small additions could be used:

>       + keeps a list of the modules started, their name, their grub
>         commandline and their thread id.
>       + no reallocation needed for modules (Why is this done anyway?
>         Is it to keep sigma0 simpler (one-to-one map?))

I assume you mean "relocation".  Your loader (or rmgr, or whatever you
want to call it) can indeed do relocation of loaded modules if it
wants to.  Sigma0 does, however, by definition run in an idempotently
mapped space.  No relocation is therefore necessary (the location of
everything is known at link time).  For your root servers you will need
to use sigma0 as the pager.  Since sigma0 resolved pagefault with an
idempotent mapping, this also implies that your root servers should be
mapped idempotently.  Alternatively you could have the code for some
startup phase in the root server mapped idempotently.  During this
startup phase you could then manually generate memory requests to
sigma0 (and map memory non-idempotently).

> Some thoughts on DMA.  We aim of course for a zero copy model (if
> it's possible at all):

> + Physical address must possibly be passed by the user.  This
>   possibly means that the user has to be trusted.  It depends a bit
>   on how Neal's VM server works (how are pages mapped into tasks,
>   idem potent or at any position?).
>   Or the driver needs to know from which address space the request
>   comes.  Is this possible in L4?

The receiver of the IPC will get the thread id of the sender.  Getting
the address space of the request must be implemented on user-level,
though (contact a process server, use caching, have a shared
tid-to-address-space table, etc.), so no, the L4 API does not directly
support this.  Remember, the L4 API doesn't even have the notion of an
address space identifier, so the best thing the kernel (i.e., an
extension of the current API) would be able to do would be to tell
whether two threads currently resides within the same address space or


reply via email to

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