new version of udev has different cd/dvd devices

new version of udev has different cd/dvd devices

[Moshe Yudkowsky]

I have two DVD drives:

 > ATA:1,0,0            HL-DT-ST, RW/DVD GCC-4320B, 1.01
 > ATA:1,1,0            TSSTcorp, CD/DVDW TS-H552B, TS04


Previous versions of udev put the first drive into /dev/cdrom and 
/dev/cdrw; the 2nd drive became /dev/dvdrw and perhaps some other drives 
that I can't recall offhand.

The latest udev (0.079) puts the second drive only for /dev/cdrom, cdrw, 
  dvd, and dvdrw.

Is this a deliberate policy change, some problem with my system (I had 
to do a manual "modprobe ide-cd"), or a packaging issue? I'd like a 
broad hint before I start to chase it down.

I could write my own rule, but if it's an unintentional change, then 
it's going to affect a lot of people (my old fstab no longer works with 
this new alias popping up).

-- 
  Moshe Yudkowsky
  work: http://www.Disaggregate.com
  book: http://www.PebbleAndAvalanche.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Marco d'Itri]

On Dec 28, Moshe Yudkowsky <msha5_17@bl.com> wrote:

> The latest udev (0.079) puts the second drive only for /dev/cdrom, cdrw, 
>  dvd, and dvdrw.
Do not use %e in rules.

-- 
ciao,
Marco


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Kay Sievers]

On Wed, Dec 28, 2005 at 11:50:00PM +0100, Marco d'Itri wrote:
> On Dec 28, Moshe Yudkowsky <msha5_17@bl.com> wrote:
> 
> > The latest udev (0.079) puts the second drive only for /dev/cdrom, cdrw, 
> >  dvd, and dvdrw.
> Do not use %e in rules.

Yes, %e will be removed in one of the next versions for that reason. It
never worked reliably outside of udevstart, which is no longer
recommended to use.

Yuu can match on ENV{ID_PATH} with custom rules for every device. On
SUSE, the system management creates rules on installation or update, to
have always the same names for optical drives, regardless of the order
of discovery:

  $ cat /etc/udev/rules.d/65-cdrom.rules
  # cdrom links generated by YaST2
  #
  SUBSYSTEM="block", ENV{ID_PATH}="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrecorder cdrom"

Distros could also have a "default" rule, which catches unconfigured
devices and automatically creates a rule for them to keep the name
stable across reboots.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Moshe Yudkowsky]

Marco d'Itri wrote:
> On Dec 28, Moshe Yudkowsky <msha5_17@bl.com> wrote:
> 
> 
>>The latest udev (0.079) puts the second drive only for /dev/cdrom, cdrw, 
>> dvd, and dvdrw.

the udev distro under Debian has these rules:

> ENV{ID_CDROM}="?*",            SYMLINK+="cdrom%e"
> ENV{ID_CDROM_CD_RW}="?*",      SYMLINK+="cdrw%e"
> ENV{ID_CDROM_DVD}="?*",        SYMLINK+="dvd%e"
> ENV{ID_CDROM_DVD_R}="?*",      SYMLINK+="dvdrw%e"


When I modify them to remove the "%e":

> ENV{ID_CDROM}="?*",		SYMLINK+="cdrom"
> ENV{ID_CDROM_CD_RW}="?*",	SYMLINK+="cdrw"
> ENV{ID_CDROM_DVD}="?*",	SYMLINK+="dvd"
> ENV{ID_CDROM_DVD_R}="?*",	SYMLINK+="dvdrw"

followed by rmmod ide-cd, modprobe ide-cd, I get the same behavior:

> lrwxrwxrwx 1 root root 30 Dec 28 17:29 /dev/cdrom -> ide/host0/bus1/target1/lun0/cd
> lrwxrwxrwx 1 root root 30 Dec 28 17:29 /dev/cdrw -> ide/host0/bus1/target1/lun0/cd

I.e., they're both pointing to the same drive.

udevmonitor --env reveals what the problem seems to be:

First comes the 1,1,0 drive:

> UDEV  [1135814449.322164] remove@/block/hdd
> UDEV_LOG=3
> ACTION=remove
> DEVPATH=/block/hdd
> SUBSYSTEM=block
> SEQNUM\x1166
> MINORd
> MAJOR"
> PHYSDEVPATH=/devices/ide1/1.1
> PHYSDEVBUS=ide
> PHYSDEVDRIVER=ide-cdrom
> UDEVD_EVENT=1
> DEVNAME=/dev/ide/host0/bus1/target1/lun0/cd
> ID_CDROM=1
> ID_CDROM_CD_R=1
> ID_CDROM_CD_RW=1
> ID_CDROM_DVD=1
> ID_CDROM_DVD_R=1
> ID_CDROM_MRW=1
> ID_CDROM_MRW_W=1
> ID_CDROM_RAM=1
> ID_TYPEÍ
> ID_MODEL=TSSTcorpCDDVDW_TS-H552B
> ID_SERIAL=TS-H552BFirmware
> ID_REVISION=TS04
> ID_BUS=ata
> ID_PATH=pcmcia--ide-1:1

Next comes the 1,0,0 drive:

> UDEV  [1135814449.429480] remove@/block/hdc
> UDEV_LOG=3
> ACTION=remove
> DEVPATH=/block/hdc
> SUBSYSTEM=block
> SEQNUM\x1167
> MINOR=0
> MAJOR"
> PHYSDEVPATH=/devices/ide1/1.0
> PHYSDEVBUS=ide
> PHYSDEVDRIVER=ide-cdrom
> UDEVD_EVENT=1
> DEVNAME=/dev/ide/host0/bus1/target0/lun0/cd
> ID_CDROM=1
> ID_CDROM_CD_R=1
> ID_CDROM_CD_RW=1
> ID_CDROM_DVD=1
> ID_CDROM_MRW=1
> ID_CDROM_MRW_W=1
> ID_CDROM_RAM=1
> ID_TYPEÍ
> ID_MODEL=HL-DT-ST_RWDVD_GCC-4320B
> ID_SERIAL> ID_REVISION=1.01
> ID_BUS=ata
> ID_PATH=pcmcia--ide-1:0

In other words, the rules match either drive completely, if I'm reading 
the rules correctly.

In the meantime, I've modified fstab to use /dev/cdroms/cdrom{0,1}, but 
it'd be nice to figure out what happened here!


-- 
Moshe Yudkowsky * moshe@pobox.com * www.pobox.com/~moshe
  "The price of a tyrant's victory is eternal vigilance... This was
   once considered the price of liberty. Nothing buys what it used to."
    				-- Pat Cadigan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Marco d'Itri]

On Dec 29, Moshe Yudkowsky <moshe@pobox.com> wrote:

> When I modify them to remove the "%e":
What we were trying to explain is that you should write your own rules
which statically assign specific aliases to specific devices.
cd-aliases.rules even already contains an example of this.

-- 
ciao,
Marco


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Moshe Yudkowsky]

Marco d'Itri wrote:
> On Dec 29, Moshe Yudkowsky <moshe@pobox.com> wrote:
> 
> 
>>When I modify them to remove the "%e":
> 
> What we were trying to explain is that you should write your own rules
> which statically assign specific aliases to specific devices.
> cd-aliases.rules even already contains an example of this.

Thanks. The email from Kay arrived just after I'd sent off my previous 
response, and then I understood what you and he were driving at.

Thanks for your patience!

By the way, Looking through the ENV as reported, I don't see any 
variable such as ID_CDROM_DVD_RW, which would allow me to distinguish 
between a DVD-R and a DVD-RW. Am I correct that no variable exists?


-- 
  Moshe Yudkowsky
  work: http://www.Disaggregate.com
  book: http://www.PebbleAndAvalanche.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Phil Howard]

On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote:

| On Wed, Dec 28, 2005 at 11:50:00PM +0100, Marco d'Itri wrote:
| > On Dec 28, Moshe Yudkowsky <msha5_17@bl.com> wrote:
| > 
| > > The latest udev (0.079) puts the second drive only for /dev/cdrom, cdrw, 
| > >  dvd, and dvdrw.
| > Do not use %e in rules.
| 
| Yes, %e will be removed in one of the next versions for that reason. It
| never worked reliably outside of udevstart, which is no longer
| recommended to use.

What is recommended to use in place of udevstart for initial populating?

Actually, I'm not expecting to use udevstart.  Rather, I am expecting to
integrate code from udevstart and/or other parts of udev into my early
userspace init program.  It will start with nothing but rootfs mounted,
and need some /dev entries to find devices to be mounted.  Since /dev
will end up being tmpfs in the end, it seems to make sense to go ahead
and populate it at this point.  There will only be /dev (tmpfs) and /sys
(sysfs) mounted at that point in time ... no /etc ... so this is a big
reason I can't just literally use udevstart as is, anyway.

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Marco d'Itri]

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

On Dec 29, Phil Howard <phil-linux-hotplug-devel@ipal.net> wrote:

> What is recommended to use in place of udevstart for initial populating?
Look at the many distribution-specific scripts which walk sysfs and poke
the uevent files.

-- 
ciao,
Marco

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

Re: new version of udev has different cd/dvd devices

[Phil Howard]

On Thu, Dec 29, 2005 at 02:36:29PM +0100, Marco d'Itri wrote:

| On Dec 29, Phil Howard <phil-linux-hotplug-devel@ipal.net> wrote:
| 
| > What is recommended to use in place of udevstart for initial populating?
| Look at the many distribution-specific scripts which walk sysfs and poke
| the uevent files.

So basically there isn't anything in udev?

Since I'm writing in C, I suspect udevstart would be more meaningful.
One thing I'd need to explore is parsing issues for sysfs data.  But
how scripts would parse it could be different than what might be done
in C.  The first need for /dev will be long before the system could
run a shell.

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Kay Sievers]

On Thu, Dec 29, 2005 at 09:18:40AM -0600, Phil Howard wrote:
> On Thu, Dec 29, 2005 at 02:36:29PM +0100, Marco d'Itri wrote:
> 
> | On Dec 29, Phil Howard <phil-linux-hotplug-devel@ipal.net> wrote:
> | 
> | > What is recommended to use in place of udevstart for initial populating?
> | Look at the many distribution-specific scripts which walk sysfs and poke
> | the uevent files.
> 
> So basically there isn't anything in udev?

No, not in the tree. It's about a few lines of shell script.

> Since I'm writing in C, I suspect udevstart would be more meaningful.

Udevstart is dead and will stay as it is, until it will be removed at
the time the "uevent" file triggers are common and udevstart is no longer
needed.

> One thing I'd need to explore is parsing issues for sysfs data.  But
> how scripts would parse it could be different than what might be done
> in C.

Ubuntu has "udevplug" which is in C, Fedora has patched udevd to to do
the "uevent" file triggers. For SUSE, I'm perfectly fine with the shell
script as it is the most flexible and best to tweak and debug option for
me. We will see if we end in a common solution some day.

> The first need for /dev will be long before the system could
> run a shell.

That's just plain wrong.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Greg KH]

On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote:
> On Wed, Dec 28, 2005 at 11:50:00PM +0100, Marco d'Itri wrote:
> > On Dec 28, Moshe Yudkowsky <msha5_17@bl.com> wrote:
> > 
> > > The latest udev (0.079) puts the second drive only for /dev/cdrom, cdrw, 
> > >  dvd, and dvdrw.
> > Do not use %e in rules.
> 
> Yes, %e will be removed in one of the next versions for that reason. It
> never worked reliably outside of udevstart, which is no longer
> recommended to use.

Yeah, but we still need a way to enumerate devices in some kind of
order, like we do for the cdrom devices today.  So I don't think we can
drop it entirely.

> Yuu can match on ENV{ID_PATH} with custom rules for every device. On
> SUSE, the system management creates rules on installation or update, to
> have always the same names for optical drives, regardless of the order
> of discovery:
> 
>   $ cat /etc/udev/rules.d/65-cdrom.rules
>   # cdrom links generated by YaST2
>   #
>   SUBSYSTEM="block", ENV{ID_PATH}="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrecorder cdrom"
> 
> Distros could also have a "default" rule, which catches unconfigured
> devices and automatically creates a rule for them to keep the name
> stable across reboots.

Or we can just stick with the rules we have today that use %e just fine,
as it emulates exactly what a static /dev would have done, and no one is
complaining about it :)

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Phil Howard]

On Thu, Dec 29, 2005 at 05:57:23PM +0100, Kay Sievers wrote:

| On Thu, Dec 29, 2005 at 09:18:40AM -0600, Phil Howard wrote:
| > On Thu, Dec 29, 2005 at 02:36:29PM +0100, Marco d'Itri wrote:

[...]

| > The first need for /dev will be long before the system could
| > run a shell.
| 
| That's just plain wrong.

My first need for it sure is.  It's in an early user space init program.
Some prototype code I have worked on just a bunch of mknod(2) calls for
now to set up a few devices I know my machines have.  The next step in
this project is to get away from statically coded devices and utilize
what is in sysfs to build /dev.  From there, it will then have devices
it can mount filesystems with.

My project isn't really about hotplugging anything.  Once the full system
is up and running, then the init scripts can start up whatever deamon is
needed, etc.  But I need to get at least some devices made in /dev so they
can be used, such as /dev/console and any block device that could have a
filesystem.  Other devices may be able to be deferred until later.

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Marco d'Itri]

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

On Dec 30, Greg KH <greg@kroah.com> wrote:

> Or we can just stick with the rules we have today that use %e just fine,
> as it emulates exactly what a static /dev would have done, and no one is
> complaining about it :)
People are complaining about it because events are not received in bus
order anymore, so the names randomly change (and since there is no
locking often the same links is created for two devices).

But still, I'd rather keep it as long as possible since half broken is
better than totally broken and I do not have a replacement ready.

-- 
ciao,
Marco

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

Re: new version of udev has different cd/dvd devices

[Darren Salt]

I demand that Greg KH may or may not have written...

> On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote:
[snip; creating static rules on-the-fly]
>> Distros could also have a "default" rule, which catches unconfigured
>> devices and automatically creates a rule for them to keep the name stable
>> across reboots.

> Or we can just stick with the rules we have today that use %e just fine, as
> it emulates exactly what a static /dev would have done, and no one is
> complaining about it :)

Well, other than that it's become broken along with various other things (in
my case, ALSA sound device numbering; fortunately, the machine in question
has just the one external network interface) due to a change elsewhere. And
we all know what that change is, don't we :-)

A switch which says "process events in series" or "process events which match
this rule in series" (hmm, groups of rules?) would do for my purposes. Faster
booting's all well and good, but I think that the cost is just a little bit
too high in this case.

-- 
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   I don't ask for much, just untold riches...

You don't know what you want, and are willing to go through hell to get it.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Kay Sievers]

On Fri, Dec 30, 2005 at 07:09:20PM +0100, Marco d'Itri wrote:
> On Dec 30, Greg KH <greg@kroah.com> wrote:
> 
> > Or we can just stick with the rules we have today that use %e just fine,
> > as it emulates exactly what a static /dev would have done, and no one is
> > complaining about it :)
> People are complaining about it because events are not received in bus
> order anymore, so the names randomly change (and since there is no
> locking often the same links is created for two devices).

Exactly. That's the reason, why it will be removed.

> But still, I'd rather keep it as long as possible since half broken is
> better than totally broken and I do not have a replacement ready.

That doesn't makes sense. %e it conceptually completely broken and
offering something that can't work does not give any value. Just get rid
of _any_ simple enumeration, for exactly the same reason a kernel devfs
is complete useless.

Write out a rule at discovery (from udev itself) for every unconfigured
device and you get a sane enumeration, that will not change at next boot.
If people want other names or different numbers, they can just edit the
automatically created rules or add custom ones. SUSE does this for
persistent network interface names, which works pretty well.

Writing out rules is reliable, predictable and one can understand what's
going on. The %e is unfixable and will definitely die some day.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Kay Sievers]

On Thu, Dec 29, 2005 at 11:46:59PM -0800, Greg KH wrote:
> On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote:
> > On Wed, Dec 28, 2005 at 11:50:00PM +0100, Marco d'Itri wrote:
> > > On Dec 28, Moshe Yudkowsky <msha5_17@bl.com> wrote:
> > > 
> > > > The latest udev (0.079) puts the second drive only for /dev/cdrom, cdrw, 
> > > >  dvd, and dvdrw.
> > > Do not use %e in rules.
> > 
> > Yes, %e will be removed in one of the next versions for that reason. It
> > never worked reliably outside of udevstart, which is no longer
> > recommended to use.
> 
> Yeah, but we still need a way to enumerate devices in some kind of
> order, like we do for the cdrom devices today.  So I don't think we can
> drop it entirely.

We don't have any "order", that's why we can't do it that way. The
persistent /dev/disk links are working without any "order", that's the
model to follow, or writing out "automatic rules" to provide stable names.
Everything else will just not work.

> > Yuu can match on ENV{ID_PATH} with custom rules for every device. On
> > SUSE, the system management creates rules on installation or update, to
> > have always the same names for optical drives, regardless of the order
> > of discovery:
> > 
> >   $ cat /etc/udev/rules.d/65-cdrom.rules
> >   # cdrom links generated by YaST2
> >   #
> >   SUBSYSTEM="block", ENV{ID_PATH}="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrecorder cdrom"
> > 
> > Distros could also have a "default" rule, which catches unconfigured
> > devices and automatically creates a rule for them to keep the name
> > stable across reboots.
> 
> Or we can just stick with the rules we have today that use %e just fine,
> as it emulates exactly what a static /dev would have done, and no one is
> complaining about it :)

No, %e doesn't work "fine" without udevstart. Device names switch with
every reboot, depending on random device response and process running
time, which is unacceptable and %e must be avoided for that reason. And
worse, %e does not use locking, so for parallel probing, it will return
the same names for different devices, if they are requested in parallel
in a short timeframe.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Darren Salt]

I demand that Kay Sievers may or may not have written...

> On Fri, Dec 30, 2005 at 07:09:20PM +0100, Marco d'Itri wrote:
>> On Dec 30, Greg KH <greg@kroah.com> wrote:
>>> Or we can just stick with the rules we have today that use %e just fine,
>>> as it emulates exactly what a static /dev would have done, and no one is
>>> complaining about it :)
>> People are complaining about it because events are not received in bus
>> order anymore, so the names randomly change (and since there is no locking
>> often the same links is created for two devices).

> Exactly. That's the reason why it will be removed.

So, basically, you're removing something which *worked* here because of an
unrelated change which broke it.

>> But still, I'd rather keep it as long as possible since half broken is
>> better than totally broken and I do not have a replacement ready.

> That doesn't makes sense. %e it conceptually completely broken and offering
> something that can't work does not give any value.

Can you provide instances in which it *doesn't* work, given events received
in bus order?

> Just get rid of _any_ simple enumeration, for exactly the same reason a
> kernel devfs is completely useless.

I don't think so - AFAIK, use of "%e" doesn't cause processes to hang due to
implementation bugs. (And that is, AIUI, exactly why the kernel devfs is
useless.)

> Write out a rule at discovery (from udev itself) for every unconfigured
> device and you get a sane enumeration, that will not change at next boot.

ITYM "sane enumeration that will not change".

If, with no devices previously configured, it differs from what would be done
with events sorted into bus order, I for one will consider it broken for the
simple reason that it cannot be predicted from bus order.

What about device removal? What about swapping devices due to (for example)
interrupt problems? What about plugging the same (hot-pluggable) device into
a different port?

[snip]
> Writing out rules is reliable, predictable and one can understand what's
> going on.

I'd say exactly that about %e and module probing, as was before the event
order was randomised.

> The %e is unfixable and will definitely die some day.

Right now, to me, it looks fixable.

-- 
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   Let's keep the pound sterling

..and the great tagline hunter crouches silently, text editor at the ready..


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Kay Sievers]

On Fri, Dec 30, 2005 at 06:16:54PM +0000, Darren Salt wrote:
> I demand that Greg KH may or may not have written...
> 
> > On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote:
> [snip; creating static rules on-the-fly]
> >> Distros could also have a "default" rule, which catches unconfigured
> >> devices and automatically creates a rule for them to keep the name stable
> >> across reboots.
> 
> > Or we can just stick with the rules we have today that use %e just fine, as
> > it emulates exactly what a static /dev would have done, and no one is
> > complaining about it :)
> 
> Well, other than that it's become broken along with various other things (in
> my case, ALSA sound device numbering; fortunately, the machine in question
> has just the one external network interface) due to a change elsewhere. And
> we all know what that change is, don't we :-)
> 
> A switch which says "process events in series" or "process events which match
> this rule in series" (hmm, groups of rules?) would do for my purposes. Faster
> booting's all well and good, but I think that the cost is just a little bit
> too high in this case.

Forget "order" of devices on a system where everything can come and go
at any time. The time can we configure a system once at installation is long
over.
Make the system aware of persistent properties and use that. It can
all work automatically if done right. There is simply no "order"
anymore we could rely on. So start to think in the right direction and
help solving the real problems instead.

It has nothing to do with "faster booting", it's about dynamic system
configuration. You can't have both at the same time: hotplug and static
configured systems. But if we do it right, we can have a completely dynamic
system, that works reliable and is predictable. But that has absolutely
nothing to do with device probing order, kernel device names, or devfs-like
naming schemes.

Thanks,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Darren Salt]

I demand that Kay Sievers may or may not have written...

> On Fri, Dec 30, 2005 at 06:16:54PM +0000, Darren Salt wrote:
>> I demand that Greg KH may or may not have written...

>>> On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote:
>> [snip; creating static rules on-the-fly]
>>>> Distros could also have a "default" rule, which catches unconfigured
>>>> devices and automatically creates a rule for them to keep the name
>>>> stable across reboots.

>>> Or we can just stick with the rules we have today that use %e just fine,
>>> as it emulates exactly what a static /dev would have done, and no one is
>>> complaining about it :)

>> Well, other than that it's become broken along with various other things
>> (in my case, ALSA sound device numbering; fortunately, the machine in
>> question has just the one external network interface) due to a change
>> elsewhere. And we all know what that change is, don't we :-)

>> A switch which says "process events in series" or "process events which
>> match this rule in series" (hmm, groups of rules?) would do for my
>> purposes. Faster booting's all well and good, but I think that the cost is
>> just a little bit too high in this case.

> Forget "order" of devices on a system where everything can come and go at
> any time.

Hmm. Drivers built into the kernel, devices require shutdown for
replacement... well, that's the case for my DVD drives.

> The time can we configure a system once at installation is long over.

I don't recall making any mention of one-time configuration.

> Make the system aware of persistent properties and use that. It can all
> work automatically if done right.

It was done right before, at least for those of us for whom the bus order
happens to be the order which we want for devices which are normally present
at boot. If others need something else, fine, add that...

> There is simply no "order" anymore we could rely on.

Bus address? Or does that change on reboot too...

> So start to think in the right direction and help solving the real problems
> instead.

=> fix the regression by restoring previous behaviour. That would solve the
real problem that I'm seeing.

> It has nothing to do with "faster booting",

I *could* be conflating or misunderstanding things here...

> it's about dynamic system configuration. You can't have both at the same
> time: hotplug and static configured systems.

Well, of course not: a static system would completely preclude the
possibility of hotplugging.

Now, if you mean "statically configured system"... let's say "statically
configured subsystem" instead. This tends to be PCI, IDE and maybe some
others or parts of others, and these tend to be fixed. (Yes, I'm aware that
there are hot-pluggable implementations...)

I don't see what the problem is with automatically allocating names in a
reliable manner to fixed devices. If you want a fixed name for something
hot-pluggable, fine, write some extra rules.

> But if we do it right, we can have a completely dynamic system, that works
> reliably and is predictable.

Hmm? ISTM that we _had_ that.

> But that has absolutely nothing to do with device probing order, kernel
> device names,

Er, yes it does. Device naming worked here because of them.

> or devfs-like naming schemes.

I didn't mention that...


Maybe some symlinks in the static /dev should be used as seeds for
udev-managed /dev? That'd provide some or possibly all of the fixed device
names, avoid some rule writing, and provide the same naming for those devices
in emergency-boot situations (where I tend to use init=/bin/sh and expect
/dev/hdaX to be mounted).

[snip]
-- 
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)

There are no giant crabs in here, Frank.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Kay Sievers]

On Fri, Dec 30, 2005 at 07:12:21PM +0000, Darren Salt wrote:
> I demand that Kay Sievers may or may not have written...
> 
> > On Fri, Dec 30, 2005 at 07:09:20PM +0100, Marco d'Itri wrote:
> >> On Dec 30, Greg KH <greg@kroah.com> wrote:
> >>> Or we can just stick with the rules we have today that use %e just fine,
> >>> as it emulates exactly what a static /dev would have done, and no one is
> >>> complaining about it :)
> >> People are complaining about it because events are not received in bus
> >> order anymore, so the names randomly change (and since there is no locking
> >> often the same links is created for two devices).
> 
> > Exactly. That's the reason why it will be removed.
> 
> So, basically, you're removing something which *worked* here because of an
> unrelated change which broke it.

It never worked reliably for modular kernels.

> >> But still, I'd rather keep it as long as possible since half broken is
> >> better than totally broken and I do not have a replacement ready.
> 
> > That doesn't makes sense. %e it conceptually completely broken and offering
> > something that can't work does not give any value.
> 
> Can you provide instances in which it *doesn't* work, given events received
> in bus order?

Plug in/out any device on any bus, reboot and all your silly numbers will
change. That's no longer acceptable with current system requirements.

> > Just get rid of _any_ simple enumeration, for exactly the same reason a
> > kernel devfs is completely useless.
> 
> I don't think so - AFAIK, use of "%e" doesn't cause processes to hang due to
> implementation bugs. (And that is, AIUI, exactly why the kernel devfs is
> useless.)

No, devfs is useless, cause it simply enumerates based on discovery
order, that does not help anything if devices come and go, which can
happen anytime with recent kernels and stuff like pci hotplug ...

> > Write out a rule at discovery (from udev itself) for every unconfigured
> > device and you get a sane enumeration, that will not change at next boot.
> 
> ITYM "sane enumeration that will not change".

There is by concept no "sane enumeration" on a dynamic system and will
never be. But seem you don't get the picture at all.

> If, with no devices previously configured, it differs from what would be done
> with events sorted into bus order, I for one will consider it broken for the
> simple reason that it cannot be predicted from bus order.

Again, seems you have absolutely no clue what all this is about, do your homework
before posting such nonsense.

> What about device removal? What about swapping devices due to (for example)
> interrupt problems? What about plugging the same (hot-pluggable) device into
> a different port?
> 
> [snip]
> > Writing out rules is reliable, predictable and one can understand what's
> > going on.
> 
> I'd say exactly that about %e and module probing, as was before the event
> order was randomised.

Nobody forces you to use it, it isn't even part of the udev tree. You
can stick with what you have or whatever you think is better.

> > The %e is unfixable and will definitely die some day.
> 
> Right now, to me, it looks fixable.

Good luck, go ahead. You will surprise me if you come up with something
useful.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Darren Salt]

I demand that Kay Sievers may or may not have written...

> On Fri, Dec 30, 2005 at 07:12:21PM +0000, Darren Salt wrote:
>> I demand that Kay Sievers may or may not have written...
>>> On Fri, Dec 30, 2005 at 07:09:20PM +0100, Marco d'Itri wrote:
>>>> On Dec 30, Greg KH <greg@kroah.com> wrote:
>>>>> Or we can just stick with the rules we have today that use %e just
>>>>> fine, as it emulates exactly what a static /dev would have done, and no
>>>>> one is complaining about it :)
>>>> People are complaining about it because events are not received in bus
>>>> order anymore, so the names randomly change (and since there is no
>>>> locking often the same links is created for two devices).
>>> Exactly. That's the reason why it will be removed.
>> So, basically, you're removing something which *worked* here because of an
>> unrelated change which broke it.

> It never worked reliably for modular kernels.

Hmm. I'm using mostly monolithic, and it's failing regardless.

>>>> But still, I'd rather keep it as long as possible since half broken is
>>>> better than totally broken and I do not have a replacement ready.
>>> That doesn't makes sense. %e it conceptually completely broken and
>>> offering something that can't work does not give any value.
>> Can you provide instances in which it *doesn't* work, given events
>> received in bus order?

> Plug in/out any device on any bus, reboot and all your silly numbers will
> change. That's no longer acceptable with current system requirements.

That's a known effect and, as such, can be routed around. For some devices, I
can see that this can be a problem; but for others, it may well be perfectly
acceptable.

I know that (given the previous, stable, naming) removing and not replacing
the sound card here in my main Linux box would cause the on-board sound
hardware to be "card 0" rather than "card 1". That's acceptable and expected
(I'm allowing ALSA to automatically number them because, until fairly
recently, this worked reliably).

[snip]
>>> Write out a rule at discovery (from udev itself) for every unconfigured
>>> device and you get a sane enumeration, that will not change at next boot.
>> ITYM "sane enumeration that will not change".

> There is by concept no "sane enumeration" on a dynamic system and will
> never be. But seem you don't get the picture at all.

If the user says that "these parts of the system are static" (and I say that
much of my system is static), why *shouldn't* some enumeration be considered
sane?

>> If, with no devices previously configured, it differs from what would be
>> done with events sorted into bus order, I for one will consider it broken
>> for the simple reason that it cannot be predicted from bus order.

> Again, seems you have absolutely no clue what all this is about, do your
> homework before posting such nonsense.

For "bus order", read "whatever order happens to have been used by older udev
which provides stable naming given the same hardware configuration". This
looks like bus order from where I'm sitting.

If a newly-upgraded udev happens to generate its own rules which provide
different naming, well, that's breakage right there: I could insert a disk
into one CDROM drive then be surprised that I get a "drive empty" error
because udev has called the wrong one (the writer, /dev/hdd) /dev/cdrom.


Do you understand that? :->

[snip]
-- 
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian,     | Northumberland | s zap,tartarus,org
| RISC OS     | Toon Army      | @
|   Retrocomputing: a PC card in a Risc PC

8 End of file, 0:1


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Kay Sievers]

On Fri, Dec 30, 2005 at 07:47:38PM +0000, Darren Salt wrote:
> I demand that Kay Sievers may or may not have written...
> 
> > On Fri, Dec 30, 2005 at 06:16:54PM +0000, Darren Salt wrote:
> >> I demand that Greg KH may or may not have written...
> 
> >>> On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote:
> >> [snip; creating static rules on-the-fly]
> >>>> Distros could also have a "default" rule, which catches unconfigured
> >>>> devices and automatically creates a rule for them to keep the name
> >>>> stable across reboots.
> 
> >>> Or we can just stick with the rules we have today that use %e just fine,
> >>> as it emulates exactly what a static /dev would have done, and no one is
> >>> complaining about it :)
> 
> >> Well, other than that it's become broken along with various other things
> >> (in my case, ALSA sound device numbering; fortunately, the machine in
> >> question has just the one external network interface) due to a change
> >> elsewhere. And we all know what that change is, don't we :-)
> 
> >> A switch which says "process events in series" or "process events which
> >> match this rule in series" (hmm, groups of rules?) would do for my
> >> purposes. Faster booting's all well and good, but I think that the cost is
> >> just a little bit too high in this case.
> 
> > Forget "order" of devices on a system where everything can come and go at
> > any time.
> 
> Hmm. Drivers built into the kernel, devices require shutdown for
> replacement... well, that's the case for my DVD drives.

Good luck if libata starts to handle parallel IDE  devices too. And _everthing_,
all block devices, becomes sd*, sr*, like recent SATA boxes alreay do.
Latest then, you better start to think about this.

> > The time can we configure a system once at installation is long over.
> 
> I don't recall making any mention of one-time configuration.

Sure, you did. %e is always "one-time" and relies on hardware that will
never change to provide predictable names. That's the whole point.

> > Make the system aware of persistent properties and use that. It can all
> > work automatically if done right.
> 
> It was done right before, at least for those of us for whom the bus order
> happens to be the order which we want for devices which are normally present
> at boot. If others need something else, fine, add that...

The other way around. If you like it how it is, keep it.

> > There is simply no "order" anymore we could rely on.
> 
> Bus address? Or does that change on reboot too...

Oh, you are coming closer. Bus addresses are the key, yes, but they have
usually nothing to do with enumerations by discovery order.

> > So start to think in the right direction and help solving the real problems
> > instead.
> 
> => fix the regression by restoring previous behaviour. That would solve the
> real problem that I'm seeing.

No we already have that problem. And removing unfixable crap, with a proper
preparation time _is_ the right fix. As said, keep it running, if you like it.

> > It has nothing to do with "faster booting",
> 
> I *could* be conflating or misunderstanding things here...


> > it's about dynamic system configuration. You can't have both at the same
> > time: hotplug and static configured systems.
> 
> Well, of course not: a static system would completely preclude the
> possibility of hotplugging.
> 
> Now, if you mean "statically configured system"... let's say "statically
> configured subsystem" instead. This tends to be PCI, IDE and maybe some
> others or parts of others, and these tend to be fixed. (Yes, I'm aware that
> there are hot-pluggable implementations...)

No, that's it. Nothing is "fixed" today. Everthing comes and goes all the
time on modern systems. If you don't use it, or unable to imagine it, that's
fine, but then start to think about it _before_ you write emails to public
lists and waste other people time.

> I don't see what the problem is with automatically allocating names in a
> reliable manner to fixed devices. If you want a fixed name for something
> hot-pluggable, fine, write some extra rules.
> 
> > But if we do it right, we can have a completely dynamic system, that works
> > reliably and is predictable.
> 
> Hmm? ISTM that we _had_ that.

We are far away from that. There is still whole lot of work to do. Again,
your sandbox may be much different from what's going on for dynamic device
management. Fine, if you are happy with it, so don't change it.

> > But that has absolutely nothing to do with device probing order, kernel
> > device names,
> 
> Er, yes it does. Device naming worked here because of them.

No, it worked if you were lucky and the system was "static enough". Read the
udev man page about %e, it is mentioned there for a long time.

> > or devfs-like naming schemes.
> 
> I didn't mention that...

It's almost the same, %e is a devfs like scheme, that doesn't make
sense if every reboot enumerates again from scratch.

> Maybe some symlinks in the static /dev should be used as seeds for
> udev-managed /dev? That'd provide some or possibly all of the fixed device
> names, avoid some rule writing, and provide the same naming for those devices
> in emergency-boot situations (where I tend to use init=/bin/sh and expect
> /dev/hdaX to be mounted).

How is that related? That's a distro issue and is a complete different
topic.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Kay Sievers]

On Fri, Dec 30, 2005 at 09:00:12PM +0000, Darren Salt wrote:
> I demand that Kay Sievers may or may not have written...
> 
> > On Fri, Dec 30, 2005 at 07:12:21PM +0000, Darren Salt wrote:
> >> I demand that Kay Sievers may or may not have written...
> >>> On Fri, Dec 30, 2005 at 07:09:20PM +0100, Marco d'Itri wrote:
> >>>> On Dec 30, Greg KH <greg@kroah.com> wrote:
> >>>>> Or we can just stick with the rules we have today that use %e just
> >>>>> fine, as it emulates exactly what a static /dev would have done, and no
> >>>>> one is complaining about it :)
> >>>> People are complaining about it because events are not received in bus
> >>>> order anymore, so the names randomly change (and since there is no
> >>>> locking often the same links is created for two devices).
> >>> Exactly. That's the reason why it will be removed.
> >> So, basically, you're removing something which *worked* here because of an
> >> unrelated change which broke it.
> 
> > It never worked reliably for modular kernels.
> 
> Hmm. I'm using mostly monolithic, and it's failing regardless.

Sure, that's expected, cause your naming rules are broken.

> >>>> But still, I'd rather keep it as long as possible since half broken is
> >>>> better than totally broken and I do not have a replacement ready.
> >>> That doesn't makes sense. %e it conceptually completely broken and
> >>> offering something that can't work does not give any value.
> >> Can you provide instances in which it *doesn't* work, given events
> >> received in bus order?
> 
> > Plug in/out any device on any bus, reboot and all your silly numbers will
> > change. That's no longer acceptable with current system requirements.
> 
> That's a known effect and, as such, can be routed around. For some devices, I
> can see that this can be a problem; but for others, it may well be perfectly
> acceptable.

"Some devices" concepts are exactly that we are working on to get rid
of. Why are you running an explicitely marked as "unstable" system, if you
have no clue what we are working on?

> I know that (given the previous, stable, naming) removing and not replacing
> the sound card here in my main Linux box would cause the on-board sound
> hardware to be "card 0" rather than "card 1". That's acceptable and expected
> (I'm allowing ALSA to automatically number them because, until fairly
> recently, this worked reliably).

Then you never used USB sound devices, like headsets or something
else. Again, if you lack of the needed experience in the area or ability
to imagine the picture, please stop posting this nonsense.

> [snip]
> >>> Write out a rule at discovery (from udev itself) for every unconfigured
> >>> device and you get a sane enumeration, that will not change at next boot.
> >> ITYM "sane enumeration that will not change".
> 
> > There is by concept no "sane enumeration" on a dynamic system and will
> > never be. But seem you don't get the picture at all.
> 
> If the user says that "these parts of the system are static" (and I say that
> much of my system is static), why *shouldn't* some enumeration be considered
> sane?

