On Fri, 2008-12-19 at 17:03 +0100, Kay Sievers wrote: > > scd/sr > > > > while the kernel still calls them sr, that prefix is deprecated. You > > symlink the new name to the old one, we do it the other way around to > > make it clearer: > > > > SUBSYSTEM=="block", KERNEL=="sr[0-9]*", NAME="scd%n", SYMLINK+="sr% > > We do not want to change kernel names unless absolutely needed, > especially for block devices we don't want to do that. > > Where does the "deprecated prefix" information comes from? We should > check with the kernel SCSI maintainers, and then do this, if it's the > right thing. > We set this up as devices.txt says to, with the name as the non-deprecated one. > > rtc > > > > our rtc rules are more careful about only symlinking the CMOS > > to /dev/rtc: > > > > SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos", SYMLINK+="rtc" > > Sounds fine if we do not want that for other drivers? It's only > compatibility for old x86 behavior? > As far as I know, I talked with the upstream about it for a while before adding the rule. > > additionally, we place these in the "audio" group > > > > SUBSYSTEM=="rtc", GROUP="audio" > > Hmm, that sounds like a really weird workaround of some audio problem. > Is this really what we want. :) > Actually, drop this one. We don't want it anymore. > > raw1394 > > > > This should be in the "disk" group, not the "video" group; it can be > > used to execute code as root > > It may not belong into be in the "video" group, but you definitely also > don't want to put anybody in the "disk" group to access it, it's almost > the same as being root. We can leave it as root, if we need to change it > for security measures. > > You can not execute code on the host, only on a device, which may be > another box connected over firewire, right? > Loopback cable? This is something our security guy and kernel maintainer (who is the upstream maintainer of the old firewire system) felt strongly about -- obviously new firewire stack is much better anyway. > > you also don't rename some devices, and thus disagree > > > > KERNEL=="controlC[0-9]*", NAME="snd/%k" > > KERNEL=="hwC[D0-9]*", NAME="snd/%k" > > KERNEL=="midiC[D0-9]*", NAME="snd/%k" > > KERNEL=="pcmC[D0-9cp]*", NAME="snd/%k" > > KERNEL=="seq", NAME="snd/%k" > > KERNEL=="timer", NAME="snd/%k" > > That's in packages/40-alsa.rules. We do not carry it in the default udev > rules, but in the alsa package. > These aren't installed by default, right? If we're all using the same rules, is there any reason not to? > > symlinks > > > > you have lots of extra symlinks, any particular reason? are you paid > > by the symlink? :p > > > > X0R -> null ??!! WTF > > It's in devices.txt. :) Harald wanted it. :) > I'm ok with it if it's in devices.txt :p > > vbi -> vbi0 > > radio -> radio0 > > video -> video0 > > That is needed for some old tools. People have complained. > We've not had these, and nobody complains too loudly ;) I want to avoid adding legacy symlinks to our config if I can help it, because people then will complain if they go away again later :p > > no /dev/pilot? :) > > No, that doesn't work reliably, you never know which port is the right > one. It can not be done with udev today, only with a specific > vendor/device list match. > See vbi, radio, video, etc. above :p you can't have them and complain about this ;) I'd rather have none of them, and leave legacy/deprecated symlinks to distro-specific rules. > > tty 620 instead of 600? your ttys are writable? > > No idea. Just change it? > wall/write related. I'm happy to change to your default. > > groups > > > > no cdrom group? > > no scanner group? > > no tape group? > > no dialout group? - this may be Debianish, but we rely on it > > We do not want to put users in any such groups, but use dynamically > assigned and managed ACLs for it. We use groups only for easy setups of > system daemons like "video", for a streaming server and such. These > groups do not make much sense for Fedora or SUSE, and you may want > to put them in your own rules, in cases we don't find a common solution. > Agree, we can handle these in our own rules. Scott -- Scott James Remnant scott@xxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
