From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott James Remnant Date: Mon, 22 Dec 2008 16:02:25 +0000 Subject: Re: Moving Ubuntu to upstream udev rules (Part 2) Message-Id: <1229961745.6944.76.camel@quest> MIME-Version: 1 Content-Type: multipart/mixed; boundary="=-iOLbEkrkA7OfXtDx0yXx" List-Id: References: <1229955629.6944.63.camel@quest> In-Reply-To: <1229955629.6944.63.camel@quest> To: linux-hotplug@vger.kernel.org --=-iOLbEkrkA7OfXtDx0yXx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-12-22 at 16:30 +0100, Kay Sievers wrote: > On Mon, Dec 22, 2008 at 15:20, Scott James Remnant wro= te: > > This will still be difficult for me to upload with ;) > > > > - SUBSYSTEM=3D=3D"block", KERNEL=3D=3D"sr[0-9]*", SYMLINK+=3D"scd%n" > > + SUBSYSTEM=3D=3D"block", KERNEL=3D=3D"sr[0-9]*", NAME=3D"scd%n", SYML= INK+=3D"%k" > > > > I still think we have this round the right way! :-) >=20 > devices.txt is in no way "right" for everything, that section is from > the 2.4 days, and may not mean anything today. I'll wait for the SCSI > guys to tell. We should not switch names if there will never be a scd* > device in the kernel, because that would mean that sr* is the default, > and scd* is the legacy. I'll come back as soon as I got an answer. >=20 No problem, will wait for that :) > > you said it was only there because of the legacy ptys, which we've > > both disabled now? >=20 > We set them to 0, and they can be requested on the boot command line. > We have not heard anyone using it so far. Here is the option: > http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3D= blob;f=3DDocumentation/kernel-parameters.txt;h=3De0f346d201edb70fae654c55f6= be842c4465a5ff;hb=3DHEAD#l1808 >=20 We found one, an abandoned "ttyd" project; but so not caring about that. http://kernel.ubuntu.com/git?p=3Dubuntu/ubuntu-jaunty.git;a=3Dcommitdiff;h= =3D4e79291096b0d6adc9726607c8f6b7df736a877e > > - KERNEL=3D=3D"tun", NAME=3D"net/%k", MODE=3D"0666", OPTIONS+=3D"ignor= e_remove" > > + KERNEL=3D=3D"tun", NAME=3D"net/%k" > > > > The mode seems rather permissive? Do you really allow any user to > > make tunnels by default? (Ours is 0600!) >=20 > Hmm, I don't know. I see Ubuntu users complaining on the net, who use > virtualization not running as root. But if it's unsafe we should > change that. >=20 It's an interesting question actually, since you can make an ssh tunnel anyway. Kernel docs say it's ok to be 0666 since you need CAP_NET_ADMIN anyway - so 666 it is. > > Isn't the ignore_remove already handled by the /lib/udev/devices > > check? Our /dev/net/tun is in there. >=20 > Yeah, because it sets NAME=3D earlier to place it in the subdirectory. > The current check only covers devices which have NAME=3D set. >=20 Slightly confused. The general ignore_remove rule looks like: ACTION=3D=3D"remove", NAME=3D=3D"?*", TEST=3D=3D"/lib/udev/devices/$name", = \ OPTIONS+=3D"ignore_remove" Does this mean that this rule does nothing if the name isn't changed? Want to understand where we need the ignore_remove option on rules, or what is caught by this one. > > - KERNEL=3D=3D"mem|kmem|port|nvram", GROUP=3D"kmem", MODE=3D"0640" > > + KERNEL=3D=3D"mem|kmem|port", GROUP=3D"kmem", MODE=3D"0640" > > + KERNEL=3D=3D"nvram", GROUP=3D"nvram", MODE=3D"0640" > > > > We have the nvram group, no idea why, we just do ;) >=20 > Hmm, if there is a good reason. Maybe just drop "nvram", and wait if > anybody complains? >=20 Yeah, I think I'll probably just do that -- the udev package is what creates the nvram group in the first place, so I suspect this is just something we picked up from Debian once and never threw away. I'll drop this. > > - SUBSYSTEM=3D=3D"block", GROUP=3D"disk" > > + SUBSYSTEM=3D=3D"block", ATTRS{removable}!=3D"1", GROUP=3D"disk" > > + SUBSYSTEM=3D=3D"block", ATTRS{removable}=3D=3D"1", GROUP=3D"floppy" > > > > We put removable block devices in the floppy group, you leave them in > > disk? (But use the floppy group for real floppies?) >=20 > Putting gigabyte-big USB hard disks in the "floppy" group? Also some > ATA/SCSI storage controller are marked as removable. I don't think we > want that in the defaults. :) >=20 Fair point ;) I'll drop this. (cdrom/tape pending Harald's reply) > > rules/rules.d/80-drivers.rules: > > > > - SUBSYSTEM=3D=3D"module", KERNEL=3D=3D"parport_pc", \ > > - RUN+=3D"/sbin/modprobe -b ppdev" > > > > We don't have this one? What's this for? Is a module missing a > > dependency? >=20 > It's for legacy parallel port, yes. Nobody will fix the kernel. Not > sure why we needed it and you don't. You have that as a loadable > module? >=20 Figured it out, it's loaded by our "cups" init script. *sigh* Clearly we need this, then I can eliminate a non-udev call to modprobe. > > rules/packages/40-isdn.rules: > > > > - SUBSYSTEM=3D=3D"capi", KERNEL=3D=3D"capi", NAME=3D"capi20", \ > > - SYMLINK+=3D"isdn/capi20", GROUP=3D"uucp" > > + SUBSYSTEM=3D=3D"capi", KERNEL=3D=3D"capi", NAME=3D"capi20", \ > > + GROUP=3D"uucp" > > > > What uses the /dev/isdn/capi20 symlink? We've never had that, and > > I've never had any bug reports. >=20 > The old ISDN drivers are pretty much dead. But I've seen bugs about > /dev/capi20, and it seems used: > http://www.google.com/codesearch?hl=3Den&sa=3DN&q=3D/dev/capi20++lang:c= &ct=3Drr&cs_r=3Dlang:c >=20 Right, but is /dev/isdn/capi20 used? We don't have that symlink right now, just /dev/capi20 (Nit-picky, I know, but the fewer symlinks and the more fixed software the better! :p) [dialout] > If we can not agree on a default, we can do an option, but we do > nobody a favor who works on an upstream project and who needs to find > the differences again. So, I'm all for finding a common solution, For > me it would not be a problem to use "dialout" if that is what we want. > Harald? >=20 There's enough legacy stuff in Debian and Ubuntu that assumes dialout (the entire PPP script maintenance, etc.) that I wouldn't want to use uucp for it -- especially since dialout is a more descriptive group anyway. Scott --=20 Scott James Remnant scott@ubuntu.com --=-iOLbEkrkA7OfXtDx0yXx 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) iEYEABECAAYFAklPuhEACgkQSnQiFMl4yK5f/gCZAcZelewv9/tv9C9yMG/WPOK/ A0AAn0Vq1dwOYwXfnDMzv5sZ1eWkXZ9c =6hKW -----END PGP SIGNATURE----- --=-iOLbEkrkA7OfXtDx0yXx--