Cause _nothing_ is static today. Get used to it.

> >> If, with no devices previously configured, it differs from what would be
> >> done with events sorted into bus order, I for one will consider it broken
> >> for the simple reason that it cannot be predicted from bus order.
> 
> > Again, seems you have absolutely no clue what all this is about, do your
> > homework before posting such nonsense.
> 
> For "bus order", read "whatever order happens to have been used by older udev
> which provides stable naming given the same hardware configuration". This
> looks like bus order from where I'm sitting.

Repeating the same stuff again and again doesn't add any value to it.

> If a newly-upgraded udev happens to generate its own rules which provide
> different naming, well, that's breakage right there: I could insert a disk
> into one CDROM drive then be surprised that I get a "drive empty" error
> because udev has called the wrong one (the writer, /dev/hdd) /dev/cdrom.

No, definitely not. Your broken rules have renamed it. Fix them and
everthing is fine.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Darren Salt]

I demand that Kay Sievers may or may not have written...

> On Fri, Dec 30, 2005 at 09:00:12PM +0000, Darren Salt wrote:
>> I demand that Kay Sievers may or may not have written...
[snip]
>>> Plug in/out any device on any bus, reboot and all your silly numbers will
>>> change. That's no longer acceptable with current system requirements.
>> That's a known effect and, as such, can be routed around. For some
>> devices, I can see that this can be a problem; but for others, it may well
>> be perfectly acceptable.

> "Some devices" concepts are exactly that we are working on to get rid of.
> Why are you running an explicitely marked as "unstable" system, if you have
> no clue what we are working on?

I'm running what was currently in Debian testing when I last updated -
0.076-6.

>> I know that (given the previous, stable, naming) removing and not
>> replacing the sound card here in my main Linux box would cause the
>> on-board sound hardware to be "card 0" rather than "card 1". That's
>> acceptable and expected (I'm allowing ALSA to automatically number them
>> because, until fairly recently, this worked reliably).

> Then you never used USB sound devices, like headsets or something else.

In the case of USB sound devices, it is *possible* that I would already have
taken the time to explicitly number those (and the others if they turned out
to require numbering as a result), but I would have to have seen randomness
in udev's behaviour or some appropriate warning of such randomness.

I don't know about USB headsets or speakers, though. I'm avoiding such things
on the assumption that they're not compatible with my existing sound
hardware.

(It still seems to me to be breaking things which may be working for some
before adequate replacement is ready.)

[snip]
>>> There is by concept no "sane enumeration" on a dynamic system and will
>>> never be. But seem you don't get the picture at all.
>> If the user says that "these parts of the system are static" (and I say
>> that much of my system is static), why *shouldn't* some enumeration be
>> considered sane?

> Cause _nothing_ is static today. Get used to it.

Then the udev package which I'm using (076) should have contained appropriate
warnings. However, if this randomisation wasn't expected or noticed by the
packager...

Marco, have you done this for 079?

[snip]
-- 
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)

RISC OS 4 easter egg E3A00002 E28F1004 E3A02000 EF00001E 55515249 736C6974 00


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Darren Salt]

I demand that Kay Sievers may or may not have written...

> On Fri, Dec 30, 2005 at 07:47:38PM +0000, Darren Salt wrote:
>> I demand that Kay Sievers may or may not have written...
[snip]
>>> Forget "order" of devices on a system where everything can come and go at
>>> any time.
>> Hmm. Drivers built into the kernel, devices require shutdown for
>> replacement... well, that's the case for my DVD drives.

> Good luck if libata starts to handle parallel IDE  devices too. And
> _everthing_, all block devices, becomes sd*, sr*,

Ouch.

(Hmm, fd* are block devices... ;-) )

> like recent SATA boxes alreay do.

I'm aware that some people were caught out by that...

> Latest then, you better start to think about this.

I'll probably notice this in time.

>>> The time can we configure a system once at installation is long over.
>> I don't recall making any mention of one-time configuration.

> Sure, you did. %e is always "one-time" and relies on hardware that will
> never change to provide predictable names. That's the whole point.

Removing hdc and leaving hdd in place (both being CDROM drives) would still
provide a predictable name for hdd. Predictable naming includes fixed naming,
but is not limited to that.

[snip]
>>> So start to think in the right direction and help solving the real
>>> problems instead.
>> => fix the regression by restoring previous behaviour. That would solve
>> the real problem that I'm seeing.

> No we already have that problem.

... exacerbated.

> And removing unfixable crap, with a proper preparation time _is_ the right
> fix.

I'm now left wondering why my CD symlinks script was removed. Of course, if
two runs of that (during boot) could see two different versions of
/proc/sys/dev/cdrom/info then we would appear to have the same problem...

> As said, keep it running, if you like it.

uptime++ :-)

[snip]
>>> it's about dynamic system configuration. You can't have both at the same
>>> time: hotplug and static configured systems.

>> Well, of course not: a static system would completely preclude the
>> possibility of hotplugging.

>> Now, if you mean "statically configured system"... let's say "statically
>> configured subsystem" instead. This tends to be PCI, IDE and maybe some
>> others or parts of others, and these tend to be fixed. (Yes, I'm aware
>> that there are hot-pluggable implementations...)

> No, that's it. Nothing is "fixed" today. Everything comes and goes all the
> time on modern systems.

That implies continual udev/hotplug activity and lots of system load. :->

> If you don't use it, or unable to imagine it, that's fine, but then start
> to think about it _before_ you write emails to public lists and waste other
> people time.

Sometimes you just want to write something :-)

[snip]
>>> But that has absolutely nothing to do with device probing order, kernel
>>> device names,

>> Er, yes it does. Device naming worked here because of them.

> No, it worked if you were lucky and the system was "static enough". Read
> the udev man page about %e, it is mentioned there for a long time.

(076)

... "The use of enumerations in todays [sic] systems where devices can come
and go at any time is not recommended."

Without this discussion, I would definitely understand that as referring to
USB (that being where devices are likely to come and go, barring failure,
here) and proceed to use %e anyway, regarding the warning as not being
applicable.

As it happens, use of %e occurs in the udev package; I have done nothing
other than installing a newer udev and, some time later, a reboot to cause
use of it locally.

>>> or devfs-like naming schemes.
>> I didn't mention that...

> It's almost the same, %e is a devfs like scheme, [...]

I'd understood "devfs-like" to mean "long name such as disk/ide/disk0/part0".

>> Maybe some symlinks in the static /dev should be used as seeds for
>> udev-managed /dev? That'd provide some or possibly all of the fixed device
>> names, avoid some rule writing, and provide the same naming for those
>> devices in emergency-boot situations (where I tend to use init=/bin/sh and
>> expect /dev/hdaX to be mounted).

> How is that related? That's a distro issue and is a complete different
> topic.

Maybe it's something which several distributions would want and makes sense
to punt upstream; I don't know... ignore it if you like :-)

-- 
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian,     | Northumberland | s zap,tartarus,org
| RISC OS     | Toon Army      | @
|   Kill all extremists!

Convention is the ruler of all.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Marco d'Itri]

On Dec 30, Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:

> Marco, have you done this for 079?
No. I will not waste time adding debconf warnings for this.
If you would like to help then help writing whatever is needed to
generate on demand the rules for static names.

-- 
ciao,
Marco


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Kay Sievers]

On Fri, Dec 30, 2005 at 07:56:52PM +0100, Kay Sievers wrote:
> On Thu, Dec 29, 2005 at 11:46:59PM -0800, Greg KH wrote:

> > Yeah, but we still need a way to enumerate devices in some kind of
> > order, like we do for the cdrom devices today.  So I don't think we can
> > drop it entirely.
> 
> We don't have any "order", that's why we can't do it that way. The
> persistent /dev/disk links are working without any "order", that's the
> model to follow, or writing out "automatic rules" to provide stable names.
> Everything else will just not work.

The problem is we need to "name" devices reliably, without depending on
discovery-order enumeration. %e is also used to enumerate over different
subsystems like hd* and sr*. That probing order can't provide "stable"
names.

On SUSE we never used %e for that reason and the system management creates
rules for optical devices which just match on ID_PATH. That works pretty well
in all currently known setups.

For systems/distros who don't have such a central system management, we
may want some kind of "auto rule creation" for optical devices to provide
stable names.

Something like a script that checks, if a device is already catched
by a persistent rule and if not, it names the device uniquely and at the
same time it drops a rule line to a file in /etc/udev/rules.d/. So the
next time the device shows up, the same name gets assigned. That file
can be edited by the user, if he wants a different name.

That "auto rule setup" could run from udev itself, but may not work in all
cases where /etc is not writable on bootup, or it can be triggered by
running the script manually, once after adding new hardware.

That sounds like the only sane and future proof option to me.

Anybody willing to try this? I shouldn't be hard to implement this as a
shell script. Any code, ideas, comments?

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Darren Salt]

I demand that Marco d'Itri may or may not have written...

> On Dec 30, Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
>> Marco, have you done this for 079?

> No. I will not waste time adding debconf warnings for this.

A paragraph in NEWS.Debian would be adequate, I suspect.

> If you would like to help then help writing whatever is needed to generate
> on demand the rules for static names.

I may have a look. Maybe my cdsymlinks script would be a good starting
point...?

-- 
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)

The Government spins faster than the fastest CD-ROM drive can spin a disc.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Marco d'Itri]

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

On Dec 31, Kay Sievers <kay.sievers@vrfy.org> wrote:

> Anybody willing to try this? I shouldn't be hard to implement this as a
> shell script. Any code, ideas, comments?
I have been thinking about this for a while. 
So far I collected these factoids:

- there is no other component which 
- it would be nice if links to CD/DVD drives were assigned in bus order,
  as it used to happen with %e. How?
- this does not need to be perfect, but it should not create surprises
  for the common cases.
- OSS sound devices are harder, there are a set of different devices
  whose indexes must be kept in sync.
- it should really be a shell script

-- 
ciao,
Marco

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

Re: new version of udev has different cd/dvd devices

[Martin Schwenke]

>>>>> "Kay" = Kay Sievers <kay.sievers@vrfy.org> writes:

    Kay> Something like a script that checks, if a device is already
    Kay> catched by a persistent rule and if not, it names the device
    Kay> uniquely and at the same time it drops a rule line to a file
    Kay> in /etc/udev/rules.d/. So the next time the device shows up,
    Kay> the same name gets assigned. That file can be edited by the
    Kay> user, if he wants a different name.

    Kay> That "auto rule setup" could run from udev itself, but may
    Kay> not work in all cases where /etc is not writable on bootup,
    Kay> or it can be triggered by running the script manually, once
    Kay> after adding new hardware.

    Kay> That sounds like the only sane and future proof option to me.

    Kay> Anybody willing to try this? I shouldn't be hard to implement
    Kay> this as a shell script. Any code, ideas, comments?

* Is locking necessary to generate sequence numbers correctly?  I'm not
  sure about this, since I haven't been following closely enough whether
  udev currently serialises the processing of events, which would
  avoid the need to lock around sequence number generation.

* Name generation can be considered orthogonal to rule generation for
  persistent names.

  That is, name generation can be handled by something like:

    ACTION="add", ..., PROGRAM="/sbin/namegen hd %%N 0", NAME="%c"

  The 1st arg to namegen is the device name prefix.  The 2nd is the
  suffix style "%N" would use the standard letter-based enumeration,
  whereas '%d' would just sequentially number.  The optional 3rd
  argument is the initial sequence number, which would default to 0
  anyway.

  All that is needed is a place to drop the current sequence number
  for each prefix.

  Groups of devices with the same sequence number, such as ALSA
  devices, shouldn't be too much of a problem.  Rules this should do
  the trick:

    ACTION="add", ..., PROGRAM="/sbin/namegen snd/controlC %%d 0", NAME="%c"
    ACTION="add", ..., \
      PROGRAM="/sbin/namegen snd/pcmC %%dD0c 0 snd/controlC", NAME="%c"

  The extra argument to namegen indicates which sequence number to
  use.

  I suspect something cleverer could be done using IMPORT{program} and
  some environment variables.

* Rule generation could be handled using a separate program.  udev
  rules to do the generation might look like:

    ACTION="add", BUS="scsi", ENV{ID_VENDOR}="?*", ENV{ID_MODEL}="?*", \
      ENV{ID_SERIAL}="?*", RUN+="/sbin/rulegen  [...]"

  The biggest trick is knowing when namegen has been called to
  generate a name.  Instead of using PROGRAM=... above, we could use
  IMPORT{program}=... and then check:

    NAME=ENV{NAMEGEN_NAME}

  in the above rule.

Is any of that sane?  :-)

peace & happiness,
martin



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Patrick Mansfield]

On Sat, Dec 31, 2005 at 01:39:02AM +0100, Marco d'Itri wrote:
> On Dec 31, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > Anybody willing to try this? I shouldn't be hard to implement this as a
> > shell script. Any code, ideas, comments?

> I have been thinking about this for a while. 

me too ... mainly for scsi disks.

> So far I collected these factoids:
> 
> - there is no other component which 

?

> - it would be nice if links to CD/DVD drives were assigned in bus order,
>   as it used to happen with %e. How?
> - this does not need to be perfect, but it should not create surprises
>   for the common cases.
> - OSS sound devices are harder, there are a set of different devices
>   whose indexes must be kept in sync.
> - it should really be a shell script

A simple script that generates rules to create /dev's under (perhaps)
/dev/user that are the same as the current kernel name based on a match
with ID_SERIAL (of course handling name collisions and more) would be
useful. Users could then edit the rule file to create "nicer" names.

IMHO, there should eventually be both command line and gui interfaces
(built on top of the same underlying code), as a gui (even curses like
interface) is probably better for displaying the device names and
attributes, and selectively modifying policies if you have many
devices/disks i.e. columns with check boxes for enabling particular
policies and/or names.

Also:

 - allow selection of policies, so for example, you can have by-id,
   by-path, or user-named. So we don't always create by-id, by-path or
   user-named.

The items I stumble on are:

How do you know if an attribute (mainly the id / serial number) for the
device is useful as a persistent attribute? Do you assume all are invalid,
valid, or what?

Should or how do you integrate this into the installer? It is bad to *not*
allow naming or use of by-id at install time, but then later require it to
mount root. Mount by label solves this for many but can't handle a disk
being duplicated/backed up. I guess you can just run the scripts from the
installer.

-- Patrick Mansfield


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Darren Salt]

I demand that Patrick Mansfield may or may not have written...

[snip; tool for setting udev policy]
> Also:

>  - allow selection of policies, so for example, you can have by-id,
>    by-path, or user-named. So we don't always create by-id, by-path or
>    user-named.

I'm happy with whatever's there at boot and at udev startup, after modules
are loaded, gets automatically enumerated (sorting by bus address, generic
rules), with everything else being handled dynamically.

