Udev-135

[Matthew Burgess]

New version. Full list of the many changes since 130 are in ChangeLog in the tarball.

[Bryan Kadzban]

My first inclination is to wait for 134. There's a compilation bug in udev-sysdeps.h: it doesn't include errno.h, but still uses the errno and ENOSYS symbols. (However, it may only affect people who don't have inotify in glibc -- i.e. not LFS. Can't remember for sure.)

I'm not sure yet (because I haven't checked) whether the "The pnp shell script modprobe hack is removed from the default rules" change is a problem. (This was a fairly bad hack, but that's what happens when PNP devices have multiple IDs that each need to be modprobe'd.) I need to boot up a relatively current kernel and see if all my PNP devices are available from ACPI as well; if so, then this should be fine. At least for me... ;-)

I doubt this last one makes any difference, but it's something that needs to be double checked: "The NAME assignment is no longer special cased." Apparently now the last rule wins when multiple rules set NAME (the same way that most other keys work), instead of the first. I doubt we have this, but I don't want to assume we do without checking.

Other than that, the memory usage improvements (and perhaps speed as well; I don't know if that's noticeable on my CPU) would be good to have. :-)

[Matthew Burgess]

Well, no compilation problems here, so it looks as if LFS is OK in that respect. However, the following commands from 7.13:

for NIC in /sys/class/net/* ; do
    INTERFACE=${NIC##*/} udevadm test --action=add --subsystem=net $NIC
done

result in:

udevadm_test. version 133
test: unrecognized option '--subsystem=net'

Regards,

Matt.

[Matthew Burgess]

Simply removing the '--subsystem=net' parameter allows the above command to run and generates the /etc/udev/rules.d/70-persistent-net.rules file, which looks correct for my 'build inside a VirtualBox environment'.

[alexander@…]

The --subsystem=net parameter was added in order to support a wide range of kernels (without this, the oldest 100%-supported host kernel is 2.6.18). After removing this option, one should adjust the text on the host requirements page.

See discussion and experimental results in #2057.

[Bryan Kadzban]

Specifically, very near the end of the (very long) #2057. ;-)

The option was removed in commit aa8734ffcb8a895fc8d66ff383cbcf8f4b78f562, which looks *completely* benign according to the commit description (and yes, I *hate* it when the udev devs do this: if you're going to change the options that a command takes, note it in the log!).

I haven't tried this, but it *may* work to set SUBSYSTEM=net in the environment when running udevadm test on those older kernels? Otherwise we may have to live with only supporting >= 2.6.18 on the host system. :-(

[Matthew Burgess]

Now Udev-134. Release announcement at ​http://marc.info/?l=linux-hotplug&m=122767166300991&w=2.

[Matthew Burgess]

With the addition of the "video" group to the default Udev rules, I believe the following entries from 55-lfs.rules can now be removed:

KERNEL=="video[0-9]*",  GROUP="video"
KERNEL=="vbi[0-9]*",    GROUP="video"
KERNEL=="vtx[0-9]*",    GROUP="video"
SUBSYSTEM=="dvb", GROUP="video

That just leaves the following two rules that change ownership to the "video" group in 55-lfs.rules:

KERNEL=="fb[0-9]*",     GROUP="video"
KERNEL=="radio[0-9]*",  GROUP="video"

Why do we change ownership of the framebuffer devices to 'video'?

There's a 'winradio' rule in 50-udev.rules - has the device been renamed in recent kernels, so that our 'radio[0-9]*' rule doesn't fire any more, or are these two different sets of devices?

[Matthew Burgess]

Here's some more notes, and questions regarding our current Udev rules, in comparison with upstream's defaults:

1. random & urandom = 0444 permssions in LFS, Udev sets them to 0666. Who's 'correct'?

2. rtc = 0666 in LFS, 0644 in Udev. I'd be prone to side with Udev here, unless there's use-cases that someone knows will break? (if so, this is an upstream bug and should be sent there).

3. mouse*|mice|event* = 0644 in LFS, 0640 in Udev. Again, I'd prefer to take Udev's rules here, or report it broken upstream if that's the case.

4. js* matches, so can be removed from 55-lfs.rules.

5. SUBSYSTEM=="usb" matches, so can be removed from 55-lfs.rules.

6. KERNEL=="card*" - LFS ignores these, but Udev manages it as a dri/ device. I think things are beginning to change in the kernel now, and it may be starting to manage these devices itself?

7. SUBSYSTEM=="block" - 0660 in LFS, default in Udev. Again, unless it's broken in Udev, we should use their rule.

8. KERNEL=="dm-*" - LFS ignores. What is Udev doing in its persistent_storage_end label?

9. KERNEL=="fd[0-9]" - LFS & Udev both in floppy group so can be removed from 55-lfs.rules.

10. What's the difference between LFS' ACTION=="add" and Udev's for fd[0-9] devices?

11. The doc/ directory looks quite out of date/incomplete.

[Bryan Kadzban]

Replying to matthew@linuxfromscratch.org:

With the addition of the "video" group to the default Udev rules, I believe the following entries from 55-lfs.rules can now be removed:

Yep. All of those can be removed once we upgrade to -134 (or higher). :-)

That just leaves the following two rules that change ownership to the "video" group in 55-lfs.rules:

KERNEL=="fb[0-9]*"; KERNEL=="radio[0-9]*"

