Re: Deva interface

[Bas Wijnen]

Neal H. Walfield wrote:
> > *I tried to design some interfaces for deva.
> >
> > deva should respond to at least these RPCs:
> >
> > -enumerate
> > -open
> > -close
> > -read
> > -write
> > -map
>
>
> This is a good start.  We will also need a way to get some properties
> of devices such as the preferred block size, the size of the device
> (in the case of block devices) etc.  The list can always be extended
> later depending on the actual needs (instead of perceived needs) of
> the device drivers and the users.

I think the most important thing of the framework is to have clear 
definitions of "device class interfaces", a bit like usb device classes 
have them.  The difference is that every device should fall into a 
class.  An example: there should be a class "network device", for which 
an interface is defined.  To write a driver for an ethernet card, or a 
modem, or a wifi card, it is then clear what interface to implement. 
Drivers may follow more than one interface (in fact, most devices will 
do that, I think).  I mention in particular the modem, as I heard from 
some companies who were complaining about the way Linux handles them: in 
fact it doesn't at all, if you're lucky you get a serial port, with 
nowhere in the system a hint on how to set up exotic parameters.  That 
sort of information should be usable by the client, either by making it 
available, or better yet, by providing an RPC to set it up.

There should be interface definitions for every possible device, of 
course, so every device driver writer knows what to implement, and every 
client knows what to interface.  If someone wants to write a driver for 
a device which doesn't have an interface definition yet (because noone 
thought of such a device before), a new definition should be designed. 
Of course the interface definition database should be publicly readable 
in a logical place, probably somewhere on gnu.org.

I think this is the most important thing to get right.  In the old days, 
you knew how to control a device, and an application had to be a device 
driver as well.  This is still the case for "special" devices (such as 
spectrometers).  In my opinion, programs should be able to use any 
device of some type, without needing any modification (or even a 
recompile) when a different device is used.  This is of course the case 
for "normal" devices, such as hard drives and other "normal" drivers, 
such as filesystems.  It should also be the case for the "special" 
devices and drivers.

Those were just some thoughts which I think are important to keep in 
mind while writing a ddf.

Thanks,
Bas

--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: OpenPGP digital signature