Re: udev event completion order
On Mon, Jan 02, 2006 at 08:19:30PM +0100, Adrian von Bidder wrote: > 'just plug' is the watchword. New device model just needs a reboot - in > some circumstances device numbering is random without hardware changes and > without software changes. So it exposes a bug more frequently than before. So why not fix the bug instead of trying to paper over it forever? As a user, a disk changing its name if I plug it to a different SATA connector that happens to be connected to a different chip on the MB is _exactly_ the same problem as the name change on a single reboot. Any solution must work equally well for the "plugged in at a different location" case or it is useless. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: udev event completion order
On Monday 02 January 2006 14.48, Gabor Gombas wrote: > On Wed, Dec 21, 2005 at 07:29:16PM +, Darren Salt wrote: > > I'd call that broken, just as I consider udev (076) to be broken given > > that it breaks expectations wrt device naming. (Here, it swapped the > > names of the DVD drives (drivers are built-in) and sound devices > > (drivers are modular).) > > But that was the case since ages for SCSI (and nowadays SATA) devices. > No modules, no udev, just plug a new SATA/SCSI disk to the controller ... 'just plug' is the watchword. New device model just needs a reboot - in some circumstances device numbering is random without hardware changes and without software changes. -- vbi -- Beware of the FUD - know your enemies. This week * The Alexis de Toqueville Institue * http://fortytwo.ch/opinion/adti pgp7j5JxFO0KA.pgp Description: PGP signature
Re: udev event completion order
On Wed, Dec 21, 2005 at 07:29:16PM +, Darren Salt wrote:
> I'd call that broken, just as I consider udev (076) to be broken given that
> it breaks expectations wrt device naming. (Here, it swapped the names of the
> DVD drives (drivers are built-in) and sound devices (drivers are modular).)
But that was the case since ages for SCSI (and nowadays SATA) devices.
No modules, no udev, just plug a new SATA/SCSI disk to the controller
that happens to be detected first and all disks on the other controller
gets renamed. udev at least provides persistent naming using
/dev/disk/by-{id,label,path,uuid}.
This is also true for any add-on cards: just plug them to different PCI
slots and the attached devices get renamed. This is not a new problem at
all, it is just exposed more frequently as device handling becomes more
and more dynamic. Again, udev now provides an interface to manually
override these name changes if you want to.
Btw. looking at /usr/src/linux/init/do_mounts.c, the name parsing is
already sysfs-based so it would not be too hard to implement support for
something like
"root=/sys/devices/pci:00/:00:1e.0/:02:0b.2/usb5/5-2/5-2.4/5-2.4:1.0/host0/target0:0:0/0:0:0:0"
So if you worry that the "root=/dev/sda1" style is not
reliable (well, it never was), then talk to the kernel guys.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order
On Thu, 22 Dec 2005 06:29, Darren Salt wrote: > I demand that Alexander E. Patrakov may or may not have written... > > > Kay Sievers wrote: > >> There is also the plan to do parallel device probing inside the kernel > >> some day, that will make the situation of relying on kernel names even > >> more fragile. > > > > Right, this means that the way of passing "root=/dev/hdc2" will no > > longer work because /dev/hdc will sometimes become /dev/hde. > That will also break scripts/apps that manipulate disks/partitions. This could easily result in some-one restoring a backup over the wrong disk. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order
I demand that Alexander E. Patrakov may or may not have written... > Kay Sievers wrote: >> There is also the plan to do parallel device probing inside the kernel >> some day, that will make the situation of relying on kernel names even >> more fragile. > Right, this means that the way of passing "root=/dev/hdc2" will no longer > work because /dev/hdc will sometimes become /dev/hde. I'd call that broken, just as I consider udev (076) to be broken given that it breaks expectations wrt device naming. (Here, it swapped the names of the DVD drives (drivers are built-in) and sound devices (drivers are modular).) If the parallel probing is done such that the naming remains predicatable, that's good. Whether it's faster doesn't matter - userspace isn't affected and doesn't require modification, and that's a good thing. > If you are serious about going to implement this, first add (to > linux-2.6.16?) a boot-time warning if the kernel is booting without > initramfs. The warning should say something like this: > WARNING: you have booted the kernel without initramfs and passed an > explicit root device name. I see no problem with booting like that. I've always used the root device name; why should I forced to change should a kernel upgrade become necessary just because of some should-be-in-2.7.x [1] breakage? > This will no longer work when the kernel will probe devices in parallel > (i.e., since linux-2.6.??) because device ordering will be random. Please > create an initramfs that mounts the root device using some stable > attribute, like label or UUID. That'd be "stable and duplicatable", and I fully expect somebody to run into that sooner or later... [1] Heated discussion, anybody? ;-) -- | Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk | Debian, | Northumberland | s zap,tartarus,org | RISC OS | Toon Army | @ | Kill all extremists! I've got 256K of RAM, so why can't I run Windows 3.1? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order
Kay Sievers wrote: There is also the plan to do parallel device probing inside the kernel some day, that will make the situation of relying on kernel names even more fragile. Right, this means that the way of passing "root=/dev/hdc2" will no longer work because /dev/hdc will sometimes become /dev/hde. If you are serious about going to implement this, first add (to linux-2.6.16?) a boot-time warning if the kernel is booting without initramfs. The warning should say something like this: WARNING: you have booted the kernel without initramfs and passed an explicit root device name. This will no longer work when the kernel will probe devices in parallel (i.e., since linux-2.6.??) because device ordering will be random. Please create an initramfs that mounts the root device using some stable attribute, like label or UUID. -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order (was: Re: Debian Installer team monthly meeting minutes (20051214 meeting))
On Sun, Dec 18, 2005 at 09:52:42AM +0100, Marco d'Itri wrote: > On Dec 18, Darren Salt <[EMAIL PROTECTED]> wrote: > > > An alternative appears to be to process events in series... or maybe > > delaying > This was the precedent approach, and it's much slower (also, it cannot > be implemented anymore with just udevd). Right, you could request event-by-event from the kernel and wait for it to finish for devices that you know to have initialized first, but that sounds like a bad idea. The whole "device enumeration by module load order"-thing never worked too reliably and will never work again. Everybody just needs to get used to the fact that while you can add and remove devices at any point in time from a running system, it can never give predictable simple enumerations, like the kernel names are. We implemented persistent device links for disks, which is on almost all distros today and SUSE has persistent network device names implemented by automatically writing udev rules from the device event. Persistent naming is the way to go and to work on improving and extending the current system. The /dev/disk/* link model should work for other subsystems in a similar way, it's just that somebody needs to do it. :) There is also the plan to do parallel device probing inside the kernel some day, that will make the situation of relying on kernel names even more fragile. I will remove the %e from the udev rules some day too, cause it never worked correctly outside of udevstart and udevstart is also no longer recommended to use cause you can't match on event properties which are only available from the event itself but not in sysfs. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order (was: Re: Debian Installer team monthly meeting minutes (20051214 meeting))
On Dec 18, Darren Salt <[EMAIL PROTECTED]> wrote: > An alternative appears to be to process events in series... or maybe delaying This was the precedent approach, and it's much slower (also, it cannot be implemented anymore with just udevd). -- ciao, Marco signature.asc Description: Digital signature
udev event completion order (was: Re: Debian Installer team monthly meeting minutes (20051214 meeting))
[CC'ing hotplug-devel] I demand that Marco d'Itri may or may not have written... > On Dec 17, Christian Perrier <[EMAIL PROTECTED]> wrote: >> It is currently very likely that systems with two network interfaces will >> end up with both switched on the installed system after the reboot. This >> is of course a blocker. >> The discussion showed that sticking with discover while udev is used may >> be the main reason for this. > No. This will happen no matter how the system was installed, because > modules are loaded concurrently and the first one to finish its setup wins. > This applies to the /dev/cdrom and similar links on systems with multiple > CD readers too. FWIW, I've seen this with both CD/DVD drives and both sound devices in one of my machines. I have no doubt that the same applies to DVB cards etc., which might cause problems when one's DVB-T and another's DVB-S or something. > The solution so far appears to be writing a rules file which will > statically assign the names. An alternative appears to be to process events in series... or maybe delaying naming until all modules have been loaded could help? I think that ordering by bus address or kernel device name could help here. Of course, adding some modules may trigger another round of events, causing more modules to be loaded, but this shouldn't be a problem - it should be just another batch of events to be buffered and processed after the current batch is complete. [snip] -- | Darren Salt | nr. Ashington, | linux (or ds) at | sarge,| Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | We've got Souness, we don't want him Buy! Amdahl Stock to go up 100 points next week. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
