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: overriding udev rules
On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl wrote: > Am 09.09.2013 20:50, schrieb Lennart Poettering: >> It's now a Debianism to stick to the persistant names, all support for >> it has been removed upstream. From upstream we hope DEbian eventually >> drops support for the old persistant names too. > > We (Debian pkg-systemd team) decided to keep the old persistent naming > scheme "as default" for now, for the simple reason, that we didn't want > to break upgrades. It just didn't seem possible to detect every case > where the old ethX names were used and losing network connection as part > of the upgrade is a big no-go. > As documented in the debian changelog, you can opt-in to use the new > naming scheme, but this requires explicit configuration from the > administrator. > We might make the new network interface naming the default for new > installations, but this isn't something we haven't been working on yet. Hmm, why would upgrades break? The old file would still be there, rename the devices (if you keep the patch to swap names, which upstream does not support any more), and take precedence over tht new names; the old rules file would just not be updated anymore when new devices appear. Kay -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capxgp13syupgweorgm6xmvrvqrqpzafdbf3bxp1sb-abstj...@mail.gmail.com
Re: overriding udev rules
On Mon, Sep 9, 2013 at 11:26 PM, Ben Hutchings wrote: > On Mon, Sep 09, 2013 at 08:50:48PM +0200, Lennart Poettering wrote: > [...] >> As a side note, also note that the MAC address range definitions are all >> blurred these days, MAC addresses are reused by manufacturers and most >> parsable meaning of MAC addresses has been removed (simply because the >> namespace is mostly depleted these days...) > > There is no shortage of namespace; only a tiny fraction of the 2^22 > valid OUIs have been allocated. But perhaps some OUIs are abused for > volatile and non-unique assignments and you're right that this breaks > the old naming policy. > > The new udev policy isn't any better for Thomas's use case, though. > He seems to want to take his chances with kernel probing order... It's hopefully still better for most virtual machine use cases, as it will not write out config to disk at every boot and not use MAC addresses, which can change from boot-to-boot on some boxes. With the old model we've seen virtual machines with 1000s of entries in the rules files created by just rebooting them. :) Kay -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capxgp11wppj6kenbbiudywppyae_tk2x-hn2hcjto19apt7...@mail.gmail.com
Re: overriding udev rules
On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl wrote: > Am 09.09.2013 23:53, schrieb Kay Sievers: >> Hmm, why would upgrades break? > > See [1], there are several cases where 75-persistent-net-generator.rules > doesn't generate a persistent name (mostly VM related). In those cases, > you would typically use eth0 in your /etc/network/interface etc. > On upgrades, the new networking naming would kick in, and suddenly it's > no longer eth0. The new names should only get active where the old rules also matched, it currently supports PCI parent devices only, most VM use cases, xen, virt drivers would be excluded anyway. But sure, there can be setups where that could happen, I would just expect that the number is very very low. Kay -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capxgp11nncysl1xrwm+z2ux5aukomkpodxothqro8dps1qi...@mail.gmail.com
