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(), ...