Re: Moving Ubuntu to upstream udev rules (Part 2)

[Scott James Remnant <scott@ubuntu.com>]

[-- Attachment #1: Type: text/plain, Size: 5611 bytes --]

On Mon, 2008-12-22 at 16:30 +0100, Kay Sievers wrote:

> On Mon, Dec 22, 2008 at 15:20, Scott James Remnant <scott@ubuntu.com> 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@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]