Re: Deva interface

[Bas Wijnen]

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
> systems.

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.

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