[Top][All Lists]

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

Re: Deva interface

From: Bas Wijnen
Subject: Re: Deva interface
Date: Mon, 17 Jan 2005 17:28:53 +0100
User-agent: Mozilla Thunderbird 0.9 (X11/20041124)

Marcus Brinkmann wrote:
At Mon, 17 Jan 2005 10:13:27 +0100,
Bas Wijnen <address@hidden> wrote:

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.

I appreciate your sentiment.  Which means I agree with you if we talk
about what we would like to have.  But we also must acknowledge that
the world is a cruel and harsh place.

I agree with you on that as well. What this is about is to make it so easy to write a driver for our framework, that our framework will be ported to other systems. Then people will like to write such "platform-independant" (no doubt excluding Windows) drivers, because they can be used by everyone without change.

I don't think we can possibly define a good interface that fits all
spectrometer devices now and in future.

Of course. Every interface should leave room for extensions. Applications which don't use the extensions should still be able to use the new devices though (although probably not all its features).

Heck, I don't even know the
interface of a single such beast.

As I wrote, "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." What I meant with that is that we shouldn't try to define everything which is possible in the world, just the things we have and want to get working. Interfaces should be designed by people who use such devices, and perhaps they should be considered "unstable" for a certain period, in which it can change. After that it is declared "stable", which means the features in it will not be removed. New features can still be added though (which are then themselves unstable for some time until merging permanently in the stable interface definition). I haven't thought about this a lot, so these thoughts should still be considered unstable. ;-)

Also, I am sceptical if what you envision can even be achieved for the
most common types of devices.  If a hardware is special, you need the
software know about the speciality.  If this is in form of a small
driver type of snippet, or in form of a configuration snippet is
almost irrelevant at that point - for both type of changes you have to
modify the application.

If the change is in the driver interface, then the same application can be used with new devices which provide the same feature. If it is unlikely that there will ever be such a device, the feature may never be added to the stable interface. Or perhaps it will. Interfaces may be large, drivers don't need to implement it all. In general, there will still be a library to access the driver anyway, as that makes device drivers really platform independant. That library should handle the use of missing features in a proper way (ignoring, aborting, whatever).

But the killer argument is that all this work is mostly useless if we
are the only ones doing and using it, because then almost nobody wins
anything: We still have to modify all the software out there, and all
the software still needs to have the small drivers for all the other

At the moment, a separate driver is needed for every system. As far as I understood it, the reason of making the ddf not use any hurd-specific features was to make it portable. I like that idea very much. It would make it possible to write a single driver for several systems. We will have to see if that is what happens, but at least it's good that it's possible. :-)

Since there is no such system available at this moment, we cannot simply use it (otherwise we should, IMO). So we should start it ourselves, and hope others will use ours.

Now, this doesn't mean we shouldn't try, but I'd suggest to do this in
a reasonable manner and according to our resources.  If this is
something you are so eager to have that you will define a hundred
device class interfaces, then more power to you.

Not at all. I was proposing to do this as it comes up. Whenever we write a device driver, we start with a well defined interface, and implement that. I wasn't planning on designing any interfaces of devices I don't have, or for which I don't want to write a driver.

But I wouldn't mind
to go with simple cloning interfaces in the meantime, and use
ioctl-like tricks as used on other operating systems where necessary,
just because this would be almost a no-brainer, and you need to have
such things anyway (there will _never_ be a specific interface that
covers all present and future devices people want to run).

With the stable and unstable features, there shouldn't be a problem. Any feature is "ioctl-like", and anything that doesn't seem to fit in the interface is given an unstable feature. It then either becomes stable if it was good, or is replaced by a different feature if it wasn't.

Maybe you can start this work, if you are so inclined and able, to
present us with a list of the most common device classes, and what
their interface specialties are.

I'll see what I can do. I shall not try to define interfaces for devices of which I have no knowledge though, as they will most likely be worthless anyway. ;-)

I do agree though that we must get the basics right, and this includes
things like event notification and stuff like that, which seems to be
ever more important (pluggability and everything).

I don't think it's more important, but I do agree that it's important enough to consider it unacceptable if they're missing.


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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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