default udev rules

default udev rules

[Kay Sievers]

We like to remind everybody, that all distros should work towards a
default udev rules set, instead of maintaining their own home-grown
version of default rules. We should all unify as far as possible.
Red Hat, SUSE and Gentoo are already using the same rules files, with a
minimal rules set on top, in a distro specific file. We ask the rest of
the universe to join us, and do the same. :)

Please consider adapting the default rules now, and let us find a common
solution for everybody. New packages, like the upcoming DeviceKit-*
packages will depend on a recent udev with a proper rules setup.

Soon, we will remove all copies of (in some cases totally outdated)
distro rules from the udev source tree which contain their own default
rules. Sure, we can not force anybody to adapt the default rules, but
upstream udev will no longer support custom default rules with the
distributed sources, and carry very likely non-working rules for
packages which depend on a proper udev setup.

Thanks a lot,
Kay

Re: default udev rules

[Marco d'Itri]

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

On Aug 09, Kay Sievers <kay.sievers@vrfy.org> wrote:

> We like to remind everybody, that all distros should work towards a
> default udev rules set, instead of maintaining their own home-grown
Not going to happen, because:
- I consider my rules much more readable and elegant than yours
- anyway there are differences in the permissions (e.g. uucp vs. dialout)
- the default rules are unusable for Debian since we need to support
  older kernels (currently and until Xen dom0 will be supported by new
  kernels or obsoleted by KVM, >= 2.6.18)

> Please consider adapting the default rules now, and let us find a common
> solution for everybody. New packages, like the upcoming DeviceKit-*
> packages will depend on a recent udev with a proper rules setup.
You should formalize what "a proper rules setup" is, not make other
packages depend on the undocumented behaviour of a default configuration.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: default udev rules

[Greg KH]

On Sat, Aug 09, 2008 at 05:23:19PM +0200, Marco d'Itri wrote:
> On Aug 09, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > We like to remind everybody, that all distros should work towards a
> > default udev rules set, instead of maintaining their own home-grown
> Not going to happen, because:
> - I consider my rules much more readable and elegant than yours

Why not submit patches to get your versions into the upstream version if
they are much better?

> - anyway there are differences in the permissions (e.g. uucp vs. dialout)

Minor things like this should be resolved if possible.

> - the default rules are unusable for Debian since we need to support
>   older kernels (currently and until Xen dom0 will be supported by new
>   kernels or obsoleted by KVM, >= 2.6.18)

Why would the rules files be dependant on kernel versions?

thanks,

greg k-h

Re: default udev rules

[Marco d'Itri]

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

On Aug 09, Greg KH <greg@kroah.com> wrote:

> > - I consider my rules much more readable and elegant than yours
> Why not submit patches to get your versions into the upstream version if
> they are much better?
They are available and up to date in rules/debian/*, nobody ever
expressed any interest in this.

> > - anyway there are differences in the permissions (e.g. uucp vs. dialout)
> Minor things like this should be resolved if possible.
These are not minor things, so at best the common rules would need to
be patched.

> > - the default rules are unusable for Debian since we need to support
> >   older kernels (currently and until Xen dom0 will be supported by new
> >   kernels or obsoleted by KVM, >= 2.6.18)
> Why would the rules files be dependant on kernel versions?
Workarounds, etc.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: default udev rules

[Greg KH]

On Sat, Aug 09, 2008 at 09:30:59PM +0200, Marco d'Itri wrote:
> On Aug 09, Greg KH <greg@kroah.com> wrote:
> 
> > > - I consider my rules much more readable and elegant than yours
> > Why not submit patches to get your versions into the upstream version if
> > they are much better?
> They are available and up to date in rules/debian/*, nobody ever
> expressed any interest in this.

It seems they are now :)

Why not send patches?

> > > - anyway there are differences in the permissions (e.g. uucp vs. dialout)
> > Minor things like this should be resolved if possible.
> These are not minor things, so at best the common rules would need to
> be patched.

Like Kay pointed out, there are differences, like this, and that's fine,
but permissions on specific nodes are minor things.  Consistant names
are the real issue here.

> > > - the default rules are unusable for Debian since we need to support
> > >   older kernels (currently and until Xen dom0 will be supported by new
> > >   kernels or obsoleted by KVM, >= 2.6.18)
> > Why would the rules files be dependant on kernel versions?
> Workarounds, etc.

Such as?

thanks,

greg k-h

Re: default udev rules

[Kay Sievers]

On Sat, Aug 9, 2008 at 17:23, Marco d'Itri <md@linux.it> wrote:
> On Aug 09, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> We like to remind everybody, that all distros should work towards a
>> default udev rules set, instead of maintaining their own home-grown
> Not going to happen, because:
> - I consider my rules much more readable and elegant than yours

I see they look different, I can't really see any significant
difference in elegance. :) But sure, patches are always welcome.

> - anyway there are differences in the permissions (e.g. uucp vs. dialout)
> - the default rules are unusable for Debian since we need to support
>  older kernels (currently and until Xen dom0 will be supported by new
>  kernels or obsoleted by KVM, >= 2.6.18)

Gentoo does the same, and uses default rules just fine. Just
coordinate with them to generate an optional common rule for old
kernels, or it can all be done just fine in a 40-debian.rules file.

>> Please consider adapting the default rules now, and let us find a common
>> solution for everybody. New packages, like the upcoming DeviceKit-*
>> packages will depend on a recent udev with a proper rules setup.
> You should formalize what "a proper rules setup" is, not make other
> packages depend on the undocumented behaviour of a default configuration.

Sorry, too many things change too fast, and it may speed up even more
depending DeviceKit's progress, while we are moving stuff from HAL
(which will go away) to udev. If you use the default rules, you are
fine. :)

Thanks,
Kay

Re: default udev rules

[Scott James Remnant]

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

On Sat, 2008-08-09 at 12:21 +0200, Kay Sievers wrote:

> We like to remind everybody, that all distros should work towards a
> default udev rules set, instead of maintaining their own home-grown
> version of default rules. We should all unify as far as possible.
> Red Hat, SUSE and Gentoo are already using the same rules files, with a
> minimal rules set on top, in a distro specific file. We ask the rest of
> the universe to join us, and do the same. :)

The conflation of names and permissions in the default rules is a
problem for us, and why Ubuntu has not adopted them.

I'm also entirely unconvinced about putting rules in /lib instead
of /etc

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Marco d'Itri]

On Aug 09, Kay Sievers <kay.sievers@vrfy.org> wrote:

> I see they look different, I can't really see any significant
> difference in elegance. :) But sure, patches are always welcome.
What should be patched? Either you like mine and use them, or you like
your ones and use these.

> Sorry, too many things change too fast, and it may speed up even more
> depending DeviceKit's progress, while we are moving stuff from HAL
> (which will go away) to udev. If you use the default rules, you are
> fine. :)
This is a lousy excuse for the devkit developers not providing
documentation.

-- 
ciao,
Marco

Re: default udev rules

[Greg KH]

On Sun, Aug 10, 2008 at 07:07:54PM +0100, Scott James Remnant wrote:
> On Sat, 2008-08-09 at 12:21 +0200, Kay Sievers wrote:
> 
> > We like to remind everybody, that all distros should work towards a
> > default udev rules set, instead of maintaining their own home-grown
> > version of default rules. We should all unify as far as possible.
> > Red Hat, SUSE and Gentoo are already using the same rules files, with a
> > minimal rules set on top, in a distro specific file. We ask the rest of
> > the universe to join us, and do the same. :)
> 
> The conflation of names and permissions in the default rules is a
> problem for us, and why Ubuntu has not adopted them.

What do you mean by this?  Specifics please.

> I'm also entirely unconvinced about putting rules in /lib instead
> of /etc

Why?  Read-only things like udev rules can be in /lib just fine.

thanks,

greg k-h

Re: default udev rules

[Kay Sievers]

On Sun, 2008-08-10 at 19:07 +0100, Scott James Remnant wrote:
> On Sat, 2008-08-09 at 12:21 +0200, Kay Sievers wrote:
> 
> > We like to remind everybody, that all distros should work towards a
> > default udev rules set, instead of maintaining their own home-grown
> > version of default rules. We should all unify as far as possible.
> > Red Hat, SUSE and Gentoo are already using the same rules files, with a
> > minimal rules set on top, in a distro specific file. We ask the rest of
> > the universe to join us, and do the same. :)
> 
> The conflation of names and permissions in the default rules is a
> problem for us, and why Ubuntu has not adopted them.

Which names, which perms? Please just list them all, we will try to find
a common solution.

> I'm also entirely unconvinced about putting rules in /lib instead
> of /etc

Most udev rules are not config files, not supposed to be edited, and
therefore do not belong into /etc. It's a pretty common, and HAL's model
for fdi files. As we are moving things from HAL to udev, we may have
more things, which are unconvincing until they are used and start to
make sense. :)

Thanks,
Kay

Re: default udev rules

[Kay Sievers]

On Sun, Aug 10, 2008 at 21:18, Marco d'Itri <md@linux.it> wrote:
> On Aug 09, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> I see they look different, I can't really see any significant
>> difference in elegance. :) But sure, patches are always welcome.
> What should be patched?

The default rules.

> Either you like mine and use them, or you like
> your ones and use these.

Please send patches against the default rules, if you can improve them.

>> Sorry, too many things change too fast, and it may speed up even more
>> depending DeviceKit's progress, while we are moving stuff from HAL
>> (which will go away) to udev. If you use the default rules, you are
>> fine. :)
> This is a lousy excuse for the devkit developers not providing
> documentation.

You are very welcome to join us, get the thing running, and make us
make less lousy excuses. :)

Kay

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 04:36 -0300, Piter PUNK wrote:
> Kay Sievers wrote:
> > We like to remind everybody, that all distros should work towards a
> > default udev rules set, instead of maintaining their own home-grown
> > version of default rules. We should all unify as far as possible.
> > Red Hat, SUSE and Gentoo are already using the same rules files, with a
> > minimal rules set on top, in a distro specific file. We ask the rest of
> > the universe to join us, and do the same. :)
> 
> Slackware is using the rules inside "rules/rules.d", the rules installed
> by apps and scripts in "extra" and the additional:

Ah, nice.

> 40-slackware.rules
> 40-video.rules (shared with Gentoo)
> 40-alsa.rules and 64-device-mapper.rules (from rules/packages)
> 65-permissions.rules

The permissions are shared with Gentoo too?

> > Please consider adapting the default rules now, and let us find a common
> > solution for everybody. New packages, like the upcoming DeviceKit-*
> > packages will depend on a recent udev with a proper rules setup.
> 
> We can remove the 40-slackware.rules if some changes are done in
> 50-udev-default.rules. A patch that does these changes is:
> 
> --------------cut here--------------------------------------------
> --- udev-126/rules/rules.d/50-udev-default.rules	2008-07-30 
> 08:20:21.000000000 -0300
> +++ udev-126new/rules/rules.d/50-udev-default.rules	2008-08-11 
> 04:00:51.000000000 -0300
> @@ -12,13 +12,15 @@
>   KERNEL="tty[A-Z]*|pppox*|ircomm*|noz*", GROUP="uucp"
>   KERNEL="ppp",			MODE="0600", OPTIONS+="ignore_remove"
>   KERNEL="mwave",		NAME="modems/mwave", GROUP="uucp"
> -KERNEL="hvc*|hvsi*",		GROUP="uucp"
> +KERNEL="hvc*|hvsi*|ippp*|isdn*|dcbri*|capi*|pilot", GROUP="uucp"

ISDN should go into its own file. ISDN is not widely used, and should
not unconditionally installed on every system. In the end it should be
packaged with the ISDN tools, which use these nodes.
As far as I can see, the non-CAPI ISDN devices are not created by udev,
and need to be copied from /lib/udev/devices/, or created by some custom
logic, so there is no need to add these. For now, I've added a simple
packages/40-isdn.rules file.

Are you sure, that there is a kernel device named "pilot", and not only
a symlink?

>   KERNEL="lirc0",		SYMLINK+="lirc"
> +KERNEL="capi",			NAME="capi20", SYMLINK+="isdn/capi20"
> +KERNEL="capi*",		NAME="capi/%n"
> 
>   # mem
>   KERNEL="null|zero|full|random|urandom", MODE="0666"
>   KERNEL="null",			SYMLINK+="XOR"
> -KERNEL="mem|kmem|port",	GROUP="kmem", MODE="0640"
> +KERNEL="mem|kmem|port|nvram",	GROUP="kmem", MODE="0640"

I've added this.

>   KERNEL="ram0",			SYMLINK+="ramdisk"
>   KERNEL="ram1",			SYMLINK+="ram"
> 
> @@ -26,6 +28,7 @@
>   KERNEL="mouse*|mice|event*",	NAME="input/%k", MODE="0640"
>   KERNEL="ts[0-9]*|uinput",	NAME="input/%k", MODE="0600"
>   KERNEL="js[0-9]*",		NAME="input/%k", MODE="0644", SYMLINK+="%k"
> +KERNEL="mice",			SYMLINK+="mouse"
> 
>   # video4linux
>   KERNEL="vbi0",			SYMLINK+="vbi"
> --------------cut here--------------------------------------------
> 
> The "capi" rules are shared by slackware, frugalware, gentoo and debian;
> if the distro files that are in udev package are updated (slackware
> isn't, my fault).
> 
> The including of "ippp*|isdn*|dcbri*|capi*|pilot" in "uucp" group is
> shared by slackware and gentoo.

I guess, non of these rules will do anything. :)

> If 40-video.rules can be added to
> 50-udev-default.rules we can be very happy -:)

The assignment to the group "video"? Yeah, I like to have that too,
there is nothing else left in the suse.rules.

Harald, any problems, if we add group "video" to some video devices,
seems we all need that, and it's useful even with the ACL stuff we do
for frame grabber services/webcam daemons/fluendo stuff, and such.

> The last two changes are "nvram" in "kmem", but every distro put it
> in different group (i can move this to 65-permissions.rules, if can't
> be added to 50-udev-default.rules) and a link from "mice" to /dev/mouse,
> i don't think it hurts anyone and the link help us to maintain the same
> /dev/mouse device that our users knows to be their mouse.
> 
> Isn't the 40-alsa.rules a good candidate to be merged with
> 50-udev-default.rules?

Some systems do not have audio, we should put all "optional" subsystem
specific stuff their own files, so they can be picked up by the
subsystem packages, which rely on the device nodes.

> I hope this can be useful

Sure.

Thanks,
Kay

Re: default udev rules

[Marco d'Itri]

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

On Aug 11, Kay Sievers <kay.sievers@vrfy.org> wrote:

> ISDN should go into its own file. ISDN is not widely used, and should
> not unconditionally installed on every system. In the end it should be
Why?

> Some systems do not have audio, we should put all "optional" subsystem
> specific stuff their own files, so they can be picked up by the
> subsystem packages, which rely on the device nodes.
Again, what is the point of using multiple files?

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: default udev rules

[Marco d'Itri]

On Aug 10, Kay Sievers <kay.sievers@vrfy.org> wrote:

> > Either you like mine and use them, or you like
> > your ones and use these.
> Please send patches against the default rules, if you can improve them.
Maybe I was not clear. What I meant is that they should just be
replaced.

> > This is a lousy excuse for the devkit developers not providing
> > documentation.
> You are very welcome to join us, get the thing running, and make us
> make less lousy excuses. :)
devkit is not my project.

-- 
ciao,
Marco

Re: default udev rules

[Scott James Remnant]

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

On Sun, 2008-08-10 at 21:47 +0200, Kay Sievers wrote:

> On Sun, 2008-08-10 at 19:07 +0100, Scott James Remnant wrote:
> > On Sat, 2008-08-09 at 12:21 +0200, Kay Sievers wrote:
> > 
> > > We like to remind everybody, that all distros should work towards a
> > > default udev rules set, instead of maintaining their own home-grown
> > > version of default rules. We should all unify as far as possible.
> > > Red Hat, SUSE and Gentoo are already using the same rules files, with a
> > > minimal rules set on top, in a distro specific file. We ask the rest of
> > > the universe to join us, and do the same. :)
> > 
> > The conflation of names and permissions in the default rules is a
> > problem for us, and why Ubuntu has not adopted them.
> 
> Which names, which perms? Please just list them all, we will try to find
> a common solution.
> 
Setting any group names, and thus any group-writable permissions; our
rules have these split out into a separate file which is added later.

> > I'm also entirely unconvinced about putting rules in /lib instead
> > of /etc
> 
> Most udev rules are not config files, not supposed to be edited, and
> therefore do not belong into /etc. It's a pretty common, and HAL's model
> for fdi files. As we are moving things from HAL to udev, we may have
> more things, which are unconvincing until they are used and start to
> make sense. :)
> 
I've yet to have it explained to me why udev rules suddenly aren't
configuration files.  They've been configuration files for years, and we
encourage people to edit them.

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 14:03 +0100, Scott James Remnant wrote:
> On Sun, 2008-08-10 at 21:47 +0200, Kay Sievers wrote:
> > On Sun, 2008-08-10 at 19:07 +0100, Scott James Remnant wrote:
> > > On Sat, 2008-08-09 at 12:21 +0200, Kay Sievers wrote:
> > > 
> > > > We like to remind everybody, that all distros should work towards a
> > > > default udev rules set, instead of maintaining their own home-grown
> > > > version of default rules. We should all unify as far as possible.
> > > > Red Hat, SUSE and Gentoo are already using the same rules files, with a
> > > > minimal rules set on top, in a distro specific file. We ask the rest of
> > > > the universe to join us, and do the same. :)
> > > 
> > > The conflation of names and permissions in the default rules is a
> > > problem for us, and why Ubuntu has not adopted them.
> > 
> > Which names, which perms? Please just list them all, we will try to find
> > a common solution.
> > 
> Setting any group names, and thus any group-writable permissions; our
> rules have these split out into a separate file which is added later.

That makes no difference, assigning perms works any time.

It would be still nice if you could provide facts, al list, what the
differences are, which makes you compose your own, almost identical
default rules, for no obvious reason today. We should try to come up
with a common setup, it can save us all a lot of time debugging.

> > > I'm also entirely unconvinced about putting rules in /lib instead
> > > of /etc
> > 
> > Most udev rules are not config files, not supposed to be edited, and
> > therefore do not belong into /etc. It's a pretty common, and HAL's model
> > for fdi files. As we are moving things from HAL to udev, we may have
> > more things, which are unconvincing until they are used and start to
> > make sense. :)
> > 
> I've yet to have it explained to me why udev rules suddenly aren't
> configuration files.

Default rules are supposed to be entirely replaced on version updates
for that reason. They have dependencies across files, and can only be
seen as a whole, not as randomly editable/collectable.

> They've been configuration files for years,

No, they never have been config files in that sense. They are static
instructions, not supposed to be changed. Editing them may result in a
broken udev setup on updates.

> and we
> encourage people to edit them.

That just wrong to do, and I can not see how you could solve the update
problem that way.

Thanks,
Kay

Re: default udev rules

[David Zeuthen]

On Mon, 2008-08-11 at 14:03 +0100, Scott James Remnant wrote:
> I've yet to have it explained to me why udev rules suddenly aren't
> configuration files.  They've been configuration files for years, 

False. The rules have lived in /etc though so many many people and
distros mistakenly assume they can be edited and that they are
configuration files. It's a common misconception. 

FWIW, if you edit some udev rules then your system will most likely
break in one way or another. Look at it this way, what do you think
would happen if a user changed any of these rules

  "KERNEL="device-mapper", NAME="mapper/control"

  RUN+="socket:/org/freedesktop/hal/udev_event"

Thanks for playing.

Of course, one mans configuration file is another mans system
implementation detail. Me? I see the new policy of shipping the default
rules in /lib just as a reinforcement of the fact that (most) udev rules
are not to be edited by users nor admins. Of course the world isn't as
black as white as you paint it hence why udev will still read files
from /etc/udev/rules.d so hackers, ppl building embedded systems and
hobbyist users can override rules there.

In fact, we should put 

 # DO NOT EDIT. This is not a configuration file, see the udev man page for details

in the top of each udev rule. Then said man page can tell the user what
to do. Kay?

> and we
> encourage people to edit them.

Very bad advice. Please stop doing that. If you encourage people to edit
these files then lots of "useful" HOWTO's and user forums will tell
newbies to edit them to "fix" their system (instead of getting the OS
vendor to fix it properly). Then said users will end up editing a file
with vital udev rules and then end up with either a) .rpmnew/.rpmorig
files (and a broken system); or b) they get exposed to crappy dialogs
like

http://weblogs.mozillazine.org/gerv/archives/2008/04/upgrading_to_hardy.html

depending on how the distro deals with configuration file changes.
IMNSHO, both are bad approaches in their own way. 

The solution is to stop offering configuration knobs. Especially when
none are needed. The move of rules to /lib from /etc is just, again, a
reinforcement of that view from upstream.

FWIW, it's off-putting to hear blanket statements like "my rules are so
much better" and "it's been like that for year" etc. ; that's _not_ how
to deal with upstream. Send patches. Thanks.

      David

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 16:54 +0200, Kay Sievers wrote:

> That just wrong to do, and I can not see how you could solve the update
> problem that way.
> 
What update problem?

As far as I'm aware, we've never had one.

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 16:54 +0200, Kay Sievers wrote:

> > Setting any group names, and thus any group-writable permissions; our
> > rules have these split out into a separate file which is added later.
> 
> That makes no difference, assigning perms works any time.
> 
But assigning groups doesn't.

As you're well aware, we run udev in the initramfs, where any attempt to
look up a group name will simply end in an error.

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 16:21 +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 16:54 +0200, Kay Sievers wrote:
> 
> > > Setting any group names, and thus any group-writable permissions; our
> > > rules have these split out into a separate file which is added later.
> > 
> > That makes no difference, assigning perms works any time.
> > 
> But assigning groups doesn't.

Wrong.

> As you're well aware, we run udev in the initramfs, where any attempt to
> look up a group name will simply end in an error.

Copy over /etc/groups and done! And who cares about groups in initramfs,
we fall back to root then, and done!

I'm still looking forward to the facts. Thanks!

Kay

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 16:20 +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 16:54 +0200, Kay Sievers wrote:
> 
> > That just wrong to do, and I can not see how you could solve the update
> > problem that way.
> > 
> What update problem?
> 
> As far as I'm aware, we've never had one.

We've seen several cases, maybe it's just the mentioned "beauty", that
makes you the lucky one. :)

Kay

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 17:28 +0200, Kay Sievers wrote:

> On Mon, 2008-08-11 at 16:20 +0100, Scott James Remnant wrote:
> > On Mon, 2008-08-11 at 16:54 +0200, Kay Sievers wrote:
> > 
> > > That just wrong to do, and I can not see how you could solve the update
> > > problem that way.
> > > 
> > What update problem?
> > 
> > As far as I'm aware, we've never had one.
> 
> We've seen several cases, maybe it's just the mentioned "beauty", that
> makes you the lucky one. :)
> 
I don't recall mentioning any beauty?

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 17:27 +0200, Kay Sievers wrote:

> On Mon, 2008-08-11 at 16:21 +0100, Scott James Remnant wrote:
> > On Mon, 2008-08-11 at 16:54 +0200, Kay Sievers wrote:
> > 
> > > > Setting any group names, and thus any group-writable permissions; our
> > > > rules have these split out into a separate file which is added later.
> > > 
> > > That makes no difference, assigning perms works any time.
> > > 
> > But assigning groups doesn't.
> 
> Wrong.
> 
Last time I tried it, I had screenfuls of errors.

> > As you're well aware, we run udev in the initramfs, where any attempt to
> > look up a group name will simply end in an error.
> 
> Copy over /etc/groups and done! And who cares about groups in initramfs,
> we fall back to root then, and done!
> 
Can't just copy over groups, we'd also have to copy over all of the
nsswitch configuration, maybe start an LDAP server, etc.

It's just far too much when it's just as simple to set the group names
in a separate udev rule.

> I'm still looking forward to the facts. Thanks!
> 
Frankly Kay, your attitude is incredibly hostile today.

You'd like us to use a set of udev rules in the tarball which are based
on the SuSE and RedHat ones - that's fine, I fully appreciate that
getting some harmony between the distributions would be nice.

But you seem unwilling to appreciate that in some cases, they don't work
for other people - or cause new problems.

And we already have rules that *do* work for us, and that *aren't*
causing us any problems.


We have concerns, and you're telling us that they are petty.

You're also telling us that *we* have to do the work to use your rules,
and have the fight with you to get your rules changed where we need to.
Your attitude while doing this is hostile, this is hardly putting us in
the mood to have that fight.


Right now, we have working udev packages.  We use a mix of the upstream
rules (for things like persistent storage) and our own.  Every now and
then, I check what needs to be merged back into our own rules.

At some point in the future, I'll sit down and work through the
differences and give you some patches.

I'd like to think you'd apply those patches without question, or maybe
have a little light-hearted discussion about them; but your current mood
suggests to me that you'd simply tell me how wrong my patches are.

So how's that supposed to encourage me to do that work, when I have
plenty of other things to do?

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 11:18 -0400, David Zeuthen wrote:

> FWIW, if you edit some udev rules then your system will most likely
> break in one way or another. Look at it this way, what do you think
> would happen if a user changed any of these rules
> 
>   "KERNEL=="device-mapper", NAME="mapper/control"
> 
If udev rules are intended to be shared amongst all distributions, and
not editable by users, that means device names will be fixed?

(Yay)

But surely that means cases where we need NAME= rules are now better
fixed by fixing the kernel to give it the right name in the first place?

That way udev would need no NAME= rules at all, since the kernel would
set the right ones in the first place.

udev rules would then only set permissions, groups, and the like.

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 16:36 +0100, Scott James Remnant wrote:

> We have concerns, and you're telling us that they are petty.

I didn't do, sorry if you could understand it like this. Earlier in this
thread, Marco wrote:
  " Not going to happen, because:
- I consider my rules much more readable and elegant than yours"

> You're also telling us that *we* have to do the work to use your
> rules, and have the fight with you to get your rules changed where
> we need to.

I just _asked_ for getting a set of rules we all use, nothing else.

You wrote: "The conflation of names and permissions in the default rules
is a problem for us", so why shouldn't I ask for the actual things that
cause problems?

Thanks,
Kay

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 17:50 +0200, Kay Sievers wrote:

> On Mon, 2008-08-11 at 16:36 +0100, Scott James Remnant wrote:
> 
> > We have concerns, and you're telling us that they are petty.
> 
> I didn't do, sorry if you could understand it like this. Earlier in this
> thread, Marco wrote:
>   " Not going to happen, because:
> - I consider my rules much more readable and elegant than yours"
> 
That's trivial to fix by giving you a patch that adds comments ;)

When/if/etc. we move over, I'll certainly end up doing that.

> > You're also telling us that *we* have to do the work to use your
> > rules, and have the fight with you to get your rules changed where
> > we need to.
> 
> I just _asked_ for getting a set of rules we all use, nothing else.
> 
> You wrote: "The conflation of names and permissions in the default rules
> is a problem for us", so why shouldn't I ask for the actual things that
> cause problems?
> 
I did that - having group names in the rules doesn't work for us.

Your response was "Wrong".

Sorry, but this is an actual problem for me, no matter how hard you wish
it wasn't ;)

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[piterpk]

> > You wrote: "The conflation of names and permissions in the default rules
> > is a problem for us", so why shouldn't I ask for the actual things that
> > cause problems?
> > 
> I did that - having group names in the rules doesn't work for us.
> 
> Your response was "Wrong".
> 
> Sorry, but this is an actual problem for me, no matter how hard you wish
> it wasn't ;)

Why not split 50-udev-default.rules in 50-udev-default.rules and
50-udev-permissions.rules? We continue with a default and shared
set of rules and a separated "permissions" file.

Isn´t that good for all?

Piter PUNK

Re: default udev rules

[Marco d'Itri]

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

On Aug 11, Kay Sievers <kay.sievers@vrfy.org> wrote:

> - I consider my rules much more readable and elegant than yours"
And I still hold this opinion. I believe that my rules are easier to
understand and you believe that your rules are easier to understand.
I do not see a possibile compromise.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 17:00 +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 17:50 +0200, Kay Sievers wrote:
> 
> > On Mon, 2008-08-11 at 16:36 +0100, Scott James Remnant wrote:
> > 
> > > We have concerns, and you're telling us that they are petty.
> > 
> > I didn't do, sorry if you could understand it like this. Earlier in this
> > thread, Marco wrote:
> >   " Not going to happen, because:
> > - I consider my rules much more readable and elegant than yours"
> > 
> That's trivial to fix by giving you a patch that adds comments ;)
> 
> When/if/etc. we move over, I'll certainly end up doing that.
> 
> > > You're also telling us that *we* have to do the work to use your
> > > rules, and have the fight with you to get your rules changed where
> > > we need to.
> > 
> > I just _asked_ for getting a set of rules we all use, nothing else.
> > 
> > You wrote: "The conflation of names and permissions in the default rules
> > is a problem for us", so why shouldn't I ask for the actual things that
> > cause problems?
> > 
> I did that - having group names in the rules doesn't work for us.

Oh, I expected you have a list of things. If that is the only real
problem, I'm sure we can solve that pretty easy. If split-out
permissions have more advantage than just initramfs, we can certainly do
that without a lot of discussion.

For the initramfs case, this could be solved much easier by fixing the
possible current error log, and expect it just to fall back to "root",
or ship a "static system groups file", which the current users do. In
almost all cases, we need to run udev before we have network, so
nsswitch will not really matter, and the few needed basic group names
should be locally provided.

> Your response was "Wrong".
> 
> Sorry, but this is an actual problem for me, no matter how hard you wish
> it wasn't ;)

Ok. :)

Kay

Re: default udev rules

[Marco d'Itri]

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

On Aug 11, Scott James Remnant <scott@canonical.com> wrote:

> > - I consider my rules much more readable and elegant than yours"
> That's trivial to fix by giving you a patch that adds comments ;)
For me it's not just comments and white space, but also many other
details like how related rules are grouped and GOTOs are organized to
not have redundancy.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: default udev rules

[Kay Sievers]

On Mon, Aug 11, 2008 at 18:14, Marco d'Itri <md@linux.it> wrote:
> On Aug 11, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> - I consider my rules much more readable and elegant than yours"
> And I still hold this opinion. I believe that my rules are easier to
> understand and you believe that your rules are easier to understand.
> I do not see a possibile compromise.

I never said so. I just said that I fail to see any difference in the
"elegance" you claim.

There is not really a need for a compromise, we asked you to send a
patch to add that "elegance", and we will change the default rules
until you don't find them equally elegant, and you could possibly
switch over. If you ever do, is a different story, but it would be
nice to come as close as needed to get a common default.

If you don't like to send a patch, care to explain in detail, so
someone else can "elegantize" the current default rules. :)

Thanks,
Kay

Re: default udev rules

[Greg KH]

On Mon, Aug 11, 2008 at 04:42:59PM +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 11:18 -0400, David Zeuthen wrote:
> 
> > FWIW, if you edit some udev rules then your system will most likely
> > break in one way or another. Look at it this way, what do you think
> > would happen if a user changed any of these rules
> > 
> >   "KERNEL="device-mapper", NAME="mapper/control"
> > 
> If udev rules are intended to be shared amongst all distributions, and
> not editable by users, that means device names will be fixed?
> 
> (Yay)
> 
> But surely that means cases where we need NAME= rules are now better
> fixed by fixing the kernel to give it the right name in the first place?

Where does the kernel not give the "right" name today?

thanks,

greg k-h

Re: default udev rules

[Kay Sievers]

On Mon, Aug 11, 2008 at 18:37, Greg KH <greg@kroah.com> wrote:
> On Mon, Aug 11, 2008 at 04:42:59PM +0100, Scott James Remnant wrote:
>> On Mon, 2008-08-11 at 11:18 -0400, David Zeuthen wrote:
>>
>> > FWIW, if you edit some udev rules then your system will most likely
>> > break in one way or another. Look at it this way, what do you think
>> > would happen if a user changed any of these rules
>> >
>> >   "KERNEL="device-mapper", NAME="mapper/control"
>> >
>> If udev rules are intended to be shared amongst all distributions, and
>> not editable by users, that means device names will be fixed?
>>
>> (Yay)
>>
>> But surely that means cases where we need NAME= rules are now better
>> fixed by fixing the kernel to give it the right name in the first place?
>
> Where does the kernel not give the "right" name today?

usb-device, dvb, ... are totally disconnected names, lot of stuff
lives in subdirs like "input/", "sound/", ... and needs rules for
moving it there.

Kay

Re: default udev rules

[Marco d'Itri]

On Aug 11, Kay Sievers <kay.sievers@vrfy.org> wrote:

> There is not really a need for a compromise, we asked you to send a
> patch to add that "elegance", and we will change the default rules
Tell me what's missing from my rules instead, I will fix it and then you
will be able to use them. If nothing is missing, then you can replace
the files right now.

BTW: *I* documented the semantics of the Debian rules files. From
README.Debian:

Since the order may be important, files have a specific name which
must be considered when adding custom rules. So far have been defined:

 - 50: the default names are set.

 - 60: path_id and the other *_id programs are run. persistent links
   are created.

 - 70: network interfaces are renamed and generated rules for persistent
   links are processed.

 - 75: the rules generators are run if needed.

 - 80: drivers are loaded.

 - 91: the default permissions and owners are set.

 - 95: $REMOVE_CMD is run, and then processing of tty devices
   is stopped with last_rule.

-- 
ciao,
Marco

Re: default udev rules

[Marco d'Itri]

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

On Aug 11, Greg KH <greg@kroah.com> wrote:

> Where does the kernel not give the "right" name today?

For a start:

SUBSYSTEMS=="scsi", KERNEL=="sr[0-9]*",         NAME="scd%n",
SYMLINK+="sr%n"
SUBSYSTEM=="bsg",                               NAME="bsg/%k"
SUBSYSTEMS=="usb", KERNEL=="auer[0-9]*",        NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="cpad[0-9]*",        NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="dabusb*",           NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="hiddev*",           NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="legousbtower*",     NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="lp[0-9]*",          NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="iowarrior[0-9]*",   NAME="usb/%k"
KERNEL=="capi",                 NAME="capi20", SYMLINK+="isdn/capi20"
KERNEL=="capi[0-9]*",           NAME="capi/%n"
KERNEL=="card[0-9]*",           NAME="dri/%k"
KERNEL=="hw_random",            NAME="hwrng"
KERNEL=="tun",                  NAME="net/%k"
KERNEL=="evtchn",               NAME="xen/%k"
KERNEL=="cdemu[0-9]*",          NAME="cdemu/%n"
KERNEL=="pktcdvd[0-9]*",        NAME="pktcdvd/%n"
KERNEL=="pktcdvd",              NAME="pktcdvd/control"
KERNEL=="cpu[0-9]*",            NAME="cpu/%n/cpuid"
KERNEL=="msr[0-9]*",            NAME="cpu/%n/msr"
KERNEL=="microcode",            NAME="cpu/microcode"
KERNEL=="umad*",                NAME="infiniband/%k"
KERNEL=="issm*",                NAME="infiniband/%k"
KERNEL=="uverbs*",              NAME="infiniband/%k"
KERNEL=="ucm*",                 NAME="infiniband/%k"
KERNEL=="rdma_cm",              NAME="infiniband/%k"
KERNEL=="controlC[0-9]*",       NAME="snd/%k"
KERNEL=="hwC[D0-9]*",           NAME="snd/%k"
KERNEL=="pcmC[D0-9cp]*",        NAME="snd/%k"
KERNEL=="midiC[D0-9]*",         NAME="snd/%k"
KERNEL=="timer",                NAME="snd/%k"
KERNEL=="seq",                  NAME="snd/%k"
KERNEL=="dv1394*",              NAME="dv1394/%n"
KERNEL=="video1394*",           NAME="video1394/%n"
KERNEL=="mice",                 NAME="input/%k"
KERNEL=="mice",                 NAME="input/%k"
KERNEL=="mouse[0-9]*",          NAME="input/%k"
KERNEL=="event[0-9]*",          NAME="input/%k"
KERNEL=="js[0-9]*",             NAME="input/%k"
KERNEL=="ts[0-9]*",             NAME="input/%k"
KERNEL=="uinput",               NAME="input/%k"
KERNEL=="zapctl",               NAME="zap/ctl"
KERNEL=="zapchannel",           NAME="zap/channel"
KERNEL=="zappseudo",            NAME="zap/pseudo"
KERNEL=="zaptimer",             NAME="zap/timer"
KERNEL=="transcode",            NAME="zap/transcode"
KERNEL=="zap[0-9]*",            NAME="zap/%n"
SUBSYSTEM=="aoe",               NAME="etherd/%k"
KERNEL=="device-mapper",        NAME="mapper/control"

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 13:06 -0300, piterpk wrote:
> > > You wrote: "The conflation of names and permissions in the default rules
> > > is a problem for us", so why shouldn't I ask for the actual things that
> > > cause problems?
> > > 
> > I did that - having group names in the rules doesn't work for us.
> > 
> > Your response was "Wrong".
> > 
> > Sorry, but this is an actual problem for me, no matter how hard you wish
> > it wasn't ;)
> 
> Why not split 50-udev-default.rules in 50-udev-default.rules and
> 50-udev-permissions.rules? We continue with a default and shared
> set of rules and a separated "permissions" file.
> 
> Isn´t that good for all?

Sure, if that makes people happy. :)

It's technically not really needed, or can be easily fixed otherwise if
needed, but if that's what people prefer, I don't really mind doing
that.

Kay

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 18:48 +0200, Kay Sievers wrote:

> On Mon, 2008-08-11 at 13:06 -0300, piterpk wrote:
> > > > You wrote: "The conflation of names and permissions in the default rules
> > > > is a problem for us", so why shouldn't I ask for the actual things that
> > > > cause problems?
> > > > 
> > > I did that - having group names in the rules doesn't work for us.
> > > 
> > > Your response was "Wrong".
> > > 
> > > Sorry, but this is an actual problem for me, no matter how hard you wish
> > > it wasn't ;)
> > 
> > Why not split 50-udev-default.rules in 50-udev-default.rules and
> > 50-udev-permissions.rules? We continue with a default and shared
> > set of rules and a separated "permissions" file.
> > 
> > Isn´t that good for all?
> 
> Sure, if that makes people happy. :)
> 
> It's technically not really needed, or can be easily fixed otherwise if
> needed, but if that's what people prefer, I don't really mind doing
> that.
> 
If we fix the kernel so that we never need NAME=, we wouldn't need the
two files after all :)

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Marco d'Itri]

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

On Aug 11, Kay Sievers <kay.sievers@vrfy.org> wrote:

> > Why not split 50-udev-default.rules in 50-udev-default.rules and
> > 50-udev-permissions.rules? We continue with a default and shared
> > set of rules and a separated "permissions" file.
> It's technically not really needed, or can be easily fixed otherwise if
> needed, but if that's what people prefer, I don't really mind doing
> that.
50-udev-permissions.rules does not work because it needs ENV{ID_CLASS}
for joystick devices and ENV{ID_CDROM}, I used 91.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: default udev rules

[Greg KH]

On Mon, Aug 11, 2008 at 06:48:19PM +0200, Marco d'Itri wrote:
> On Aug 11, Greg KH <greg@kroah.com> wrote:
> 
> > Where does the kernel not give the "right" name today?
> 
> For a start:

The large majority of those are because you want a subdirectory to make
things pretty.  The kernel can't do anything about that.

But some of them do look like the real name should be changed, like
these:

> KERNEL="zapctl",               NAME="zap/ctl"
> KERNEL="zapchannel",           NAME="zap/channel"
> KERNEL="zappseudo",            NAME="zap/pseudo"
> KERNEL="zaptimer",             NAME="zap/timer"

Anyone send upstream a patch to do so?

thanks,

greg k-h

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 17:53 +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 18:48 +0200, Kay Sievers wrote:
> 
> > On Mon, 2008-08-11 at 13:06 -0300, piterpk wrote:
> > > > > You wrote: "The conflation of names and permissions in the default rules
> > > > > is a problem for us", so why shouldn't I ask for the actual things that
> > > > > cause problems?
> > > > > 
> > > > I did that - having group names in the rules doesn't work for us.
> > > > 
> > > > Your response was "Wrong".
> > > > 
> > > > Sorry, but this is an actual problem for me, no matter how hard you wish
> > > > it wasn't ;)
> > > 
> > > Why not split 50-udev-default.rules in 50-udev-default.rules and
> > > 50-udev-permissions.rules? We continue with a default and shared
> > > set of rules and a separated "permissions" file.
> > > 
> > > Isn´t that good for all?
> > 
> > Sure, if that makes people happy. :)
> > 
> > It's technically not really needed, or can be easily fixed otherwise if
> > needed, but if that's what people prefer, I don't really mind doing
> > that.
> > 
> If we fix the kernel so that we never need NAME=, we wouldn't need the
> two files after all :)

Sure, but how would we handle the bugs we create by renaming:
  /sys/class/input/mouse0/
to
  /sys/class/input/input!mouse0/

Add another file with a suggested name and perms to sysfs? :)

Kay

Re: default udev rules

[Kay Sievers]

On Mon, Aug 11, 2008 at 18:58, Greg KH <greg@kroah.com> wrote:
> On Mon, Aug 11, 2008 at 06:48:19PM +0200, Marco d'Itri wrote:
>> On Aug 11, Greg KH <greg@kroah.com> wrote:
>>
>> > Where does the kernel not give the "right" name today?
>>
>> For a start:
>
> The large majority of those are because you want a subdirectory to make
> things pretty.  The kernel can't do anything about that.
>
> But some of them do look like the real name should be changed, like
> these:
>
>> KERNEL="zapctl",               NAME="zap/ctl"
>> KERNEL="zapchannel",           NAME="zap/channel"
>> KERNEL="zappseudo",            NAME="zap/pseudo"
>> KERNEL="zaptimer",             NAME="zap/timer"
>
> Anyone send upstream a patch to do so?

It could be made "zap!pseudo" and it will just be a subdir without any
udev rule. :)

Kay

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 09:58 -0700, Greg KH wrote:

> On Mon, Aug 11, 2008 at 06:48:19PM +0200, Marco d'Itri wrote:
> > On Aug 11, Greg KH <greg@kroah.com> wrote:
> > 
> > > Where does the kernel not give the "right" name today?
> > 
> > For a start:
> 
> The large majority of those are because you want a subdirectory to make
> things pretty.  The kernel can't do anything about that.
> 
Why not?

We have the source code to the kernel.

The patch to allow "/" in device names, as exported to user space, must
be trivial?

udev already converts "!" to "/", so we could just use that?

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 19:00 +0200, Kay Sievers wrote:

> Sure, but how would we handle the bugs we create by renaming:
>   /sys/class/input/mouse0/
> to
>   /sys/class/input/input!mouse0/
> 
Why would we have any bugs?

We've already dropped rules for backward compatibility with previous
kernels, this would simply grow a rule like:

  KERNEL=="mouse0", KERNEL="input!mouse0"

which could go away after a short while.

> Add another file with a suggested name and perms to sysfs? :)
> 
Permissions can be still done in udev?

KERNEL=="input!mouse0", GROUP="..."

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 18:45 +0200, Marco d'Itri wrote:

> On Aug 11, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > There is not really a need for a compromise, we asked you to send a
> > patch to add that "elegance", and we will change the default rules
> Tell me what's missing from my rules instead, I will fix it and then you
> will be able to use them. If nothing is missing, then you can replace
> the files right now.
> 
> BTW: *I* documented the semantics of the Debian rules files. From
> README.Debian:
> 
This is different from Ubuntu's?

  00   rules that it is critical to be run first, usually
       only WAIT_FOR_SYSFS

  20   rules that change the name from the device from the default
       (cannot be overriden)

  40   rules that set the permissions of device nodes
       (can be overriden by later rules)

  60   rules that add symlinks to device nodes
       (adds to those set in earlier rules)

  80   rules that run programs (but do not load modules)

  90   rules that load modules

  99   rules that it is critical to be run last


Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 18:08 +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 19:00 +0200, Kay Sievers wrote:
> 
> > Sure, but how would we handle the bugs we create by renaming:
> >   /sys/class/input/mouse0/
> > to
> >   /sys/class/input/input!mouse0/
> > 
> Why would we have any bugs?

Because we change many device names in sysfs to be different from today.
I don't think we can do that. Current HAL, and all sorts of simpler
stuff would just stop working.

Kay

Re: default udev rules

[David Zeuthen]

On Mon, 2008-08-11 at 16:42 +0100, Scott James Remnant wrote:
> But surely that means cases where we need NAME= rules are now better
> fixed by fixing the kernel to give it the right name in the first place?

The kernel name is most of the time useless - it's simply just a damn
cookie. FWIW, my view is that any application depending on the kernel
name is always almost broken (except for singleton devices
like /dev/mapper/control etc.) except for when the user hasn't
configured what device to use (e.g. use the first webcam, the first
optical drive etc. etc.).

So this is why udev ships code (not user configurable settings!) in udev
rules for persistent naming. Unfortunately we don't have persistent
names for everything (and for some things it of course won't make
sense). Send patches.

Also, I would like to propose that whenever someone adds a subsystem to
the kernel they also need, for the subsystem to be merged, to send a
patch to udev for persistent naming (in cases where it makes sense).
Such a patch would some of the time need to include a user space tool
for investigating the device (for the cases where persistent naming make
sense) if device not in sysfs is needed (sometimes it doesn't make sense
for the kernel to collect all data in sysfs)

I would really like to see the kernel adopt such a requirement for new
subsystems. Greg?

     David

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 19:24 +0200, Kay Sievers wrote:

> On Mon, 2008-08-11 at 18:08 +0100, Scott James Remnant wrote:
> > On Mon, 2008-08-11 at 19:00 +0200, Kay Sievers wrote:
> > 
> > > Sure, but how would we handle the bugs we create by renaming:
> > >   /sys/class/input/mouse0/
> > > to
> > >   /sys/class/input/input!mouse0/
> > > 
> > Why would we have any bugs?
> 
> Because we change many device names in sysfs to be different from today.
> I don't think we can do that. Current HAL, and all sorts of simpler
> stuff would just stop working.
> 
Shouldn't HAL be using the DEVNAME from udev anyway?  Otherwise it would
break today if someone wrote a udev rule.

Is there any particular reason that the kernel couldn't include DEVNAME
in the uevent for things like mouse0?

add /class/input/mouse0
DEVNAME=input/mouse0

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 13:37 -0400, David Zeuthen wrote:

> On Mon, 2008-08-11 at 16:42 +0100, Scott James Remnant wrote:
> > But surely that means cases where we need NAME= rules are now better
> > fixed by fixing the kernel to give it the right name in the first place?
> 
> The kernel name is most of the time useless - it's simply just a damn
> cookie. FWIW, my view is that any application depending on the kernel
> name is always almost broken (except for singleton devices
> like /dev/mapper/control etc.) except for when the user hasn't
> configured what device to use (e.g. use the first webcam, the first
> optical drive etc. etc.).
> 
> So this is why udev ships code (not user configurable settings!) in udev
> rules for persistent naming. Unfortunately we don't have persistent
> names for everything (and for some things it of course won't make
> sense). Send patches.
> 
My problem with this is that it means udev has to execute code to
construct that persistent name, even when it's static.

And since udev can't do much in the way of intelligent string
manipulation itself, we have to fork and exec a shell or some other
binary to do it for us.

Which is kinda expensive.

Especially when the kernel had all the bits, and could have just set the
default static name in the first place.


If we're all going to agree on a fixed naming scheme, the old argument
that the kernel didn't set such policy is moot.  The kernel should agree
with our defaults, otherwise we're wasting time, cycles and effort
converting the kernel defaults into our own defaults.  Every damned
time.

(I have similar arguments every time someone asks for a modprobe.d
"option" line - if it should be the default, then patch the module so it
*is* the default)

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Kay Sievers]

On Mon, 2008-08-11 at 18:40 +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 19:24 +0200, Kay Sievers wrote:
> 
> > On Mon, 2008-08-11 at 18:08 +0100, Scott James Remnant wrote:
> > > On Mon, 2008-08-11 at 19:00 +0200, Kay Sievers wrote:
> > > 
> > > > Sure, but how would we handle the bugs we create by renaming:
> > > >   /sys/class/input/mouse0/
> > > > to
> > > >   /sys/class/input/input!mouse0/
> > > > 
> > > Why would we have any bugs?
> > 
> > Because we change many device names in sysfs to be different from today.
> > I don't think we can do that. Current HAL, and all sorts of simpler
> > stuff would just stop working.
> > 
> Shouldn't HAL be using the DEVNAME from udev anyway?  Otherwise it would
> break today if someone wrote a udev rule.

It's doing that, it does not guess /dev names, but classifies devices by
its name, which we would change.

> Is there any particular reason that the kernel couldn't include DEVNAME
> in the uevent for things like mouse0?
> 
> add /class/input/mouse0
> DEVNAME=input/mouse0

It could, possibly, but then we get all the devfs and "policy in kernel"
discussions back, if we add such a thing. :)

Kay

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 20:01 +0200, Kay Sievers wrote:

> its name, which we would change.
> 
> > Is there any particular reason that the kernel couldn't include DEVNAME
> > in the uevent for things like mouse0?
> > 
> > add /class/input/mouse0
> > DEVNAME=input/mouse0
> 
> It could, possibly, but then we get all the devfs and "policy in kernel"
> discussions back, if we add such a thing. :)
> 
Ahh, but we're not doing "policy" in kernel -- we're just supplying the
default according to devices.txt

You'd obviously stil be able to override that in udev, if you so
wished ;)

But it'd mean the default udev tarball wouldn't contain any name
overrides

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Greg KH]

On Mon, Aug 11, 2008 at 01:37:02PM -0400, David Zeuthen wrote:
> On Mon, 2008-08-11 at 16:42 +0100, Scott James Remnant wrote:
> > But surely that means cases where we need NAME= rules are now better
> > fixed by fixing the kernel to give it the right name in the first place?
> 
> The kernel name is most of the time useless - it's simply just a damn
> cookie. FWIW, my view is that any application depending on the kernel
> name is always almost broken (except for singleton devices
> like /dev/mapper/control etc.) except for when the user hasn't
> configured what device to use (e.g. use the first webcam, the first
> optical drive etc. etc.).
> 
> So this is why udev ships code (not user configurable settings!) in udev
> rules for persistent naming. Unfortunately we don't have persistent
> names for everything (and for some things it of course won't make
> sense). Send patches.
> 
> Also, I would like to propose that whenever someone adds a subsystem to
> the kernel they also need, for the subsystem to be merged, to send a
> patch to udev for persistent naming (in cases where it makes sense).
> Such a patch would some of the time need to include a user space tool
> for investigating the device (for the cases where persistent naming make
> sense) if device not in sysfs is needed (sometimes it doesn't make sense
> for the kernel to collect all data in sysfs)
> 
> I would really like to see the kernel adopt such a requirement for new
> subsystems. Greg?

No objection from me at all.  Care to write up a small documentation bit
for this that we can place in Documentation/ABI/README?

thanks,

greg k-h

Re: default udev rules

[Greg KH]

On Mon, Aug 11, 2008 at 07:00:59PM +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 13:37 -0400, David Zeuthen wrote:
> 
> > On Mon, 2008-08-11 at 16:42 +0100, Scott James Remnant wrote:
> > > But surely that means cases where we need NAME= rules are now better
> > > fixed by fixing the kernel to give it the right name in the first place?
> > 
> > The kernel name is most of the time useless - it's simply just a damn
> > cookie. FWIW, my view is that any application depending on the kernel
> > name is always almost broken (except for singleton devices
> > like /dev/mapper/control etc.) except for when the user hasn't
> > configured what device to use (e.g. use the first webcam, the first
> > optical drive etc. etc.).
> > 
> > So this is why udev ships code (not user configurable settings!) in udev
> > rules for persistent naming. Unfortunately we don't have persistent
> > names for everything (and for some things it of course won't make
> > sense). Send patches.
> > 
> My problem with this is that it means udev has to execute code to
> construct that persistent name, even when it's static.
> 
> And since udev can't do much in the way of intelligent string
> manipulation itself, we have to fork and exec a shell or some other
> binary to do it for us.
> 
> Which is kinda expensive.

expensive to whom?  Have you really timed it?  Is this a boot time speed
issue?  or a "oh no, I had to wait 50ms after my device was plugged in
before I could use it!" type thing?

> Especially when the kernel had all the bits, and could have just set the
> default static name in the first place.

Examples please, I really don't know how the kernel can do this for the
things that we create persistant names for today.  Do you?

> If we're all going to agree on a fixed naming scheme, the old argument
> that the kernel didn't set such policy is moot.  The kernel should agree
> with our defaults, otherwise we're wasting time, cycles and effort
> converting the kernel defaults into our own defaults.  Every damned
> time.
> 
> (I have similar arguments every time someone asks for a modprobe.d
> "option" line - if it should be the default, then patch the module so it
> *is* the default)

Patches for the kernel are always accepted.

thanks,

greg k-h

Re: default udev rules

[Greg KH]

On Mon, Aug 11, 2008 at 06:06:46PM +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 09:58 -0700, Greg KH wrote:
> 
> > On Mon, Aug 11, 2008 at 06:48:19PM +0200, Marco d'Itri wrote:
> > > On Aug 11, Greg KH <greg@kroah.com> wrote:
> > > 
> > > > Where does the kernel not give the "right" name today?
> > > 
> > > For a start:
> > 
> > The large majority of those are because you want a subdirectory to make
> > things pretty.  The kernel can't do anything about that.
> > 
> Why not?
> 
> We have the source code to the kernel.
> 
> The patch to allow "/" in device names, as exported to user space, must
> be trivial?
> 
> udev already converts "!" to "/", so we could just use that?

Because that would break the LSB naming standard of these devices,
making things backwardly incompatible.  Is that something you want to
push through lkml on your own just to alleviate a single line in a udev
file?

Please, be realistic here.

greg k-h

Re: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 15:29 -0700, Greg KH wrote:

> On Mon, Aug 11, 2008 at 06:06:46PM +0100, Scott James Remnant wrote:
> > On Mon, 2008-08-11 at 09:58 -0700, Greg KH wrote:
> > 
> > > On Mon, Aug 11, 2008 at 06:48:19PM +0200, Marco d'Itri wrote:
> > > > On Aug 11, Greg KH <greg@kroah.com> wrote:
> > > > 
> > > > > Where does the kernel not give the "right" name today?
> > > > 
> > > > For a start:
> > > 
> > > The large majority of those are because you want a subdirectory to make
> > > things pretty.  The kernel can't do anything about that.
> > > 
> > Why not?
> > 
> > We have the source code to the kernel.
> > 
> > The patch to allow "/" in device names, as exported to user space, must
> > be trivial?
> > 
> > udev already converts "!" to "/", so we could just use that?
> 
> Because that would break the LSB naming standard of these devices,
> making things backwardly incompatible.  Is that something you want to
> push through lkml on your own just to alleviate a single line in a udev
> file?
> 
What LSB naming standard?

Do you mean the LANANA Linux Allocated Devices list?

In which case, I humbly submit the following quote:

 13 char        Input core
                  0 = /dev/input/js0    First joystick
                  1 = /dev/input/js1    Second joystick
                    ...
                 32 = /dev/input/mouse0 First mouse
                 33 = /dev/input/mouse1 Second mouse
                    ...
                 63 = /dev/input/mice   Unified mouse
                 64 = /dev/input/event0 First event queue
                 65 = /dev/input/event1 Second event queue

Right now, Linux names these wrongly in the kernel.

My patches would simply restore Linux to match the naming 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: default udev rules

[Scott James Remnant]

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

On Mon, 2008-08-11 at 15:28 -0700, Greg KH wrote:

> > Especially when the kernel had all the bits, and could have just set the
> > default static name in the first place.
> 
> Examples please, I really don't know how the kernel can do this for the
> things that we create persistant names for today.  Do you?
> 
The usb_device name.  The kernel could call it usb/NNN/NNN if it wanted;
instead it chooses to call it usbdevNNN.NNN

Things like symlinks are entirely in udev's court, I have no problem
with that.

All I'm arguing for is that if we're agreeing on standard names for all
distributions, we make that a true standard and make the kernel agree
with those names -- so the default udev rules don't need any NAME=
except for things like persistence of enumeration.

Scott
-- 
Scott James Remnant
scott@canonical.com

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

Re: default udev rules

[Greg KH]

On Tue, Aug 12, 2008 at 12:40:09AM +0100, Scott James Remnant wrote:
> On Mon, 2008-08-11 at 15:29 -0700, Greg KH wrote:
> 
> > On Mon, Aug 11, 2008 at 06:06:46PM +0100, Scott James Remnant wrote:
> > > On Mon, 2008-08-11 at 09:58 -0700, Greg KH wrote:
> > > 
> > > > On Mon, Aug 11, 2008 at 06:48:19PM +0200, Marco d'Itri wrote:
> > > > > On Aug 11, Greg KH <greg@kroah.com> wrote:
> > > > > 
> > > > > > Where does the kernel not give the "right" name today?
> > > > > 
> > > > > For a start:
> > > > 
> > > > The large majority of those are because you want a subdirectory to make
> > > > things pretty.  The kernel can't do anything about that.
> > > > 
> > > Why not?
> > > 
> > > We have the source code to the kernel.
> > > 
> > > The patch to allow "/" in device names, as exported to user space, must
> > > be trivial?
> > > 
> > > udev already converts "!" to "/", so we could just use that?
> > 
> > Because that would break the LSB naming standard of these devices,
> > making things backwardly incompatible.  Is that something you want to
> > push through lkml on your own just to alleviate a single line in a udev
> > file?
> > 
> What LSB naming standard?
> 
> Do you mean the LANANA Linux Allocated Devices list?

Yes, LSB specifies that LANANA is the standard.

> In which case, I humbly submit the following quote:
> 
>  13 char        Input core
>                   0 = /dev/input/js0    First joystick
>                   1 = /dev/input/js1    Second joystick
>                     ...
>                  32 = /dev/input/mouse0 First mouse
>                  33 = /dev/input/mouse1 Second mouse
>                     ...
>                  63 = /dev/input/mice   Unified mouse
>                  64 = /dev/input/event0 First event queue
>                  65 = /dev/input/event1 Second event queue
> 
> Right now, Linux names these wrongly in the kernel.

Great, patches accepted :)

good luck,

greg k-h

Re: default udev rules

[Kay Sievers]

On Mon, Aug 11, 2008 at 18:58, Greg KH <greg@kroah.com> wrote:
> On Mon, Aug 11, 2008 at 06:48:19PM +0200, Marco d'Itri wrote:
>> On Aug 11, Greg KH <greg@kroah.com> wrote:
>>
>> > Where does the kernel not give the "right" name today?
>>
>> For a start:
>
> The large majority of those are because you want a subdirectory to make
> things pretty.  The kernel can't do anything about that.
>
> But some of them do look like the real name should be changed, like
> these:
>
>> KERNEL="zapctl",               NAME="zap/ctl"
>> KERNEL="zapchannel",           NAME="zap/channel"
>> KERNEL="zappseudo",            NAME="zap/pseudo"
>> KERNEL="zaptimer",             NAME="zap/timer"
>
> Anyone send upstream a patch to do so?

Seems that this driver is not upstream. It also changed its name to
"dahdi", so we can drop these rules I guess. And it already has new
names:
        (dahdi_class, MKDEV(DAHDI_MAJOR, 253), NULL, "dahditimer");
        (dahdi_class, MKDEV(DAHDI_MAJOR, 254), NULL, "dahdichannel");
        (dahdi_class, MKDEV(DAHDI_MAJOR, 255), NULL, "dahdipseudo");
        (dahdi_class, MKDEV(DAHDI_MAJOR, 0), NULL, "dahdictl");

The driver comes with a set of udev rules, I guess someone should
suggest the authors to rename the devices to prefix with "dahdi!*", so
they are no longer needed.

Kay

Re: default udev rules

[H. Peter Anvin]

Kay Sievers wrote:
> 
> Sure, but how would we handle the bugs we create by renaming:
>   /sys/class/input/mouse0/
> to
>   /sys/class/input/input!mouse0/
> 
> Add another file with a suggested name and perms to sysfs? :)
> 

Well, first of all, please actually implement the ! -> / convention (we 
convert / to ! in sysfs by necessity; udev needs to undo this)...

	-hpa

Re: default udev rules

[H. Peter Anvin]

H. Peter Anvin wrote:
> Kay Sievers wrote:
>>
>> Sure, but how would we handle the bugs we create by renaming:
>>   /sys/class/input/mouse0/
>> to
>>   /sys/class/input/input!mouse0/
>>
>> Add another file with a suggested name and perms to sysfs? :)
>>
> 
> Well, first of all, please actually implement the ! -> / convention (we 
> convert / to ! in sysfs by necessity; udev needs to undo this)...
> 

n/m, it already does this (should learn to finish reading the thread.)

	-hpa

Re: default udev rules

[Harald Hoyer]

Kay Sievers wrote:
>> If 40-video.rules can be added to
>> 50-udev-default.rules we can be very happy -:)
> 
> The assignment to the group "video"? Yeah, I like to have that too,
> there is nothing else left in the suse.rules.
> 
> Harald, any problems, if we add group "video" to some video devices,
> seems we all need that, and it's useful even with the ACL stuff we do
> for frame grabber services/webcam daemons/fluendo stuff, and such.

video will be in our standard group file. see 
https://bugzilla.redhat.com/show_bug.cgi?idE8843

Re: default udev rules

[Kay Sievers]

On Tue, Nov 18, 2008 at 18:39, Harald Hoyer <harald@redhat.com> wrote:
> Kay Sievers wrote:
>>>
>>> If 40-video.rules can be added to
>>> 50-udev-default.rules we can be very happy -:)
>>
>> The assignment to the group "video"? Yeah, I like to have that too,
>> there is nothing else left in the suse.rules.
>>
>> Harald, any problems, if we add group "video" to some video devices,
>> seems we all need that, and it's useful even with the ACL stuff we do
>> for frame grabber services/webcam daemons/fluendo stuff, and such.
>
> video will be in our standard group file. see
> https://bugzilla.redhat.com/show_bug.cgi?idE8843

Great! Another distro rule can be removed. Small steps, but we will
get there. :)

Thanks!

Kay

Re: default udev rules

[Piter PUNK]

Kay Sievers wrote:
> On Tue, Nov 18, 2008 at 18:39, Harald Hoyer <harald@redhat.com> wrote:
>> Kay Sievers wrote:
>>>> If 40-video.rules can be added to
>>>> 50-udev-default.rules we can be very happy -:)
>>> The assignment to the group "video"? Yeah, I like to have that too,
>>> there is nothing else left in the suse.rules.
>>>
>>> Harald, any problems, if we add group "video" to some video devices,
>>> seems we all need that, and it's useful even with the ACL stuff we do
>>> for frame grabber services/webcam daemons/fluendo stuff, and such.
>> video will be in our standard group file. see
>> https://bugzilla.redhat.com/show_bug.cgi?idE8843
> 
> Great! Another distro rule can be removed. Small steps, but we will
> get there. :)

Great!
slackware.rules is being smaller and smaller -:)

Piter PUNK


-- 
     |        E-Mail: piterpk@terra.com.br
    .|.
    /V\
   // \\      UIN:116043354  Homepage:http://piterpunk.info02.com.br
  /(   )\
   ^`~'^         ----> Slackware Linux <----
  #105432