From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott James Remnant Date: Mon, 22 Dec 2008 09:39:42 +0000 Subject: Re: Moving Ubuntu to upstream udev rules Message-Id: <1229938782.6944.12.camel@quest> MIME-Version: 1 Content-Type: multipart/mixed; boundary="=-iXwEHnUtAua/DdZBfa0j" List-Id: References: <1229669228.14012.30.camel@quest> In-Reply-To: <1229669228.14012.30.camel@quest> To: linux-hotplug@vger.kernel.org --=-iXwEHnUtAua/DdZBfa0j Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-12-19 at 17:03 +0100, Kay Sievers wrote: > > scd/sr > >=20 > > 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: > >=20 > > SUBSYSTEM=3D=3D"block", KERNEL=3D=3D"sr[0-9]*", NAME=3D"scd%n", SYM= LINK+=3D"sr% >=20 > We do not want to change kernel names unless absolutely needed, > especially for block devices we don't want to do that. >=20 > 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. >=20 We set this up as devices.txt says to, with the name as the non-deprecated one. > > rtc > >=20 > > our rtc rules are more careful about only symlinking the CMOS > > to /dev/rtc: > >=20 > > SUBSYSTEM=3D=3D"rtc", DRIVERS=3D=3D"rtc_cmos", SYMLINK+=3D"rtc" >=20 > Sounds fine if we do not want that for other drivers? It's only > compatibility for old x86 behavior? >=20 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 > >=20 > > SUBSYSTEM=3D=3D"rtc", GROUP=3D"audio" >=20 > Hmm, that sounds like a really weird workaround of some audio problem. > Is this really what we want. :) >=20 Actually, drop this one. We don't want it anymore. > > raw1394 > >=20 > > This should be in the "disk" group, not the "video" group; it can be > > used to execute code as root >=20 > 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. >=20 > You can not execute code on the host, only on a device, which may be > another box connected over firewire, right? >=20 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 > >=20 > > KERNEL=3D=3D"controlC[0-9]*", NAME=3D"snd/%k" > > KERNEL=3D=3D"hwC[D0-9]*", NAME=3D"snd/%k" > > KERNEL=3D=3D"midiC[D0-9]*", NAME=3D"snd/%k" > > KERNEL=3D=3D"pcmC[D0-9cp]*", NAME=3D"snd/%k" > > KERNEL=3D=3D"seq", NAME=3D"snd/%k" > > KERNEL=3D=3D"timer", NAME=3D"snd/%k" >=20 > That's in packages/40-alsa.rules. We do not carry it in the default udev > rules, but in the alsa package. >=20 These aren't installed by default, right? If we're all using the same rules, is there any reason not to? > > symlinks > >=20 > > you have lots of extra symlinks, any particular reason? are you paid > > by the symlink? :p > >=20 > > X0R -> null ??!! WTF >=20 > It's in devices.txt. :) Harald wanted it. :) >=20 I'm ok with it if it's in devices.txt :p > > vbi -> vbi0 > > radio -> radio0 > > video -> video0 >=20 > That is needed for some old tools. People have complained. >=20 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? :) >=20 > 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. >=20 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? >=20 > No idea. Just change it? >=20 wall/write related. I'm happy to change to your default. > > groups > >=20 > > no cdrom group? > > no scanner group? > > no tape group? > > no dialout group? - this may be Debianish, but we rely on it >=20 > 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. >=20 Agree, we can handle these in our own rules. Scott --=20 Scott James Remnant scott@canonical.com --=-iXwEHnUtAua/DdZBfa0j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklPYF4ACgkQSnQiFMl4yK4yMwCglaaLl93nfa6DjgTz/3EAopQq 0pUAnjThGkVwYk0KpnmcmCOZWBIDxoQJ =JbDT -----END PGP SIGNATURE----- --=-iXwEHnUtAua/DdZBfa0j--