On Mon, 2008-12-22 at 16:30 +0100, Kay Sievers wrote: > On Mon, Dec 22, 2008 at 15:20, Scott James Remnant <scott@xxxxxxxxxx> wrote: > > This will still be difficult for me to upload with ;) > > > > - SUBSYSTEM=="block", KERNEL=="sr[0-9]*", SYMLINK+="scd%n" > > + SUBSYSTEM=="block", KERNEL=="sr[0-9]*", NAME="scd%n", SYMLINK+="%k" > > > > I still think we have this round the right way! :-) > > 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. > No problem, will wait for that :) > > you said it was only there because of the legacy ptys, which we've > > both disabled now? > > 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=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kernel-parameters.txt;h=e0f346d201edb70fae654c55f6be842c4465a5ff;hb=HEAD#l1808 > We found one, an abandoned "ttyd" project; but so not caring about that. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commitdiff;h=4e79291096b0d6adc9726607c8f6b7df736a877e > > - KERNEL=="tun", NAME="net/%k", MODE="0666", OPTIONS+="ignore_remove" > > + KERNEL=="tun", NAME="net/%k" > > > > The mode seems rather permissive? Do you really allow any user to > > make tunnels by default? (Ours is 0600!) > > 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. > 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. > > Yeah, because it sets NAME= earlier to place it in the subdirectory. > The current check only covers devices which have NAME= set. > Slightly confused. The general ignore_remove rule looks like: ACTION=="remove", NAME=="?*", TEST=="/lib/udev/devices/$name", \ OPTIONS+="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=="mem|kmem|port|nvram", GROUP="kmem", MODE="0640" > > + KERNEL=="mem|kmem|port", GROUP="kmem", MODE="0640" > > + KERNEL=="nvram", GROUP="nvram", MODE="0640" > > > > We have the nvram group, no idea why, we just do ;) > > Hmm, if there is a good reason. Maybe just drop "nvram", and wait if > anybody complains? > 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=="block", GROUP="disk" > > + SUBSYSTEM=="block", ATTRS{removable}!="1", GROUP="disk" > > + SUBSYSTEM=="block", ATTRS{removable}=="1", GROUP="floppy" > > > > We put removable block devices in the floppy group, you leave them in > > disk? (But use the floppy group for real floppies?) > > 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. :) > Fair point ;) I'll drop this. (cdrom/tape pending Harald's reply) > > rules/rules.d/80-drivers.rules: > > > > - SUBSYSTEM=="module", KERNEL=="parport_pc", \ > > - RUN+="/sbin/modprobe -b ppdev" > > > > We don't have this one? What's this for? Is a module missing a > > dependency? > > 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? > 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=="capi", KERNEL=="capi", NAME="capi20", \ > > - SYMLINK+="isdn/capi20", GROUP="uucp" > > + SUBSYSTEM=="capi", KERNEL=="capi", NAME="capi20", \ > > + GROUP="uucp" > > > > What uses the /dev/isdn/capi20 symlink? We've never had that, and > > I've never had any bug reports. > > 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=en&sa=N&q=/dev/capi20++lang:c&ct=rr&cs_r=lang:c > 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? > 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 -- Scott James Remnant scott@xxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
