Device enumeration (was Re: CD writing in future Linux (stirring up a hornets' nest))

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

 



On Mon, Feb 13, 2006 at 09:50:46AM -0800, Greg KH wrote:
> On Mon, Feb 13, 2006 at 05:49:11PM +0100, Olivier Galibert wrote:
> > You mean root is mandatory to talk with devices, whatever they are?
> 
> Not at all.  You only have to be root to create a device node, nothing
> new there.

Ok, since I don't think you're being deliberately dense, please pick
up your beverage of choice in order to clear up your head and let's
start again calmly.

Problem: finding and talking to all the devices which have capability
<x>, as long as the system administrator allows.

Examples of <x> can be:
- Maxgate hard drive I can do firmware upgrades on
- Motokia phone I can exchange data with
- CD/DVD drive, with or without writing capabilities

The hard drive can be ide, sata or in a usb enclosure.  The phone can
be connected through serial-over-usb or serial-over-bluetooth, etc.

At that point, we get several answers:
1- You do not need to do device enumeration, the user has to know the
   devices names, period.
2- Hal knows it, ask him
3- Udev knows it, ask him
4- sysfs has all the information you need, just read it

Answer 1 gets a little tiring after a while.  Usability starts by not
asking the user things you can know automatically.

Answer 2 is a little annoying.  Hal/dbus are not at 1.0 at that point
yet, especially Hal.  The constraints they put on programs and
especially on libraries can be a little hard to swallow, mandatory
glib for a start.  It's a little too much for such low-level needs.
OTOH, it has the advantage of being able to tell you dynamically of
new devices being connected.

Answer 3 is even more annoying.  Udev is not very good at backwards
compatibility (udevinfo -d of fedora core 3, i.e. udev-039, is
udevinfo -e in later versions for instance).  Udev is obviously not
mandatory, and may be replaced in two years or less (remember
/sbin/hotplug's fate?).  And frankly, should programs that just want
to find devices have to know about the program-of-the-day for device
node creation?  It also has the problem of requiring a
fork()+exec()+output parsing, which from a library context can be
annoying at best.

Answer 4 would be very nice if it was correct.  sysfs is pretty much
mandatory at that point, and modulo some fixable incompleteness
provides all the capability information and model names and everything
needed to find the useful devices.  What it does not provide is the
mapping between a device as found in sysfs, and a device node you can
open to talk to the device.  You get the major/minor, which allows you
to create a temporary device node iff you're root.  Or you can scan
all the nodes in /dev to find the one to open, which is kinda
ridiculous and inefficient.  Or you have to go back to udev/hal to ask
for the sysfs node/device node path mapping, and then why use sysfs in
the first place.

At that point, sysfs would be the best choice for device enumeration
from a user program, from a point of view of resilience to userspace
fad changes and simplicity/weight of code.  Except that you can't use
it for that.  That's annoying.

  OG.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux