From: Scott James Remnant <scott@canonical.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Patches for device names
Date: Wed, 13 Aug 2008 19:33:30 +0000 [thread overview]
Message-ID: <1218656010.6882.94.camel@quest> (raw)
In-Reply-To: <1218648175.6882.63.camel@quest>
[-- Attachment #1: Type: text/plain, Size: 3794 bytes --]
On Wed, 2008-08-13 at 11:16 -0700, Greg KH wrote:
> On Wed, Aug 13, 2008 at 07:02:58PM +0100, Scott James Remnant wrote:
> > On Wed, 2008-08-13 at 10:50 -0700, Greg KH wrote:
> >
> > > On Wed, Aug 13, 2008 at 06:22:55PM +0100, Scott James Remnant wrote:
> > > > Before I get patching, I wanted to get a consensus about what the best
> > > > patches would be, since there's a few options:
> > >
> > > Wait, why do this at all?
> > >
> > > To get rid of a few udev rules that group things into subdirectories?
> > >
> > > Is that really a sane/wise/useful thing to do? Is your goal to get rid
> > > of _all_ udev rules by doing this? If not, then why worry about it?
> > >
> > To get rid of all udev rules that set a NAME based only on information
> > received from the kernel.
> >
> > Why waste cycles and resources constructing a static name just because
> > the kernel's static name doesn't match the standard?
>
> Because of history here? Can't you live with input devices having a few
> rules in udev? Is it really that hard to maintain? :)
>
Maybe I'm weird, but I don't see that we *should* live with it.
Why is the kernel sacred in such a way that means it's better to work
around the kernel than just fix the bloody thing?
If the standard says it's called "foo", and the distributions have
agreed on a single default naming and thus "foo", which udev knows as
"foo" ... why do we live with the kernel calling it "bar" ?
It's not just the input devices, so far I have the following list:
Simply have the wrong name:
capi capi20
capi[0-9]* capi20.[00-99]*
sr[0-9]* scd[0-9]*
hw_random hwrng
sxctl specialix_sxctl
rioctl specialix_rioctl
LANANA says they go in sub-directories:
device-mapper mapper/control
tun net/tun
mice input/mice
uinput input/uinput
mouse[0-9]* input/mouse[0-9]*
js[0-9]* input/js[0-9]*
ts[0-9]* input/ts[0-9]*
event[0-9]* input/event[0-9]*
dv1394-[0-9]* dv1394/[0-9]*
video1394-[0-9]* video1394/[0-9]*
seq snd/seq
timer snd/timer
controlC[0-9]* snd/controlC[0-9]*
hwC[D0-9]* snd/hwC[D0-9]*
midiC[D0-9]* snd/midiC[0-9]*
pcmC[D0-9cp]* snd/pcmC[D0-9cp]*
card[0-9]* dri/card[0-9]*
raw[0-9]* raw/raw[0-9]*
microcode cpu/microcode
cpu[0-9]* cpu/[0-9]*/cpuid
msr[0-9]* cpu/[0-9]*/msr
auer[0-9]* usb/auer[0-9]*
cpad[0-9]* usb/cpad[0-9]*
dabusb[0-9]* usb/dabusb[0-9]*
hiddev[0-9]* usb/hiddev[0-9]*
legousbtower[0-9]* usb/legousbtower[0-9]*
brlvgr[0-9]* usb/brlvgr[0-9]*
sisusbvga[0-9]* usb/sisusbvga[0-9]*
iowarrior[0-9]* usb/iowarrior[0-9]*
rio500 usb/rio500
usblcd usb/usblcd
idmouse usb/ud,mouse
lp[0-9]* (on USB) usb/lp[0-9]*
scanner[0-9]* (on USB) usb/scanner[0-9]*
mwave modems/mwave
umad[0-9]* infiniband/umad[0-9]*
issm[0-9]* infiniband/issm[0-9]*
uverbs[0-9]* infiniband/uverbs[0-9]*
ucm[0-9]* infiniband/ucm[0-9]*
rdma_cm infiniband/rdma_cm
zapctl zap/ctl
zaptimer zap/timer
zapchannel zap/channel
zappseudo zap/pseudo
zap[0-9]* zap/[0-9]*
discover (on aoe) etherd/discover
err (on aoe) etherd/err
interfaces (on aoe) etherd/interfaces
revalidate (on aoe) etherd/revalidate
pktcdvd pkctdvd/control
pktcdvd[0-9]* pkctdvd/pktcdvd[0-9]*
evtchn xen/evtchn
And the kernel has all the information, yet we have to spend time and
effort constructing a device name when this could just be in the uevent
as DEVNAME:
usb/[000-999]/[000-999]
dvb/adapter[0-9]*/NAME
And I found the following mistakes in the default rules (the translation
from the former to the latter is invalid according to LANANA):
rawctl raw/rawctl
Scott
--
Scott James Remnant
scott@canonical.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-08-13 19:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-13 17:22 Patches for device names Scott James Remnant
2008-08-13 17:31 ` H. Peter Anvin
2008-08-13 17:49 ` Greg KH
2008-08-13 17:50 ` Greg KH
2008-08-13 17:57 ` Scott James Remnant
2008-08-13 18:02 ` Scott James Remnant
2008-08-13 18:16 ` Greg KH
2008-08-13 18:22 ` H. Peter Anvin
2008-08-13 18:33 ` Scott James Remnant
2008-08-13 18:38 ` David Zeuthen
2008-08-13 18:52 ` Kay Sievers
2008-08-13 18:54 ` Kay Sievers
2008-08-13 19:33 ` Scott James Remnant [this message]
2008-08-13 20:00 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1218656010.6882.94.camel@quest \
--to=scott@canonical.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).