[gentoo-desktop] Re: Kernel_2.6/devfsd/SCSI/USB/Digital Camera problem

[Duncan]

Luke-Jr posted <200410170339.07781.luke-jr@×××××××.org>, excerpted below, 
on Sun, 17 Oct 2004 03:39:04 +0000:

> On Sunday 17 October 2004 3:34 am, Collins Richey wrote:
>> I can't explain the behavior for devfs, but you should be able to cure
>> the problem by moving over to udev. You can add a udev paramter to
>> insure that the camera always mounts as some specific device, example
>> /dev/sda?. udev does not use the complex
>> /dev/scsi/host4/bus0/target0/lun0/part? nomenclature.
>
> I actually like having the /dev/scsi/host4/bus0/target0/lun0/part stuff.
> In certain circumstances, accessing devices based on physical location can
> be useful.
> However, I like hearing that you can specify device-specific things like
> that... Maybe I'll switch and hope I can configure it to do both =D Anyone
> know if the script for hotplug to automatically mount USB devices (under
> /mnt/usb/devicename) is compatible w/ udev?

udev is designed around the ability to provide /just/ this sort of
solution.  The scripts activated when you plug something in can use
various stuff (like the buss, default kernel name, model and/or serial
number of the device, etc) to create an real /dev entry, and any number of
symlinks, which can be located in the traditional devfs location (as
Gentoo does by default) or anywhere you might happen to decide you want to
put them.

One of the reference implementation examples uses scripting to look up the
info for a CD in a CDDB, and actually symlinks the artist and album name
as one of the available device names!  Greg KH (one of the Gentoo kernel
devs, BTW as well as one of the up and coming mainline kernel developers
due to his UDEV work) said it was a "fun" script without a lot of
practical use, but that it /did/ illustrate the flexibility available with
udev!

The one downside, if you want to call it that, is that depending on
whether you have it set to full dynamic UDEV or set to save some device
nodes across reboots, if in dynamic mode, it doesn't create the device
nodes until it actually detects the device.  With hotplugged stuff it
generally does quite well.  However, with stuff that's plugged into the
system at boot, with coldplug, it can and does detect and load the modules
and therefore creates the device nodes in some cases, but not in all
cases, depending on what the hardware is.  However, that can be fixed
either by listing the modules in question in the kernel autoload file, or
by building the modules directly into the kernel.  I believe creating the
device nodes manually, saving state across a reboot much as devfs did in
some cases, will work as well, autoloading the required module when the
device node is referenced.  However, I prefer to avoid that sort of crufty
solution here, and like the idea of not having the device nodes there if
either the hardware or the modules aren't loaded to handle them.  That
way, I can tell at a glance what's available for use, by the nodes in
/dev.  If I wanted all sorts of crufty nodes maintaining themselves over
reboots, whether or not the hardware devices and kernel modules were
actually there available for use, I'd stick with a static /dev.  I want
dynamic, and that's what I get, with udev, which allows me far more
precise control than devfs ever did.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-desktop@g.o mailing list