Patches for device names

Patches for device names

[Scott James Remnant]

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

Before I get patching, I wanted to get a consensus about what the best
patches would be, since there's a few options:

 a) kernel names match LANANA, using ! instead of /

		ACTION=add
		DEVPATH=/class/input/mice
		SUBSYSTEM=input
		MAJOR=13
		MINOR=63

	Pro: simplest, ! -> / already supported by udev
	Con: looks strange in sysfs;
	     /class/input/mice becomes /class/input/input!mice;
	     backwards compatibility?
		- we can match NAME=="input/mice" for permissions,
		  this works for both!

 b) kernel names remain the same, include DEVNAME in environment

		ACTION=add
		DEVPATH=/class/input/mice
		DEVNAME=/dev/input/mice
		SUBSYSTEM=input
		MAJOR=13
		MINOR=63

	Pro: fixes sysfs and compatibility, attractive
	Con: udev needs patching, extra macro in kernel

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: Patches for device names

[H. Peter Anvin]

Scott James Remnant wrote:
> 
>  b) kernel names remain the same, include DEVNAME in environment
> 
> 		ACTION­d
> 		DEVPATH=/class/input/mice
> 		DEVNAME=/dev/input/mice
> 		SUBSYSTEM=input
> 		MAJOR\x13
> 		MINORc
> 
> 	Pro: fixes sysfs and compatibility, attractive
> 	Con: udev needs patching, extra macro in kernel
> 

In this case, I would also argue we need devname in sysfs.  There are 
enough tools out there who want to be able to correlate sysfs and devices.

	-hpa

Re: Patches for device names

[Greg KH]

On Wed, Aug 13, 2008 at 10:31:06AM -0700, H. Peter Anvin wrote:
> Scott James Remnant wrote:
>>  b) kernel names remain the same, include DEVNAME in environment
>> 		ACTION­d
>> 		DEVPATH=/class/input/mice
>> 		DEVNAME=/dev/input/mice
>> 		SUBSYSTEM=input
>> 		MAJOR\x13
>> 		MINORc
>> 	Pro: fixes sysfs and compatibility, attractive
>> 	Con: udev needs patching, extra macro in kernel
>
> In this case, I would also argue we need devname in sysfs.  There are 
> enough tools out there who want to be able to correlate sysfs and devices.

So the kernel should cache this information?  That's a mess, why do that
when userspace already has this mapping (udevinfo provides it).  We
already have a mapping from device major/minor already in sysfs as well.

So why would the kernel need to care about this?

thanks,

greg k-h

Re: Patches for device names

[Greg KH]

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?

thanks,

greg k-h

Re: Patches for device names

[Scott James Remnant]

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

On Wed, 2008-08-13 at 10:31 -0700, H. Peter Anvin wrote:

> Scott James Remnant wrote:
> > 
> >  b) kernel names remain the same, include DEVNAME in environment
> > 
> > 		ACTION=add
> > 		DEVPATH=/class/input/mice
> > 		DEVNAME=/dev/input/mice
> > 		SUBSYSTEM=input
> > 		MAJOR=13
> > 		MINOR=63
> > 
> > 	Pro: fixes sysfs and compatibility, attractive
> > 	Con: udev needs patching, extra macro in kernel
> > 
> 
> In this case, I would also argue we need devname in sysfs.  There are 
> enough tools out there who want to be able to correlate sysfs and devices.
> 
That's what DeviceKit is for.

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: Patches for device names

[Scott James Remnant]

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

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?

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: Patches for device names

[Greg KH]

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?  :)

Becides input, what other subsystem do you see such kernel changes being
needed for?

thanks,

greg k-h

Re: Patches for device names

[H. Peter Anvin]

Greg KH wrote:
> 
> So the kernel should cache this information?  That's a mess, why do that
> when userspace already has this mapping (udevinfo provides it).  We
> already have a mapping from device major/minor already in sysfs as well.
> 
> So why would the kernel need to care about this?
> 

Fair enough.

Now, calling udevinfo is quite expensive; is this information available 
through a programmatic API?

	-hpa

Re: Patches for device names

[Scott James Remnant]

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

On Wed, 2008-08-13 at 11:22 -0700, H. Peter Anvin wrote:

> Greg KH wrote:
> > 
> > So the kernel should cache this information?  That's a mess, why do that
> > when userspace already has this mapping (udevinfo provides it).  We
> > already have a mapping from device major/minor already in sysfs as well.
> > 
> > So why would the kernel need to care about this?
> > 
> 
> Fair enough.
> 
> Now, calling udevinfo is quite expensive; is this information available 
> through a programmatic API?
> 
http://hal.freedesktop.org/docs/DeviceKit/

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: Patches for device names

[David Zeuthen]

On Wed, 2008-08-13 at 19:33 +0100, Scott James Remnant wrote:
> > Now, calling udevinfo is quite expensive; is this information available 
> > through a programmatic API?
> > 
> http://hal.freedesktop.org/docs/DeviceKit/

We also might want a libudev shared library for those allergic to D-Bus
(not to mention for the implementation of devkit-daemon(1)).

     David

Re: Patches for device names

[Kay Sievers]

On Wed, 2008-08-13 at 11:22 -0700, H. Peter Anvin wrote:
> Greg KH wrote:
> > 
> > So the kernel should cache this information?  That's a mess, why do that
> > when userspace already has this mapping (udevinfo provides it).  We
> > already have a mapping from device major/minor already in sysfs as well.
> > 
> > So why would the kernel need to care about this?
> > 
> 
> Fair enough.
> 
> Now, calling udevinfo is quite expensive; is this information available 
> through a programmatic API?

Not directly to udev, because all higher level stuff uses HAL. We could
create a shared library that offers access to the udev database, but
there was no real need for that.

Thanks,
Kay

Re: Patches for device names

[Kay Sievers]

On Wed, 2008-08-13 at 10:31 -0700, H. Peter Anvin wrote:
> Scott James Remnant wrote:
> > 
> >  b) kernel names remain the same, include DEVNAME in environment
> > 
> > 		ACTION­d
> > 		DEVPATH=/class/input/mice
> > 		DEVNAME=/dev/input/mice
> > 		SUBSYSTEM=input
> > 		MAJOR\x13
> > 		MINORc
> > 
> > 	Pro: fixes sysfs and compatibility, attractive
> > 	Con: udev needs patching, extra macro in kernel
> > 
> 
> In this case, I would also argue we need devname in sysfs.  There are 
> enough tools out there who want to be able to correlate sysfs and devices.

Maybe better than nothing, yeah, but the basic /dev name is in a lot of
cases not too interesting, but the symlinks are, and they will not be
known by the kernel.

Kay

Re: Patches for device names

[Scott James Remnant]

[-- 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 --]

Re: Patches for device names

[H. Peter Anvin]

Scott James Remnant wrote:
> 
> Simply have the wrong name:
> 
> 	sr[0-9]*		scd[0-9]*
> 

This one is an interesting variant.  The origin of this one is actually 
due to Red Hat (specifically) ignoring the consensus of the kernel 
developers.

	-hpa