[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fwd: Re: Deva interface]
From: |
R. Koot |
Subject: |
[Fwd: Re: Deva interface] |
Date: |
Tue, 18 Jan 2005 16:49:17 +0100 |
User-agent: |
Mozilla Thunderbird 1.0 (X11/20041206) |
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?).
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
- [Fwd: Re: Deva interface],
R. Koot <=