Re: Getting Started with Hurd-L4

[Neal H. Walfield]

At Mon, 25 Oct 2004 22:50:03 +0200,
Marcus Brinkmann wrote:
> 
> At Mon, 25 Oct 2004 21:30:12 +0100,
> Neal H. Walfield wrote:
> > The client does not give the container to the server as it would not
> > be able to get it back.  The clients gives the server access to the
> > container including the right to uninterruptibly lock the container
> > for a time period.  (This way the server can be sure that the client
> > will not remove the container while it is filling it or corrupting it
> > before it takes a copy into its cache and allows the client to know
> > that it can get its resources back eventually.)
> 
> I think we dropped the idea of using a notion of "time period" in this
> context, consider "kill -9".  I also don't see a reason: If the
> container access is revoked, the server can deal with that easily (I
> don't know of a situation where the server must be guaranteed that the
> server exists for a period of time).
  ^do you mean client here?

What about cache consistency?  The server has the device driver read
data into a container.  When the device driver returns, the container
has the data and the file system takes a COW copy into its cache as
part of its extra page allocation.  If the client is able to
manipulate the data between the DMA operation and the placement of the
data into the cache, there is an opportunity for corruption.  (Hence
the exclusive lock.)

If the client dies, until the server releases the container, who owns
the guaranteed pages?  (I guess either the user or we keep a zombie
around?)

> The only exception I know of is locking for DMA, and that is by nature
> special, and a highly privileged operation, reserved for device drivers.

This is a rather large exception and integral to the system as I
understand it.

> I am not sure about the cross-CPU issue.  The scheduler doesn't have
> any idea about what IPC operations are occuring, and a server thread
> can only run on one CPU while it will deal with many clients that can
> run on different CPUs (assuming we don't have one server thread per
> CPU, which is what the L4 people recommend, but which has its own
> issues).

There are two concepts here that I need clarified:

If you do an IPC, do you not donate the rest of your time slice to the
receiving process (assuming you don't block).  (Hence the scheduler is
not invoked.)

Second, assuming the server thread is ready (i.e. in receiving
"mode"), it is not running--it is blocked waiting to receive a
message.  Hence, it is not on a CPU (it may have a last CPU where it
has a small cache footprint but that is different as I understand it).