Opened 16 years ago
Closed 16 years ago
#2297 closed task (fixed)
Use upstream Udev rules whenever appropriate
| Reported by: | Matthew Burgess | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.5 |
| Component: | Book | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
From #2284:
Ideally, we should use the rules that Udev provide. Where we have identified differences that are useful to us, these should be passed upstream as a patch, unless they are LFS-specific. In that case, these should be patches against upstream rules. This will allow us to drop the udev-config tarball.
As a first stage, we should look at removing any rules in LFS that duplicate those already being supplied in the upstream tarball. See comment:9:ticket:2284 for further details on which rules can currently be removed.
Change History (13)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
CAPI devices moved to upstream rules, and uucp vs. dialout group names fixed, in r8841.
follow-up: 5 comment:3 by , 16 years ago
Bryan,
I've taken another look at the rules this evening and removed what I think were duplicates in r8877 & r8878. Here's what I think are left to figure out:
random=0444 (LFS), 0666 (udev) urandom=0444 (LFS), 0666 (udev) aio=0444 (LFS), 0660 (udev - default) kmsg=0600 (LFS), 0660 (udev - default) rtc=0666 (LFS), 0660 (udev - default) mice=0644 (LFS), 0640 (udev) mouse=0644 (LFS), 0640 (udev) event=0644 (LFS), 0640 (udev) ts=0644 (LFS), 0640 (udev)
Much like our patches, I'd like it if we could either submit these rules upstream, if there's good reason for having them, or adopt upstream's rules.
comment:4 by , 16 years ago
| Milestone: | 7.0 → 6.5 |
|---|
comment:5 by , 16 years ago
Replying to matthew@…:
I've taken another look at the rules this evening and removed what I think were duplicates in r8877 & r8878.
The changes look good (for what that's worth... ;-) ).
random=0444 (LFS), 0666 (udev)
urandom=0444 (LFS), 0666 (udev)
Depends on whether writing non-random data into these files can compromise the kernel RNG. Wikipedia claims no, since there's no way to artificially increase the entropy estimate inside the kernel without being root, and presumably it's a kernel bug if writing non-random data (that looks random) into the pool causes predictable output. So these can probably go.
aio=0444 (LFS), 0660 (udev - default)
Hmm. I presume async I/O is useful to all users. Does it need to be writable? Never tried to use it...
(Does it even exist anymore? My system doesn't have it: 2.6.29.2, though with some odd compile options. Maybe this entry is irrelevant now.)
kmsg=0600 (LFS), 0660 (udev - default)
Depends on whether you trust group root. (Heh.) I think this can be dropped.
rtc=0666 (LFS), 0660 (udev - default)
Hmm; my /dev/rtc is a symlink to rtc0, which is 0660, root/timer (...I think pieces of this have come up before). I'm in the timer group. It also looks like that's something I added, though; I don't see the group in upstream rules or udev-config.
mplayer definitely benefits from being able to read and write the file; 0666 or a timer group would be preferred for that. OTOH, changing the system clock (if possible; I believe it would be with a writable /dev/rtc) is bad.
mice=0644 (LFS), 0640 (udev)
mouse=0644 (LFS), 0640 (udev)
event=0644 (LFS), 0640 (udev)
ts=0644 (LFS), 0640 (udev)
Since X and gpm both run as root (gpm because it's launched from bootscripts, X because it's setuid-root), these probably don't matter?
comment:6 by , 16 years ago
Removed overrides for random, urandom, kmsg, and input devices in r8891.
Still left: aio and rtc. Anyone know whether /dev/aio still exists? Opinions on rtc?
follow-up: 9 comment:7 by , 16 years ago
aio is not in the RedHat or Ubuntu instances I have access to. I'd just drop it from 55-lfs.rules.
RedHat leaves rtc as 644 (the default). Ubuntu has it as crw-rw---- 1 root audio 10, 135 May 15 10:18 /dev/rtc
If we come across an application in blfs, we can always address the rtc issue there. I'd say just go with the udev default there too.
comment:8 by , 16 years ago
More on rtc:
Ubuntu has 40-permissions.rules:
KERNEL=="rtc", GROUP="audio"
It also has 85-hwclock.rules
KERNEL=="rtc", ACTION=="add", RUN+="set_hwclock"
This may be useful in addressing #2266
follow-up: 10 comment:9 by , 16 years ago
Replying to bdubbs@…:
RedHat leaves rtc as 644 (the default).
Hmm; the default is 0660, isn't it? Or did they patch their udev to change that?
Ubuntu has it as
crw-rw---- 1 root audio 10, 135 May 15 10:18 /dev/rtc
That's an option: the audio group is probably close enough to my "timer" group to work.
Replying to bdubbs@…:
More on rtc:
Ubuntu has 40-permissions.rules:
KERNEL=="rtc", GROUP="audio"
It also has 85-hwclock.rules
KERNEL=="rtc", ACTION=="add", RUN+="set_hwclock"
Both of those will need to be duplicated for SUBSYSTEM=="rtc" (instead of KERNEL==) to get it to work right with the new(ish) rtc-cmos and friends. (Of course, the "friends" are mostly the RTC chips on embedded devices...)
This may be useful in addressing #2266
Yeah, with a few modifications to the script. I'll comment there.
follow-up: 11 comment:10 by , 16 years ago
comment:11 by , 16 years ago
Replying to bdubbs@…:
RH has /etc/udev/rules.d/50-udev.rules:KERNEL=="rtc", MODE="0644"
OK, I'd be fine with either 0644 or keeping my own custom GROUP="timer". Making it readable is enough for mplayer (just tested).
comment:12 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
First stage is done (I believe) in r8770.
That's all of the changes (I believe) that cause zero runtime differences, at least. The insignificant runtime differences are still up for inclusion. (E.g., I know that removing our rule that changes permissions on /dev/rtc won't cause problems, at least not with mplayer. There are a few others.)