On Fri, 2008-12-19 at 06:47 +0000, Scott James Remnant wrote:
> Have been going through our udev rules and comparing them to those in
> the package as the upstream rules, and have noted about a page of things
> either we need to change or need to change in the upstream rules.
>
> Some of these I care about, some of them I'm not fussed - but we should
> at least chat about them.
>
>
> modprobe called without -b:
>
> without -b, the modprobe calls in udev are not checked against the
> blacklist, making it damned hard to disable automatic module loading
>
> please add -b to the modprobe calls.
Done.
> ide-scsi
>
> discussed on IRC, DO NOT WANT
The driver is dead, and the rule removed.
> ch
>
> this scsi driver (tape changers) is missing a modalias, the following
> rule is needed to load it (or a kernel patch):
>
> SUBSYSTEM=="scsi", ATTR{type}=="8", RUN+="/sbin/modprobe -b ch"
The ch module should get an alias:
scsi:t-0x09*
instead. I added the rule for now, but it should be removed when it's in
the kernel.
> tifm
>
> your rules are less careful than ours, we do:
>
> SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", RUN+="/sbin/modprobe
> -b tifm_sd"
> SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", RUN+="/sbin/modprobe
> -b tifm_ms"
Added. :)
> firmware
>
> if we don't copy the default rules into the initramfs (to get around
> the many GROUP= in there), we still need to load firmware.
>
> could this rule be separated out into a different file?
Done.
> 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.
> 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?
> 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. :)
> dv1394
>
> I couldn't work out why you symlink the kernelish names to their
> proper names, should this not be:
>
> KERNEL=="dv1394*", NAME="dv1394/%n"
Same here, there was no clear rule, and we seem to need both, and then
we usually do not switch names and links around if we have both anyway.
But I don't mind here to do that, this driver is almost dead anyway, and
will go some day.
> 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?
> names
>
> you rename some devices and disagree with devices.txt
>
> rawctl -> raw/rawctl
The tools use that, if I remember. Someone maintaining the tools should
tell, devices.txt is pretty unreliable sometimes.
> 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.
> KERNEL=="device-mapper", NAME="mapper/control"
It's only in suse/64-device-mapper.rules, because upstream device-mapper
does not integrate with udev. The rules belong into the dmsetup package.
Ubuntu carries the "dmsetup export" patch, so I have no problem moving a
copy to the packages directory, and let the Red Hat guys find out when
they want to fix their stuff. :)
> KERNEL=="capi", NAME="capi20"
> KERNEL=="capi[0-9]*", NAME="capi/%n"
It's in the packages/40-isdn.rules rules, they are installed with the
ISDN tools.
> KERNEL=="zapctl", NAME="zap/ctl"
> KERNEL=="zaptimer", NAME="zap/timer"
> KERNEL=="zapchannel", NAME="zap/channel"
> KERNEL=="zappseudo", NAME="zap/pseudo"
> KERNEL=="zap[0-9]*", NAME="zap/%n"
That driver is dead, and renamed to something else. These rules are in:
packages/40-zaptel.rules though.
> 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. :)
> ramdisk -> ram0
> ram -> ram1
> lirc -> lirc0
> js* -> input/js* - aren't these different kernel drivers?
I have no idea. Maybe remove them? Harald?
> vbi -> vbi0
> radio -> radio0
> video -> video0
That is needed for some old tools. People have complained.
> fb -> fb0
> par* -> lp* ??
> ftape -> qft0
No idea. Harald?
> hw_random -> hwrng - we just rename, and don't symlink the old name
Sounds fine.
> sbpcd -> sbpcd0
> xpram* -> slram*
No idea, never seen. Remove it and wait for someone to complain? Harald?
> sxctl -> specialix_sxctl - shouldn't this be just a rename?
> rioctl -> specialix_rioctl - shouldn't this be just a rename?
Maybe just rename it, yeah.
> 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.
> permissions
>
> dri/card* 666 ???!!!
> fuse 666 ???!!!
No idea.
> bus/usb/* 644 instead of 664?
We intentionally don't do group assignment here, so we can change the
permission if you need it.
> tty 620 instead of 600? your ttys are writable?
No idea. Just change it?
> 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.
> no audio group?
This group is used in alsa rules.
> ppdev devices not in the lp group?
Sounds like they should.
> nvram in group kmem not nvram?
No idea what's "right" here.
I changed some things and pushed it out to git.
Care to check the list again, and collect the remaining things for the
next step? Then we can check with Harald what we can remove or change?
Thanks for doing this, looking forward to a more unified setup!
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
