[Top][All Lists]

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

Re: [Fwd: Re: Deva interface]

From: Vittore Scolari
Subject: Re: [Fwd: Re: Deva interface]
Date: Tue, 18 Jan 2005 20:15:30 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804

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


L4-hurd mailing list

Another problem remains bootstraping..
Wortel should load the boot-drivers and the rootfs


reply via email to

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