linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).