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: 3B1 parts needed
    ... O.K. But you need the initial install disk to partition the ... But really -- you need the install floppy to partition the disk ... add in oxidation of connector plating - the warm connector ... A compressed version of the 3.51m kernel. ...
    (comp.sys.3b1)
  • 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)