Re: Working on the ddf

[Marcus Brinkmann]

At Wed, 14 Apr 2004 14:48:16 +0200,
wagi wrote:
> 
> > This is actually rather easy.  I have gotten a task server dummy to
> > work, ie, wortel starts it, and it is using simplistic dummy
> > containers in physmem.
> 
> Ah, that's great news!
> 
> So what we have to do is to design a nice interface between dplm, deva
> and hurd...

You can not have something "between" three entities (the word you'd
have to use is "among").  What is required is an interface between
dplm and deva, which is your official dplm interface, and that will be
a native L4 interface, with your semantical extensions.  The interface
between deva and the rest of the Hurd (note that deva is part of the
Hurd) is a "normal" Hurdish server interface.

> Marco: Here a short not finished list of needed stuff.  Feel free to
> change/add:
> 
> deva - wortel:
>   create new (L4) task
>   destroy (L4) task

I am tempted to let deva wrap dplm tasks into normal Hurd tasks.  This
makes them attackable to "kill -9", but that is arguably the right
thing.  At the very least it will show the device tasks in the process
listing, and the task server could also keep track of the cpu time
consumed (via the scheduler) etc.  It would also allow to integrate
the Hurdish debugging support into the dplm framework (optional).

> deva - physmem:
>   alloc memory 
>   dealloc memory (remember: physmem can ask memory back!)

Having the device framework work on paged memory is quite hard and I
would claim downright near to impossible.  I'd suggest to wire down
all memory you use.  However, if you want low-level I/O caches
(gianluca thinks they are essential, but neal and me believe caching
is better done at higher levels, like the filesystem), then it makes
sense to treat cache memory specially (using extra pages).  So, some
considerations apply here, but in general, don't worry too much about
it.

> deva - root file system:
>   load driver binary

Well, that's the normal filesystem interface, of course.
 
> dplm - deva:
>   create new task
>   destroy task
>   alloc memory
>   dealloc memory (deva can ask memory back!)
>   load driver binary

See above.  We should try hard to make the dplm-deva interface slim
and lean, and generic so that it can be implemented by other OSs, too,
and so that deva does not need to reimplement a whole operating system.

Thanks,
Marcus