Mmmm... I don't think the radio[0-9]* devices are left. I know that those are definitely V4L devices (e.g. my ivtv card has a radio tuner that shows up as radio0); I suspect that they'll have the "video4linux" subsystem. But I can't check at the moment (won't have access to my main machine for another couple of days).

fb[0-9]* is still left in our rules, though.

Why do we change ownership of the framebuffer devices to 'video'?

I suspect it's because the framebuffer is a video-related device, and we decided at one point to do that. (Or it was based on MAKEDEV...) But I don't know for sure.

There's a 'winradio' rule in 50-udev.rules - has the device been renamed in recent kernels, so that our 'radio[0-9]*' rule doesn't fire any more, or are these two different sets of devices?

According to LANANA's copy of devices.txt, winradio* rules are for "WiNRADiO cards", whatever those are. It does not look like those cover "any radio tuner in a TV card", like /dev/radio0 V4L devices would. It looks like /dev/winradio* are a separate type of card. See ​http://www.lanana.org/docs/device-list/devices.txt for a few details, and a link to (maybe?) more. (Character major 82.)

Replying to matthew@linuxfromscratch.org:

1. random & urandom = 0444 permssions in LFS, Udev sets them to 0666.

I don't know, but I'd guess 0444 is better than 0666. With 0666, any random user can add anything that looks like entropy to the pool (but may not actually be a lot of entropy). It may even be possible to corrupt the entropy pool, to the point where you can predict what will come back out the other side given how much data you've written into it. (Of course, this is purely theoretical; I have *no* idea if it's actually possible.)

I would be fine with 0644 or 0664 (group root), though.

2. rtc = 0666 in LFS, 0644 in Udev.

I don't know how mplayer opens /dev/rtc to get its sync signals, but if it opens it for read/write, then it needs to be 0666 (unless we want to create another group, like sound and video, and set it to 0664). But I haven't tried it. I'll attempt to do so in a few days, unless someone reports either way.

(Actually, I use /dev/rtc0 with a /dev/rtc symlink already; I bet my rtc0 device is already 0644, since our rules don't change that. So I bet mplayer already works fine; I just haven't looked for sure.)

3. mouse*|mice|event* = 0644 in LFS, 0640 in Udev.

Hmm; would depend on what programs use those. The X server is (...probably?) setuid-root, so it shouldn't affect anything in X. gpm is very likely started as root during the bootscripts, so it shouldn't affect gpm. It would be a question of whether there's anything else (squake?) that might think it needs direct access to the mouse.

4. js* matches, so can be removed from 55-lfs.rules.

Actually, it doesn't look like it does match. 55-lfs.rules has a rule that refers to "js", while udev has a rule that refers to "js[0-9]*" instead. Those are disjoint sets of strings.

Of course I don't know whether there is such a thing as a /dev/js (or /dev/djs) device; devices.txt says there isn't. So I bet both "js" and "djs" can be removed from our rules at any point. :-)

5. SUBSYSTEM=="usb" matches, so can be removed from 55-lfs.rules.

The USB printer device matches, yes. Although actually, so do legousbtower*, hiddev*, and dabusb* (though udev requires a digit in their names; we don't).

So yeah -- with a udev upgrade, we can yank all those rules.

6. KERNEL=="card*" - LFS ignores these, but Udev manages it as a dri/ device. I think things are beginning to change in the kernel now, and it may be starting to manage these devices itself?

I don't know enough about DRI (either the X or the kernel side) to comment on this one...

7. SUBSYSTEM=="block" - 0660 in LFS, default in Udev.

Udev is broken if you want members of the "disk" group to be able to write to the disk (raw, without going through an FS). Personally, I've used that capability several times, especially when the FS is corrupted (or, more often, when I deleted something that I didn't have on backups). ;-)

8. KERNEL=="dm-*" - LFS ignores. What is Udev doing in its persistent_storage_end label?

persistent_storage_end just skips the entire 60-persistent-storage.rules file (it's a LABEL at the end of that file). Ignoring the whole device will also skip everything else. (Most other rules won't match, but skipping everything will help slightly with rule eval time.)

9. KERNEL=="fd[0-9]" - LFS & Udev both in floppy group so can be removed from 55-lfs.rules.

Yep. Once we upgrade anyway. :-)

10. What's the difference between LFS' ACTION=="add" and Udev's for fd[0-9] devices?

This was a recent change to get the right permissions on auxiliary floppy devices (e.g. fd0u720). The upstream RUN rule has a different -M argument (0640) than what they assign to normal floppy devices (fd[0-9]* -- they assign 0660), which is wrong. I've asked at least once about it, and gotten no response...

11. The doc/ directory looks quite out of date/incomplete.

Heh. Um, yeah. That was up to date and complete well before 55-udev-default.rules even existed, but has been bit-rotting ever since then. If I get a couple of weeks of time to plug away at updating it, I will. Otherwise, I'm not sure what to do with it... :-(

[Matthew Burgess]

Now Udev-135. Release announcement at ​http://marc.info/?l=linux-hotplug&m=122818259301735&w=2. It's got a couple of bug fixes and some infiniband rule additions. The 1st bug in the rules for this version is reported at ​http://marc.info/?l=linux-hotplug&m=122824851323088&w=2 (it affects ISDN devices) and a fix has already been applied upstream (see ​http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=1ac8fad8e56097cf8e08a0a17f044309317cb50f;hp=3e18fb062f16e99cd3b308089f1459f4eeb33003).

[Matthew Burgess]

Fixed in r8768. I'll raise a separate ticket for getting LFS' configuration in-line with upstream rules.