| View previous topic :: View next topic |
| Author |
Message |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
 Posted: Wed Apr 17, 2013 10:05 pm Post subject: |
 |
|
| gentoo_newguy wrote: | | i have to manual type dhcpcd wlan0 to get an ip hwo can i start this automatically ? |
gentoo_newguy ... thats really a subject for another thread.
best ... khay |
|
| Back to top |
|
 |
oliv3r
n00b
Joined: 06 Jan 2013
Posts: 16
|
| Posted: Thu May 02, 2013 11:50 am Post subject: |
|
|
So now that all the mudslinging is done, I am still left without a workable solution.
Want I want:
Use the new names, I'm fine with them but!
I want to rename known adapters/configurations to something of my choosing, and the rest use the new names. E.g. I plug in a new card, it will be called enp0s1, I replace card 'mynet0', the new card will be renamed to mynet0.
We allready established we can copy/modify /etc/udev/rules.d/80-my-net-name-slot.rules. But this can be broken by etc-update, udev etc etc. So better to use 79-my-net-name-slot.rules as a base, followed up by either /etc or /lib version of 80-my-net-name-slot.rules.
I would assume both tree's are parsed simultaniously and the alphabetical order determins which gets executed first, so /etc/udev/rules.d/79-* goes before /lib/udev/rules.d/80-*.
Now this is what I envisioned my 79-my.rules would look like:
| Code: |
ACTION=="remove", GOTO="net_name_slot_end"
SUBSYSTEM!="net", GOTO="net_name_slot_end"
NAME!="", GOTO="net_name_slot_end"
NAME=="", ENV{ID_NET_NAME_PATH}!="enp5s0f1", NAME="lan1"
NAME=="", ENV{ID_NET_NAME_PATH}!="enp5s0f0", NAME="lan0"
NAME=="", ENV{ID_NET_NAME_PATH}!="enp4s0f1", NAME="vlan0"
NAME=="", ENV{ID_NET_NAME_PATH}!="enp4s0f0", NAME="lan2"
NAME=="", ENV{ID_NET_NAME_PATH}!="enp8s0", NAME="management0"
LABEL="net_name_slot_end"
|
Makes sense right? My quad port adapter gets names lan[012] + vlan0, the onboard NIC gets named 'management0'.
However this compeltly fails. Only half of the interfaces get renamed, the other half gets either a different name, or the enp* name. So unless I have a very obvious typo there, is my reasoning wrong? Could this not work? Should this not work? |
|
| Back to top |
|
|
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
| Posted: Thu May 02, 2013 2:04 pm Post subject: |
|
|
In some kind of sick, twisted irony, I plugged a new NIC into a free PCIe slot on one of my machines so I could have two Ethernet interfaces instead of one. This machine, like all my machines now, was using the new "predictable naming" scheme before and after adding the NIC.
I booted back up and none of my networking worked. Why? Because the PCI bus renumbered everything and what was enp4s0 was now enp5s0 and the new card was enp4s0. So I needed to go back through everything and fix it all. The only thing predictable is that every time I get near this, I curse it. Absolutely predictable.
After all the aggravation switching everything to enpXsY convention and abandoning all hope that the names would imply some sort of order that I could easily remember to get "predictable names" it's all a big sham. This isn't mudslinging it's just the facts. In order to make names reliable and predictable, they need to be mapped to MAC addresses. It was that way before, mapping eth* by MAC, and it is possible now. So nothing changed except a stable, useful and easily understood naming convention has been replaced by someone's unilateral wet dream.
One of the surest ways of putting horrible and confusing bugs in software is to start naming things randomly and with no relationship to what they are. This highlights that axiom. |
|
| Back to top |
|
|
oliv3r
n00b
Joined: 06 Jan 2013
Posts: 16
|
| Posted: Thu May 02, 2013 2:11 pm Post subject: |
|
|
| dbishop wrote: | In some kind of sick, twisted irony, I plugged a new NIC into a free PCIe slot on one of my machines so I could have two Ethernet interfaces instead of one. This machine, like all my machines now, was using the new "predictable naming" scheme before and after adding the NIC.
I booted back up and none of my networking worked. Why? Because the PCI bus renumbered everything and what was enp4s0 was now enp5s0 and the new card was enp4s0. So I needed to go back through everything and fix it all. The only thing predictable is that every time I get near this, I curse it. Absolutely predictable.
After all the aggravation switching everything to enpXsY convention and abandoning all hope that the names would imply some sort of order that I could easily remember to get "predictable names" it's all a big sham. This isn't mudslinging it's just the facts. In order to make names reliable and predictable, they need to be mapped to MAC addresses. It was that way before, mapping eth* by MAC, and it is possible now. So nothing changed except a stable, useful and easily understood naming convention has been replaced by someone's unilateral wet dream.
One of the surest ways of putting horrible and confusing bugs in software is to start naming things randomly and with no relationship to what they are. This highlights that axiom. |
Oh wow, PCI bus renumbering, you should submit that as a bug to udev devs, I really think you should. The fall out should be nice 
Renaming based on MAC is equally unreliable. Swapping out a broken device? Spoofed MAC address? Cheap hardware with duplicate/wrong MAC's. There's a few scenario's (like yours above) that can break things. There simply is no holy grail i'm affraid. I really was hoping that this presistant thing was gonna work ... Guess we all got cheated. |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia
|
| Posted: Thu May 02, 2013 2:17 pm Post subject: |
|
|
The solution is obvious. Pottering needs to introduce a layer of abstraction before udev runs to ensure that the numbering of PCI buses is predictable. Perhaps some sort of userspace rules-based system can be constructed. Absolutely no kernel changes should be allowed, of course, in support of the smooth transition to this new paradigm.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Thu May 02, 2013 2:22 pm Post subject: |
|
|
| oliv3r wrote: |
Renaming based on MAC is equally unreliable. Swapping out a broken device? Spoofed MAC address? Cheap hardware with duplicate/wrong MAC's. There's a few scenario's (like yours above) that can break things. There simply is no holy grail i'm affraid. I really was hoping that this presistant thing was gonna work ... Guess we all got cheated. |
I would not say "equally unreliable", just not perfectly reliable. At least with renaming based on MAC, you know that you're tampering with networking, and it's reasonable to have to do something with your networking configuration. With PCI based names, changing/adding a sound or graphics card can break your network configuration.
It's even worse if you have a USB networking device with the current method.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3266
Location: Canada
|
| Posted: Thu May 02, 2013 3:15 pm Post subject: |
|
|
| depontius wrote: | | oliv3r wrote: |
Renaming based on MAC is equally unreliable. Swapping out a broken device? Spoofed MAC address? Cheap hardware with duplicate/wrong MAC's. There's a few scenario's (like yours above) that can break things. There simply is no holy grail i'm affraid. I really was hoping that this presistant thing was gonna work ... Guess we all got cheated. |
I would not say "equally unreliable", just not perfectly reliable. At least with renaming based on MAC, you know that you're tampering with networking, and it's reasonable to have to do something with your networking configuration. With PCI based names, changing/adding a sound or graphics card can break your network configuration.
It's even worse if you have a USB networking device with the current method. |
I have more conceptual problem with renaming based on MAC. This essenitially means that we say that there is no need for interface name abstraction (besides trivial name aliasing) - just let us use manufactures serial numbers. I can hardly believe that in the long run the OS should present user with hardware serial numbers as
namespace to work with. This is akin designing email client around MAC addresses of the recipient.
The vision behind this idea is that it is envisaged that the user will never see these device names directly, instead will be shielded by the gui network management software. Which in Gentoo world if often not the case. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Thu May 02, 2013 4:38 pm Post subject: |
|
|
| depontius wrote: | | oliv3r wrote: |
Renaming based on MAC is equally unreliable. Swapping out a broken device? Spoofed MAC address? Cheap hardware with duplicate/wrong MAC's. There's a few scenario's (like yours above) that can break things. There simply is no holy grail i'm affraid. I really was hoping that this presistant thing was gonna work ... Guess we all got cheated. |
I would not say "equally unreliable", just not perfectly reliable. At least with renaming based on MAC, you know that you're tampering with networking, and it's reasonable to have to do something with your networking configuration. |
I agree.
MAC addresses aren't 100% perfect, but they suffice for ~99% of users/situations.
Yes, if I replace my ethernet card then I will have to edit a file once but only once for that card.
And if I should put it in a different slot or add other hardware, since the MAC addy is being used it will still know what to do with it.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Thu May 02, 2013 4:39 pm Post subject: |
|
|
| dmpogo wrote: | | The vision behind this idea is that it is envisaged that the user will never see these device names directly, instead will be shielded by the gui network management software. Which in Gentoo world if often not the case. |
Well, if understanding hardware/software and editing a file every now and then is too difficult,
there is always red hat/ubuntu/windows/etc.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3266
Location: Canada
|
| Posted: Thu May 02, 2013 11:39 pm Post subject: |
|
|
| Anon-E-moose wrote: | | depontius wrote: | | oliv3r wrote: |
Renaming based on MAC is equally unreliable. Swapping out a broken device? Spoofed MAC address? Cheap hardware with duplicate/wrong MAC's. There's a few scenario's (like yours above) that can break things. There simply is no holy grail i'm affraid. I really was hoping that this presistant thing was gonna work ... Guess we all got cheated. |
I would not say "equally unreliable", just not perfectly reliable. At least with renaming based on MAC, you know that you're tampering with networking, and it's reasonable to have to do something with your networking configuration. |
I agree.
MAC addresses aren't 100% perfect, but they suffice for ~99% of users/situations.
. |
Everything seems 99%. For 99% eth0 was pefectly fine. In your 1% there are all users who want similar configuration for more than one computer. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Fri May 03, 2013 12:51 am Post subject: |
|
|
| dmpogo wrote: | | Anon-E-moose wrote: | | depontius wrote: | | oliv3r wrote: |
Renaming based on MAC is equally unreliable. Swapping out a broken device? Spoofed MAC address? Cheap hardware with duplicate/wrong MAC's. There's a few scenario's (like yours above) that can break things. There simply is no holy grail i'm affraid. I really was hoping that this presistant thing was gonna work ... Guess we all got cheated. |
I would not say "equally unreliable", just not perfectly reliable. At least with renaming based on MAC, you know that you're tampering with networking, and it's reasonable to have to do something with your networking configuration. |
I agree.
MAC addresses aren't 100% perfect, but they suffice for ~99% of users/situations.
. |
Everything seems 99%. For 99% eth0 was pefectly fine. In your 1% there are all users who want similar configuration for more than one computer. |
Well unfortunately now by default we've taken a few steps backwards, between PCI and USB renaming.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri May 03, 2013 11:58 am Post subject: |
|
|
| oliv3r wrote: |
Renaming based on MAC is equally unreliable. Swapping out a broken device? Spoofed MAC address? Cheap hardware with duplicate/wrong MAC's. There's a few scenario's (like yours above) that can break things. There simply is no holy grail i'm affraid. I really was hoping that this presistant thing was gonna work ... Guess we all got cheated. |
What does spoofing a MAC address have to do with the kernel bringing up a network device? At that level it can't lie about it. So yeah, crappy hardware, which isn't really a concern for people who really need multi-NIC functionality.
The context of a VM is quite interesting: at that level you could use the same set of MAC addresses in the internal virtual device, and then change the MAC in use across the LAN (ie spoof it) if it were really needed: after all, most LANs will just work off the IP address.
That would allow you to use the same configuration across a network of VMs. Assuming a sane implementation of MAC to ifname mapping, which is much simpler than it sounds. Really it's just ifname reservation.
| depontius wrote: | I would not say "equally unreliable", just not perfectly reliable. At least with renaming based on MAC, you know that you're tampering with networking, and it's reasonable to have to do something with your networking configuration. With PCI based names, changing/adding a sound or graphics card can break your network configuration.
It's even worse if you have a USB networking device with the current method. |
Exactly. A giant step backward, much worse than the existing eth* and wlan* defaults which are all 99% of desktop users ever needed anyway.
| dmpogo wrote: | | I have more conceptual problem with renaming based on MAC. This essenitially means that we say that there is no need for interface name abstraction (besides trivial name aliasing) - just let us use manufactures serial numbers. |
No it doesn't. It just says it's much easier (ie more robust in the longer-term, which is why network admins like it) to use the hardware MAC address as the basis for the abstraction: not a bus ID which changes whenever you plug a new device in, or remove one, or one drops out because it's faulty. And this is only when you actually have multiple NIC of the same type and the default ordering is not suitable or changes.
You have a choice between "manufacturer serial number" and "hardware bus ID susceptible to change." I know which one I prefer.
| Quote: | | I can hardly believe that in the long run the OS should present user with hardware serial numbers as namespace to work with. This is akin designing email client around MAC addresses of the recipient. |
It's not though: that's a wilful misunderstanding, imo. How is "hardware bus id" any more a better namespace? It's really not: that's why eth0 and wlan0 were the default.
Further more, the email analogy is a completely false one. The hardware doesn't lie about its factory settings to the kernel driver when being initialised. A "recipient's MAC address" does not even exist in the email protocol. If you're talking about MAC spoofing across a LAN, that's got nothing to with the kernel bringing up the device.
Additionally the OS doesn't present the serial number as the default namespace. It uses a very sane eth0 and wlan0: the point is if you need to tell it which name to use for which card, the only sane way to do so is to specify the card by the hardware MAC which the kernel sees when it initialises the device. Someone wrote before that often manufacturers even label the cards with the MAC. It's much more reliable than partition UUIDs for example.
| Quote: | | The vision behind this idea is that it is envisaged that the user will never see these device names directly, instead will be shielded by the gui network management software. Which in Gentoo world if often not the case. |
That's not really a "vision" at all. It's what lots of other systems have done for quite a while, and it's never really been that useful; you tend to end up needing to deal with the configuration at some point or another. At which point obfuscated names "because we feel like it" are a real PITA.
Especially not when it's so easy just to edit one file and fire-and-forget. The latter is actually much easier to automate, and to wrap a GUI around if desired.
That's the trouble with idiot-box complexity. It always ends up making things more difficult, not less, over the lifecycle of the software.
And we end up having to spend ages making flawed designs work, wasting time on complex workarounds when we don't quite fit the expectations of the newb "developer" who thought up the crap idea in the first place.
If you want to do a GUI, do one. Trust me, it's much easier when you're working with plaintext files and a system that doesn't try to second-guess you.
BTW, thanks for making me laugh, John R. Graham. It was needed. ;-)
_________________
| creaker wrote: | | systemd. It is a really ass pain |
update - "a most excellent portage wrapper"
#friendly-coders -- We're still here for you™ ;) |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Fri May 03, 2013 12:35 pm Post subject: |
|
|
| dbishop wrote: | | I booted back up and none of my networking worked. Why? Because the PCI bus renumbered everything and what was enp4s0 was now enp5s0 and the new card was enp4s0. So I needed to go back through everything and fix it all. The only thing predictable is that every time I get near this, I curse it. Absolutely predictable. |
That has to be just about the best quote so far. The thing, as I have been insisting throughout this debate, is that there is absolutely no case to be made for names of the magic "predictable" form. Never!!
The instructions should make it plain that the "predictable" pattern is possible to get but people with multiple NIC's of the same type (Ethernet, WiFi, etc) should always plan on setting up some kind of udev rules to get names like netX. Telling people that they should go through with setting up files like /etc/init.d/net.enp0s4 is evil! That adds to instability.
What is really sickening about this is that, as it is dawning on me, there would not be a problem with boot-time races if we didn't have udev starting up while the kernel's still starting up. Who dreamed this up? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Fri May 03, 2013 1:03 pm Post subject: |
|
|
| miket wrote: | | there would not be a problem with boot-time races if we didn't have udev starting up while the kernel's still starting up. |
The kernel should always finish up what it's doing with a device
before something else (udev for example) tries to do something with that device
whether it is built into the kernel or a module loading.
This may need a wait loop (or something similar) for things like udev.
And yes, I'm aware that it might make booting slightly slower for some
but the alternative is hard to duplicate race conditions.
And IMO, understanding this isn't rocket science.
I still run udev 171-r6 because it was one of the last that used udev-postmount instead of udev-mount
which means it was starting later (after all local mounts were done).
The real solution is to get rid of udev being separate (whether standalone or part of systemd) and let the kernel populate /dev.
I still keep a real /dev directory that goes back to the 2.4 series of kernels, just in case.
Anyway IMO, there is no easy solution to problems like dbishop's if one is using "predictable naming"
and though MAC addresses have problems (few in the scheme of things) they are more predictable.
But to each their own.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri May 03, 2013 1:06 pm Post subject: |
|
|
| John R. Graham wrote: | | The solution is obvious. Pottering needs to introduce a layer of abstraction before udev runs to ensure that the numbering of PCI buses is predictable. Perhaps some sort of userspace rules-based system can be constructed. Absolutely no kernel changes should be allowed, of course, in support of the smooth transition to this new paradigm. |
John ... have you not heard of 'aggressive parallelization capabilities'? This solution was already committed to the tree, two, three, may be four, weeks, or months, back ... and is currently being back ported and merged with future enhancements. If your hardware doesn't take advantage of these new developments then it is necessary that you break them down into their respective sub-atomic elements and rearrange them until they do ... its *that* simple.
best ... Dr. Reginald Fang PhD. |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia
|
| Posted: Fri May 03, 2013 1:11 pm Post subject: |
|
|
In retrospect, sooo obvious. Thanks. 
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri May 03, 2013 5:15 pm Post subject: |
|
|
| miket wrote: | | if we didn't have udev starting up while the kernel's still starting up. |
When is the kernel started up? When the user has attached the last device which might be 20 hours after starting the machine (and which might very well be an ethernet device or wireless stick)? Things just are not so simple nowadays... |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri May 03, 2013 5:21 pm Post subject: |
|
|
| Anon-E-moose wrote: | The kernel should always finish up what it's doing with a device
before something else (udev for example) tries to do something with that device
whether it is built into the kernel or a module loading. |
I am not a kernel hacker, but AFAIK, this is happening. The problem is that then - while udev is running - the next device might be initialized, and this is what gives the race with udev. This race could only be omitted if the kernel would treat the udev process in a special manner and allow it to postpone certain kernel actions - which AFAIK is what explicitly was not desired by kernel and udev developers because, as I understand it, it is the whole point of udev that it runs in user space with "only" root privileges. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri May 03, 2013 5:42 pm Post subject: |
|
|
| Anon-E-moose wrote: | I still run udev 171-r6 because it was one of the last that used udev-postmount instead of udev-mount
which means it was starting later (after all local mounts were done). |
That's not quite accurate. udev-mount was always around, starting in sysinit, and that's when udev starts. postmount just used to try devices a second time, that had not been initialised at boot because they needed something in /usr. Support for that was deprecated, though I think there is still a use-case for initialisation at a later stage than pre-mount. It is possible to start udev after localmount but you'd know if you were running that; you commented there that you didn't need to start udev late?
Anyhow, even if you're on 171-r6, udev is still starting before localmount: it's just that a second call happens in postmount, which apparently doesn't work in some situations (can't recall what.) If you want it to start later, then you have to use the method above, or perhaps switch to eudev. (I'm not sure if that needs the same adjustment or not, as I don't like switching system software unless I have to. I'd imagine it does, since eudev doesn't change when the udev initscripts start, afaik.)
| Quote: | The real solution is to get rid of udev being separate (whether standalone or part of systemd) and let the kernel populate /dev.
I still keep a real /dev directory that goes back to the 2.4 series of kernels, just in case. |
There are always going to be devices that need setup in userspace. So something like udev, listening on a netlink socket is needed. And at least it doesn't execute external scripts for everything any more ;)
| Quote: | Anyway IMO, there is no easy solution to problems like dbishop's if one is using "predictable naming"
and though MAC addresses have problems (few in the scheme of things) they are more predictable. |
Yup: the new names are functionally useless, and a waste of time and effort as an approach.
| Quote: | | But to each their own. |
Yeah but this isn't a question of how you configure your machine, or what software you use, which are entirely up to you. It's about whether the new approach has any real merit. Given how flaky it is, it clearly does not solve the problem it was meant to, but it does a great job of obfuscating configuration and setting up everyone who uses it, to go through pain. That's just an analytical statement of fact afaic.
edit: typo.
Last edited by steveL on Fri May 03, 2013 5:51 pm; edited 1 time in total |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri May 03, 2013 5:48 pm Post subject: |
|
|
| mv wrote: | | The problem is that then - while udev is running - the next device might be initialized, and this is what gives the race with udev. |
All device events are already queued up over a netlink socket in order to send them out of the kernel. If udev is reading that stream then jumbling the order up, that's a clear defect in udev. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri May 03, 2013 5:50 pm Post subject: |
|
|
| mv wrote: | | The problem is that then - while udev is running - the next device might be initialized, and this is what gives the race with udev. |
Yes, though the issue is that udev is trying to rename to a device-name that the kernel either initialises next, or has already initialised. Hence "race" since it's a question of who grabs the name first (or more precisely whether the udev name change is accepted by the kernel before it allocates it to another device.)
| Quote: | | This race could only be omitted if the kernel would treat the udev process in a special manner and allow it to postpone certain kernel actions |
No, it could also be avoided if the kernel reserved ifnames for MAC addresses, as discussed previously; which is much less kludgy.
| Quote: | | which AFAIK is what explicitly was not desired by kernel and udev developers because, as I understand it, it is the whole point of udev that it runs in user space with "only" root privileges. |
Not an issue with the approach discussed before. Not that many of us really need the facility. Certainly not the desktop users udev was initially aimed at. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Fri May 03, 2013 6:45 pm Post subject: |
|
|
| mv wrote: | | Anon-E-moose wrote: | The kernel should always finish up what it's doing with a device
before something else (udev for example) tries to do something with that device
whether it is built into the kernel or a module loading. |
I am not a kernel hacker, but AFAIK, this is happening. The problem is that then - while udev is running - the next device might be initialized, and this is what gives the race with udev. |
I bolded what I originally said.
If udev waited for the kernel to be done with a device there would be NO race condition it would be impossible.
| Quote: | | This race could only be omitted if the kernel would treat the udev process in a special manner |
Udev is the problem not the solution. It has already caused enough problems even needing DEVTMPFS added to the kernel for its uses.
It used to work perfectly well (for most users), until the development of it started being driven by systemd instead of the kernel.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Fri May 03, 2013 7:35 pm Post subject: |
|
|
| steveL wrote: | | Anon-E-moose wrote: | I still run udev 171-r6 because it was one of the last that used udev-postmount instead of udev-mount
which means it was starting later (after all local mounts were done). |
That's not quite accurate. udev-mount was always around, starting in sysinit, and that's when udev starts. postmount just used to try devices a second time, that had not been initialised at boot because they needed something in /usr. Support for that was deprecated, though I think there is still a use-case for initialisation at a later stage than pre-mount. It is possible to start udev after localmount but you'd know if you were running that; you commented there that you didn't need to start udev late?
Anyhow, even if you're on 171-r6, udev is still starting before localmount: it's just that a second call happens in postmount, which apparently doesn't work in some situations (can't recall what.) |
You're right about the order, it's been so long since I looked at things that I forgot. 
I explicitly start udev-postmount but not the other two. Udev used to keep track of what devices failed initialization
and then retry them later, maybe it was in postmount, but I think that's one of the "features" that they are trying to do away with.
I don't keep up much with where they are going as I refuse to update.
Anyway, I digress 
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3266
Location: Canada
|
| Posted: Fri May 03, 2013 9:14 pm Post subject: |
|
|
| steveL wrote: |
| dmpogo wrote: | | I have more conceptual problem with renaming based on MAC. This essenitially means that we say that there is no need for interface name abstraction (besides trivial name aliasing) - just let us use manufactures serial numbers. |
No it doesn't. It just says it's much easier (ie more robust in the longer-term, which is why network admins like it) to use the hardware MAC address as the basis for the abstraction: not a bus ID which changes whenever you plug a new device in, or remove one, or one drops out because it's faulty. And this is only when you actually have multiple NIC of the same type and the default ordering is not suitable or changes.
You have a choice between "manufacturer serial number" and "hardware bus ID susceptible to change." I know which one I prefer.
| Quote: | | I can hardly believe that in the long run the OS should present user with hardware serial numbers as namespace to work with. This is akin designing email client around MAC addresses of the recipient. |
It's not though: that's a wilful misunderstanding, imo. How is "hardware bus id" any more a better namespace? It's really not: that's why eth0 and wlan0 were the default.
|
I prefer standard names that do not reflect any hardware pecularities. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri May 03, 2013 9:58 pm Post subject: |
|
|
| steveL wrote: | it's much easier (ie more robust in the longer-term, which is why network admins like it) to use the hardware MAC address as the basis for the abstraction: not a bus ID which changes whenever you plug a new device in, or remove one, or one drops out because it's faulty. And this is only when you actually have multiple NIC of the same type and the default ordering is not suitable or changes.
You have a choice between "manufacturer serial number" and "hardware bus ID susceptible to change." I know which one I prefer.
| dmpogo wrote: | | I can hardly believe that in the long run the OS should present user with hardware serial numbers as namespace to work with. This is akin designing email client around MAC addresses of the recipient. |
It's not though: that's a wilful misunderstanding, imo. How is "hardware bus id" any more a better namespace? It's really not: that's why eth0 and wlan0 were the default. |
| dmpogo wrote: | | I prefer standard names that do not reflect any hardware pecularities. |
Yes, so you agree then: eth* and wlan* by default, rename it to what you want from there, iff that's needed. Which for most desktop users it certainly is not.
Thing is, you're selectively quoting me and raising "conceptual" points that have little to do with the discussion at hand; the only thing you've actually said is that MAC addresses (which were designed to be human-friendly in format, just like IP-4 addresses, for exactly this purpose) are somehow inferior, with no reasoning beyond that which makes the new namespace just as bad "conceptually" only it's not reliable nor predictable, as others have clearly demonstrated.
Tell me, do you actually administer any multiple-NIC machines?
(I don't, for the record; I just listen carefully to people who do, some of whom I work with.) |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
