Re: /etc/udev/rules.d and permissions in /dev/usb

I demand that Nix may or may not have written...

> On Mon, 09 Jan 2006, Darren Salt mused:
>> I demand that Nix may or may not have written...
>>> On Fri, 06 Jan 2006, Darren Salt said:
>>>> I demand that Nix may or may not have written...
>>>>> It shouldn't do: the coldplugged devices are never unplugged, so the
>>>>> kernel should never get a REMOVE event for them. [...]
>>>> After a reboot, two ALSA devices got swapped and two DVD drives also got
>>>> swapped. I'd been relying on the default order, which had previously
>>>> been stable, and I don't recall any warning of instability.

>>> The ordering of events is not guaranteed unless you enforce it, except
>>> inasmuch as child events are guaranteed to be sent after parent events.

>> Useful wrt USB, then...

> For that, and also for things like making sure that partitions only appear
> after the block devices they are part of.

I was actually thinking about semi-modular kernels - everything required to
get as far as "late" user-space built-in and various other things left as
modules.

>>> It just happens that some subsystems (e.g. those that read disk
>>> partitions) always happen to emit the events in the same order. Others
>>> have no such guarantees, and in general, there are no guarantees at all.

>> Link order?

[snip]
> - `udevsynthesize', which writes to all those uevent files, following
> similar rules to those udevstart used to follow. Here's mine, a
> very-lightly-adapted copy of Debian's:

> ,----
> | #!/bin/bash
> | #
> | # udevsynthesize --- Populate the initial /dev tree.
> | #
> |
> | list=$(echo /sys/bus/*/devices/*/uevent /sys/class/*/*/uevent)
> | list=$(echo $list /sys/block/*/uevent /sys/block/*/*/uevent)
> |
> | for file in $list; do
> | case "$file" in
> | */device/uevent) ;; # skip followed device symlinks
> | */\*/*) ;;
> | *" "*) ;;
> |
> | */class/mem/*) # for /dev/null
> | first="$first $file" ;;
> |
> | */block/md[0-9]*)
> | last="$last $file" ;;
> |
> | *)
> | default="$default $file" ;;
> | esac
> | done
> |
> | for file in $first $default $last; do
> | echo 'add' > $file
> | done
> `----

[snip]
> It's very, very neat, but the downside is that because the shell now
> does the initial population, well, if you want ordering, you'll have to
> call `sort' in udevsynthesize yourself.

Problem: sort is in /usr/bin. OTOH, it looks like the shell is sorting glob
expansions anyway, and I'll need to build and install 2.6.15 to avoid the
binary 'udevsynthesize'.

> It was always unreliable because if those devices are hotplugged after
> boot, they of course will follow no such ordering constraints (except that
> you can't easily unplug a disk partition; you can rely on whole disk block
> devices and their children getting plug and unplug events all at the same
> time, neatly ordered).

I consider that to be an acceptable unreliability.

[snip]
>>> (This is why using %e is a bad idea: it's been removed from the
>>> documentation and deprecated now, because it's such a bad idea to use it.
>> If that's so then why was it ever added, replacing (for CDROM drives) a

> It was there from the start of udev.

Hmm. I'd not noticed that.

[snip]
>> Were 2.4.x being actively developed for newer hardware, rather than just
>> maintained, right now I'd be considering going back to it - and, yes,
>> using devfs.

> You'd be shooting yourself in the foot, I think.

What we really need is 2.7.x. :-)

> udev is lovely once you get used to it, both elegant and astonishingly
> powerful and flexible, and now the ugly corners are mostly filed off it
> should be reasonably easy to avoid breaking userspace [...]

init=/bin/sh (for emergency stuff, i.e. with a static /dev) looks like it'll
be semi-broken, which isn't good at all. I've occasionally used this to fix
things up a bit when I've just done a reboot a little too early.

[snip]
>> Given that this isn't exactly practical, I think that some enforcement of
>> order of events *is* needed, or at least is very useful.

> Why? What good is it? If you ever use it, you're asking for trouble as soon
> as you start hotplugging your devices or change udevsynthesize. (In fact,
> thanks to udevsynthesize, event ordering at coldplug time is now up to
> *you*... but of course that doesn't help much as you can't control the
> order in which users hotplug things!)

For some things, lack of order isn't a problem. For other things, well, they
shouldn't have been broken before adequate replacement was available...

>>> I personally consider even using the kernel device numbering, %n, to be
>>> somewhat risky; /dev/disks/by-* makes even that unnecessary now.)
>> I took one look at it in use and promptly removed the symlink (restoring
>> the previous state). /dev/hda is adequate, a lot easier to remember, and
>> (given one IDE controller) nicely *static*.

> That's only true as long as you don't have USB mass storage devices

Not currently a problem, and it won't be a problem anyway unless hd* suddenly
become sd* (which would be a bug).

> or parallel port devices that pretend to be IDE disks.

I don't have any; anyway, I'd build the driver as a module.

> Boot with one of them plugged in, and whoops, look, the kernel chose to
> label *it* as `hda'...

If it does, despite the IDE driver being built-in, that'd be a bug.

> (I'm not sure if the kernel will do this now, but it's quite within its
> rights, and it *does* do this with SCSI devices. The way to fix this is to
> use properties of the medium or the device as device naming
> characteristics, which is what /dev/disk/ is for.)

Why, when I'm building in what should be exactly enough to provide a useful
system?

[snip]
>>>>>> It seems that the "right" way to do this now is to generate rules to
>>>>>> provide this naming. I think that it's going in the wrong direction
>>>>>> here :-|
>>>>> Well, um, the various persistent.rules files aren't exactly long or
>>>>> rapidly changing: mine is 55 lines.
>>>> -ENOENT.
>>> The file which contains rules to generate the
>>> /dev/disk/by-{id,label,path,uuid} stuff.

>> Oh, *that* lump of ugliness...

> s/ugliness/loveliness/

No, ugliness. It's far too long-winded.

> They're names for your *disk media* or *disk devices* which *never change*,
> no matter how you might move your disks around. This is useful whenever you
> add or remove disks,

But not more useful for me, AFAICS. Therefore, why change?

> adds no overhead if you don't do that much,

Adding labels is overhead. Not *much* overhead, but still more than what I
would do now.

> and should eventually enable the removal of stuff like by-label and by-uuid
> mounting from mount entirely (it has never really belonged there IMNSHO;
> it's not mount's job to parse the insides of filesystems, just to ask the
> kernel to mount them).

Oh good. Back to hda, then :-)

--
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian, | Northumberland | s zap,tartarus,org
| RISC OS | Toon Army | @
| We've got Souness, we don't want him

universe: n. A spheroid 705m in diameter.
.

Relevant Pages

  • Re: Partition help
    ... > /boot is where the kernel and some associated files live. ... > the disk, so you should make that the first partition. ... I would probably make my swap partition smaller - more like ...
    (Fedora)
  • Re: Software RAID-5 attempt to access beyond end of device...
    ... The reiserfs is on top of an lvm2 on top of a raid5 ... >information that has previously been stored on disk. ... Sep 7 20:32:04 cu kernel: Buffer I/O error on device dm-0, ... PCI: PCI BIOS revision 2.10 entry at 0xf1150, ...
    (Linux-Kernel)
  • Re: Spontaneous reboots
    ... yet I keep experiencing spontaneous reboots and crashes. ... > I have postfix handling mail and use cyrus-imap with virtual ... Page fault while in kernel mode ... > Disk errors: ...
    (freebsd-questions)
  • Re: New Patch Fixes 43 Flaws In OS X, Many Serious
    ... A product being a "Unix" has no security implications ... Mac OS X would then become higher ... So it is with any kernel, ...
    (comp.sys.mac.advocacy)
  • Re: Story Time
    ... In this case, the General Public License says that "you" can freely use "his" code, but that if you distribute the subsequent binaries to anyone else, you must share your changes with "them". ... the GPL encourages you to charge money for shipping your code to your distributees. ... difference ins the kernel between the two versions. ...
    (comp.os.vms)