(I'd stick with static /dev but for hotplugging of some types of USB device.)

> The items I stumble on are:

> How do you know if an attribute (mainly the id / serial number) for the
> device is useful as a persistent attribute? Do you assume all are invalid,
> valid, or what?

Not sure. My guess is "assume valid" with a blacklist of known-bad attribute
values, although this could make restoring from backup after replacing or
(possibly) moving some hardware somewhat interesting.

> Should or how do you integrate this into the installer? It is bad to *not*
> allow naming or use of by-id at install time, but then later require it to
> mount root. [...]

Then there's upgrading of existing installations...

-- 
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian,     | Northumberland | s zap,tartarus,org
| RISC OS     | Toon Army      | @
|   We've got Souness, we don't want him

I don't want to grow up. I won't grow up. You can't make me.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Marco d'Itri]

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

On Jan 04, Patrick Mansfield <patmans@us.ibm.com> wrote:

> > - there is no other component which 
> ?
Debian lacks something like /sbin/hwup of SuSE, so I need a lightweight
self-contained solution.

> A simple script that generates rules to create /dev's under (perhaps)
> /dev/user that are the same as the current kernel name based on a match
> with ID_SERIAL (of course handling name collisions and more) would be
> useful. Users could then edit the rule file to create "nicer" names.
We already have stable names in /dev/disk/ and I do not think we need
more. What I need is a solution for the /dev/cdrom* symlinks.

>  - allow selection of policies, so for example, you can have by-id,
>    by-path, or user-named. So we don't always create by-id, by-path or
>    user-named.
Why not?

> How do you know if an attribute (mainly the id / serial number) for the
> device is useful as a persistent attribute? Do you assume all are invalid,
> valid, or what?
You can't, each SUBSYSTEM needs to be special-cased.

> Should or how do you integrate this into the installer? It is bad to *not*
No (at least for Debian), because the installer does not need these
devices and I have to support upgrades and new devices added after the
initial installation.

-- 
ciao,
Marco

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

Re: new version of udev has different cd/dvd devices

[Greg KH]

On Thu, Jan 05, 2006 at 01:27:11PM +0100, Marco d'Itri wrote:
> On Jan 04, Patrick Mansfield <patmans@us.ibm.com> wrote:
> 
> > > - there is no other component which 
> > ?
> Debian lacks something like /sbin/hwup of SuSE, so I need a lightweight
> self-contained solution.

So do other distros :)

> > A simple script that generates rules to create /dev's under (perhaps)
> > /dev/user that are the same as the current kernel name based on a match
> > with ID_SERIAL (of course handling name collisions and more) would be
> > useful. Users could then edit the rule file to create "nicer" names.
> We already have stable names in /dev/disk/ and I do not think we need
> more. What I need is a solution for the /dev/cdrom* symlinks.

Exactly.  The /dev/disk solution is now adopted by all distros that use
udev, so there should not be any problems with this anymore.

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Greg KH]

On Thu, Jan 05, 2006 at 09:34:02AM -0800, Patrick Mansfield wrote:
> On Thu, Jan 05, 2006 at 09:03:17AM -0800, Greg KH wrote:
> 
> > Exactly.  The /dev/disk solution is now adopted by all distros that use
> > udev, so there should not be any problems with this anymore.
> 
> It does work but is unwieldly, dm and iscsi people have complained when
> testing with many disks, I also find it unfriendly.

Then propose an additional, friendly, way of doing things in a new
subdir in /dev/disk to address these issues.  I haven't heard of any
complaints, why don't they make them on the linux-hotplug-devel mailing
list where they might be listened to?  :)

> dm already has its own "workaround" to create fixed short (?) names based
> on id/serial.

Yeah, dm does it's own thing, separate from udev.  But that's dm's
issue, not udev's...

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[patman]

On Thu, Jan 05, 2006 at 09:52:44AM -0800, Greg KH wrote:
> On Thu, Jan 05, 2006 at 09:34:02AM -0800, Patrick Mansfield wrote:
> > On Thu, Jan 05, 2006 at 09:03:17AM -0800, Greg KH wrote:
> > 
> > > Exactly.  The /dev/disk solution is now adopted by all distros that use
> > > udev, so there should not be any problems with this anymore.
> > 
> > It does work but is unwieldly, dm and iscsi people have complained when
> > testing with many disks, I also find it unfriendly.
> 
> Then propose an additional, friendly, way of doing things in a new
> subdir in /dev/disk to address these issues.  I haven't heard of any

That was kind of what I'm doing on this thread. So, use /dev/disk/user
instead of /dev/user.

> complaints, why don't they make them on the linux-hotplug-devel mailing
> list where they might be listened to?  :)

Because you'd flame them back to dm-devel ;-)

> > dm already has its own "workaround" to create fixed short (?) names based
> > on id/serial.
> 
> Yeah, dm does it's own thing, separate from udev.  But that's dm's
> issue, not udev's...

Yes, but they should be using udev. 

Can't you NAK or flame their kernel code? :-(

[hopefully i can send email to the list via this address ...]

-- Patrick Mansfield


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[Greg KH]

On Thu, Jan 05, 2006 at 10:50:56AM -0800, patman@aracnet.com wrote:
> On Thu, Jan 05, 2006 at 09:52:44AM -0800, Greg KH wrote:
> > On Thu, Jan 05, 2006 at 09:34:02AM -0800, Patrick Mansfield wrote:
> > > On Thu, Jan 05, 2006 at 09:03:17AM -0800, Greg KH wrote:
> > > 
> > > > Exactly.  The /dev/disk solution is now adopted by all distros that use
> > > > udev, so there should not be any problems with this anymore.
> > > 
> > > It does work but is unwieldly, dm and iscsi people have complained when
> > > testing with many disks, I also find it unfriendly.
> > 
> > Then propose an additional, friendly, way of doing things in a new
> > subdir in /dev/disk to address these issues.  I haven't heard of any
> 
> That was kind of what I'm doing on this thread. So, use /dev/disk/user
> instead of /dev/user.

"by-user" perhaps?  Ick, I really don't like user specific things :)

> > complaints, why don't they make them on the linux-hotplug-devel mailing
> > list where they might be listened to?  :)
> 
> Because you'd flame them back to dm-devel ;-)

Nah, am I that harsh?

> > > dm already has its own "workaround" to create fixed short (?) names based
> > > on id/serial.
> > 
> > Yeah, dm does it's own thing, separate from udev.  But that's dm's
> > issue, not udev's...
> 
> Yes, but they should be using udev. 

That's for them to decide to use or not.

> Can't you NAK or flame their kernel code? :-(

I try to stay away from dm code if I can help it :)

> [hopefully i can send email to the list via this address ...]

This list accepts email from non-subscribers just fine, only thing it
doesn't like is the normal sf.net spam tests, and html email.

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: new version of udev has different cd/dvd devices

[patman]

On Thu, Jan 05, 2006 at 04:50:25PM -0800, Greg KH wrote:

> > That was kind of what I'm doing on this thread. So, use /dev/disk/user
> > instead of /dev/user.
> 
> "by-user" perhaps?  Ick, I really don't like user specific things :)

Yeh. 

You can also have id/serial numbers for all SCSI devices. The SCSI command
(INQUIRY VPD page 0x83) is not disk specific, I think SLES9 now lists
tapes under /dev/disk/by-id.

> > Because you'd flame them back to dm-devel ;-)
> 
> Nah, am I that harsh?

no ...

> > Yes, but they should be using udev. 
> 
> That's for them to decide to use or not.

Best if all kernel and user code *can* use it in the same way, and set the
same env variables (at least ID_SERIAL).

> > [hopefully i can send email to the list via this address ...]
> 
> This list accepts email from non-subscribers just fine, only thing it
> doesn't like is the normal sf.net spam tests, and html email.

And it also blocks you if your gateway is in spam cop :-(

-- Patrick Mansfield


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel