l4-hurd
[Top][All Lists]
Advanced

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

Re: Deva interface


From: Marcus Brinkmann
Subject: Re: Deva interface
Date: Mon, 17 Jan 2005 13:29:41 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

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 don't think we can possibly define a good interface that fits all
spectrometer devices now and in future.  Heck, I don't even know the
interface of a single such beast.

For more ubiquitous (I love that word) stuff, it's definitely easier,
but only if other people already did the work and the interfaces have
passed the test of time - which either means they are dead simple, or
the device class is mature and/or obsolete and doesn't evolve anymore.

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.  The configuration of the generic driver is
also a "driver" in its own right.

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.

This all could very well be a reflection of my own lack of interest in
hardware toys, and the resulting lack of imagination of what would be
possible at the interface level.  Everywhere I look the situation
seems to be pretty messy, and that's about the only thing I can say.

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

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.  For example, I know that Joerg
Schilling has a very specific opinion on SCSI and CD Burner
interfaces, but I know next to nothing about his specific complains.
I don't know much about hardware interfaces, but I am interested in
learning about them.

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

Thanks,
Marcus





reply via email to

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