Re: [Fwd: Re: Deva interface]

[Vittore Scolari]

R. Koot wrote:

> Marcus Brinkmann wrote:
>
> >
> >
> > Ok.  Call the wrapper layer deva, drop the deva frame from your
> > picture, and we have the same mental picture again ;)
> >
> > At some point everybody just assumed that deva would be a stand alone
> > task.  I don't know why.  A few days ago it occured to us almost in
> > passing that we could just as well make the driver framework a library
> > to deva, or the other way round.
> >
>
> You might have a good point here (making Deva a library), although I 
> have a bit of a problem visualizing it.
>
> One of the problems which I see (and intuitivly solved by making Deva 
> a separate task) is concurrent access to hardware by separate drivers. 
> To talk with a PCI device the driver would have to select the bus it's 
> on into memory. Now, if another driver would select another bus into 
> memory short after the first driver would be talking to the wrong 
> device. Normal operating systems would fix this by disabling 
> interrupts/critical sections. But I hate those and I think they can be 
> avoided with a good design. Now if Deva was a task it 
> coordinate/serialize access to hardware, but how would you do this if 
> there are a lot of Deva's.
> (A: Shared memory?).
A device driver would contact the bus driver before doing such this 
thing, the bus give the right to do this only a device driver at a time

> Enumeration would be done through Task I guess. Actually now I think 
> about it, you would only need to now which task is the Root Driver, 
> which will return a list of drivers it has loaded, which in turn would 
> return the drivers they loaded, allowing you to find out about the 
> hardware topology.
>
> Does anybody else see other problems with making Deva a library?
>
> Now you would have portable drivers, Deva which transforms the 
> functions in the portable drivers into HURD RPCs and provides the 
> implementation of the portable run-time envionment available to the 
> driver. And if you wanted to use the driver on Linux you would just 
> have to create a Deva-ish thing (which would work for *all* drivers) 
> which exposes the driver to the kernel, ALSA, /proc, ioctl(), ...
>
> I could really see this working :D
>
>
> Ruud
>
>
>
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/l4-hurd
Another problem remains bootstraping..
Wortel should load the boot-drivers and the rootfs


Vittore