[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deva interface
Re: Deva interface
Mon, 17 Jan 2005 17:28:53 +0100
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
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
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 http://188.8.131.52/e-mail.html
Description: OpenPGP digital signature