Re: [gentoo-user] Re: udev (viable) alternatives ?
On Thu, Nov 13, 2014 at 12:08 PM, Walter Dnes waltd...@waltdnes.org wrote: On Tue, Nov 11, 2014 at 07:18:30AM -0500, Rich Freeman wrote Can you find one example of any situation where the linux kernel has ever required any specific implementation of anything in userspace as a matter of policy in its 23 year history? I'm sure you could find some examples of cases where there just happened to be one de-facto implementation of something, but even that might be tough with all the diversity in the linux world. It might not be an official official requirement, but if the upstream gets rolled into systemd, then we depend on the goodwill of systemd devs not to go and break anybody else's userspace implementation. Lennart and goodwill do not belong in the same sentence. How's systemd-shim working out for Debian? Do you have any reason to think that it isn't working out? The systemd-shim and cgmanager developers have to play catch up but I'm using both on Debian and Ubuntu and they're OK.
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Tue, Nov 11, 2014 at 07:18:30AM -0500, Rich Freeman wrote On Tue, Nov 11, 2014 at 12:20 AM, Walter Dnes waltd...@waltdnes.org wrote: What worries me is that Lennart has been able to get modifications done to the kernel, e.g. kdbus. I know this'll sound paranoid, but how long before he pushes a patch that requires systemd to run the linux kernel? Apologies if this comes across a bit agro, but: 1. kdbus isn't in the kernel (though that seems likely to happen at some point) 2. it does sound paranoid 3. if he pushes a patch that requires systemd I'd be shocked if Linus merged it Can you find one example of any situation where the linux kernel has ever required any specific implementation of anything in userspace as a matter of policy in its 23 year history? I'm sure you could find some examples of cases where there just happened to be one de-facto implementation of something, but even that might be tough with all the diversity in the linux world. It might not be an official official requirement, but if the upstream gets rolled into systemd, then we depend on the goodwill of systemd devs not to go and break anybody else's userspace implementation. Lennart and goodwill do not belong in the same sentence. How's systemd-shim working out for Debian??? I'm old enough to remember the OS/2-versus-Windows wars. At one point, IBM had Windows 3.1 running inside of OS/2. Then Microsoft issued a minor update (Windows 3.11) and it no longer ran inside OS/2. It took a while for IBM to get Windows 3.11 running inside OS/2. That's the kind of hostility that non-Lennart userspace software faces. Linus himself has articulated some of the reasons why kdbus is likely to get merged. It fills in a gap in Linux as compared to many competing operating systems, and it is logical to implement at the kernel level. That is generally the criteria for getting stuff into the kernel, and is basically good software design. The linux kernel is all about stable userspace ABIs - if there is only one implementation of something it is probably because nobody was bothered enough to write another. We Gentoo folks got our wakeup call ( literally http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html ) from the guy who signs himself as Lennart Poettering, Red Hat (nuff said). I don't know how long udev will run standalone without systemd. My desktop PC is running mdev. See https://wiki.gentoo.org/wiki/Mdev and https://wiki.gentoo.org/wiki/Mdev/Automount_USB eudev is also an option. Hopefully, device management doesn't get forced into systemd. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Tue, Nov 11, 2014 at 12:20 AM, Walter Dnes waltd...@waltdnes.org wrote: On Mon, Nov 10, 2014 at 05:48:49PM +0200, Samuli Suominen wrote I wouldn't worry about it at all, there is no way *sys-fs/udev ebuild* will ever need systemd. There might be a news item later, with instructions on moving to something else, but that's not something we are even planning at the moment, so sys-fs/udev is still the de facto proper upstream /dev manager. What worries me is that Lennart has been able to get modifications done to the kernel, e.g. kdbus. I know this'll sound paranoid, but how long before he pushes a patch that requires systemd to run the linux kernel? Apologies if this comes across a bit agro, but: 1. kdbus isn't in the kernel (though that seems likely to happen at some point) 2. it does sound paranoid 3. if he pushes a patch that requires systemd I'd be shocked if Linus merged it Can you find one example of any situation where the linux kernel has ever required any specific implementation of anything in userspace as a matter of policy in its 23 year history? I'm sure you could find some examples of cases where there just happened to be one de-facto implementation of something, but even that might be tough with all the diversity in the linux world. Linus himself has articulated some of the reasons why kdbus is likely to get merged. It fills in a gap in Linux as compared to many competing operating systems, and it is logical to implement at the kernel level. That is generally the criteria for getting stuff into the kernel, and is basically good software design. The linux kernel is all about stable userspace ABIs - if there is only one implementation of something it is probably because nobody was bothered enough to write another. -- Rich
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 9/26/2014 1:04 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 25/09/14 22:03, James wrote: I'd be better of with a fresh install of lilblue + musl + eudev is what you are really saying here? that's the only usecase for eudev currently, yes, otherwise you have no reason to switch Hi Samuli, So, is the above still true? eudev is looking more attractive every day... but can it continue to work and be supported if Lennart gets his way and upstream udev stops working without systemd? Just saw reference to the following thread on the debian-user list, and it includes a couple of responses from you (and an insult hurled at you from Lennart)... and I'm a bit worried that gentoo will be forced to swallow the systemd koolaid sometime maybe even sooner rather than later if Lennart succeeds in making udev work only with systemd, as he makes clear his desire to do just that here: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html Notably: Lennart said: Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. Samuli replied: I've already set minimum kernel required to 2.6.39 in = 213, and I'd be fine setting it even higher. Talking only of the udev bit here. I don't like dropping support for old versions, but if that's what has to be done, I'll go with that. Please, don't use this as an excuse to drop support for MinimalBuilds as described in wiki in some manner. As in, if it's still possible to use some kernel, like kernel with kdbus, and even if it requires an userspace library like 'libsystemd-something' to go with it, and still get a udev one way or another, that can run standalone, we are all good. Lennart responded: You need the userspace code to set up the bus and its policy and handle activation. That's not a trivial task. For us, that's what sytemd does in PID 1. You'd need to come up with an alternative for that. Samuli said: I'd really hate to be forced to fork (or carry huge patchset) unnecessarily (I'm not a systemd hater, I'm not a eudev lover, I'm simply working on what is provided to me by *you*, udev upstream) Lennart replied: Oh god. You know, if you come me like this as blame me that I would force you to do something, then you just piss me off and make me ignore you. Anyway, as soon as kdbus is merged this i how we will maintain udev, you have ample time to figure out some solution that works for you, but we will not support the udev-on-netlink case anymore. I see three options: a) fork things, b) live with systemd, c) if hate systemd that much, but love udev so much, then implement an alternative userspace for kdbus to do initialiuzation/policy/activation. Also note that this will not be a change that is just internal between udev and libudev. We expect that clients will soonishly just start doing normal bus calls to the new udev, like they'd do them to any other system service instead of using libudev.
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Mon, Nov 10, 2014 at 6:04 AM, Tanstaafl tansta...@libertytrek.org wrote: eudev is looking more attractive every day... but can it continue to work and be supported if Lennart gets his way and upstream udev stops working without systemd? Well, there are no plans to make udev stop working without systemd as far as I can tell. HOWEVER, there ARE plans to require using kdbus to communicate with udev, and for that to work there needs to be a userspace initialization of kdbus/etc. Udev is probably just be the tip of the iceberg. Lots of packages use dbus, and it seems likely to me that many will start switching to kdbus. The fact that it is going to be a standard kernel IPC mechanism also means that packages that have avoided dbus in the interests of not having large dependencies may start picking it up as well - it might be used even on embedded systems. I have no idea how much work is involved or if anybody else is interested in doing it. If busybox is willing to have their mdev module, I don't see why they wouldn't want a kdbus module to go along with that. However, that is speaking mostly out of ignorance, and somebody needs to write the code. I don't think avoiding kdbus is going to be a viable long-term solution. Folks who don't want to run systemd need to start planning for this, and cross needs dbus off their list of reasons not to use systemd. -- Rich
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 11/10/2014 7:30 AM, Rich Freeman ri...@gentoo.org wrote: Well, there are no plans to make udev stop working without systemd as far as I can tell. HOWEVER, there ARE plans to require using kdbus to communicate with udev, and for that to work there needs to be a userspace initialization of kdbus/etc. So... you're saying I'm mis-reading this: Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. and that it doesn't mean that udev will stop working without systemd, or, as Lennart said, ... we will not support non-systemd systems with udev anymore staryting at that point (when udev is moved onto kdbus as transport)? Or... maybe eudev (or mdev, or both) could or would have to be [re]written so as to be fulfill the 'kdbus userspace' role Lennart mentions above? Being 'not a dev' (or programmer at all), I guess it is entirely possible it isn't as bad as it sounds, but his Gentoo folks, this is your wake-up call. comment is what really stands out to me, as a gentoo user. I don't care about dbus/kdbus - if it is in the kernel, and under Linus' control, and I need to enable it to use my systems, that is fine with me. What I want is to always have the option - a *stable* option - to not have to install/use systemd if I don't want to.
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Mon, Nov 10, 2014 at 8:23 AM, Tanstaafl tansta...@libertytrek.org wrote: On 11/10/2014 7:30 AM, Rich Freeman ri...@gentoo.org wrote: Well, there are no plans to make udev stop working without systemd as far as I can tell. HOWEVER, there ARE plans to require using kdbus to communicate with udev, and for that to work there needs to be a userspace initialization of kdbus/etc. So... you're saying I'm mis-reading this: Somewhat. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. and that it doesn't mean that udev will stop working without systemd, or, as Lennart said, ... we will not support non-systemd systems with udev anymore staryting at that point (when udev is moved onto kdbus as transport)? The part that you're missing is the Unless the systemd-haters [sic] prepare another kdbus userspace. Like many parts of the kernel, kdbus needs initialization from userspace. This is no different than what udev does in the first place - the kernel has device drivers, but SOMETHING has to populate /dev with device nodes if you want to use them. Now /dev has been around since the dawn of time, so we get our choice of 47 different ways of doing that. Kdbus hasn't been around for long at all, so nobody has really written any standalone processes for initializing it. As far as I can tell, udev will work just fine as long as something sets up kdbus. I'd have to study it a bit more to understand if there is some reason that this something has to be PID 1. I don't care for the attitude/etc and especially the treatment of Samuli (who seems to do his best to cooperate with everybody in this contentious area), but stepping back I can't really say that a project deciding to move to a new API based on a new IPC feature is all that controversial on its own. Normally when this sort of thing happens there are a bunch of projects built to support such a new kernel feature in userspace. I think the main reasons that we are where we are right now are: 1. All the big distros are moving to systemd anyway, so they don't really have much of an itch to scratch here. 2. Most folks not interested in systemd seem to generally not be interested in dbus at all. I think there is a lot of hope that this problem will just go away, and I suspect that if anything it will get a lot worse. 3. Those who aren't using systemd to some extent are a bit split across udev, eudev, and busybox mdev. This does divide up the labor pool a bit and means interests aren't 100% aligned. The situation doesn't really see irreparable to me, but it does seem like there is something to be done. -- Rich
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 10/11/14 13:04, Tanstaafl wrote: On 9/26/2014 1:04 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 25/09/14 22:03, James wrote: I'd be better of with a fresh install of lilblue + musl + eudev is what you are really saying here? that's the only usecase for eudev currently, yes, otherwise you have no reason to switch Hi Samuli, So, is the above still true? Yes, it's still true, there is no reason to change away from sys-fs/udev except for sys-libs/musl use, and even then, I'd be happy to accept musl compability patches for sys-fs/udev's ebuild, but the sys-libs/musl maintainer decided to put his work to sys-fs/eudev instead. So unless some user does the work for him... I wouldn't worry about it at all, there is no way *sys-fs/udev ebuild* will ever need systemd. There might be a news item later, with instructions on moving to something else, but that's not something we are even planning at the moment, so sys-fs/udev is still the de facto proper upstream /dev manager.
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 11/10/2014 10:48 AM, Samuli Suominen ssuomi...@gentoo.org wrote: I wouldn't worry about it at all, there is no way *sys-fs/udev ebuild* will ever need systemd. There might be a news item later, with instructions on moving to something else, but that's not something we are even planning at the moment, so sys-fs/udev is still the de facto proper upstream /dev manager. Well, that sounds reassuring, so thanks very much for this and you're hard work for all of us non-programmer gentoo users, it is much appreciated! I guess Lennart was just using words that I read the wrong way... even now if I re-read his posts, it sounds to me like he is saying 'no more separate udev without systemd ultimately'... and I know for sure he has made exactly this comments in the past, but that was admittedly 1 year or two ago...
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Mon, Nov 10, 2014 at 05:48:49PM +0200, Samuli Suominen wrote I wouldn't worry about it at all, there is no way *sys-fs/udev ebuild* will ever need systemd. There might be a news item later, with instructions on moving to something else, but that's not something we are even planning at the moment, so sys-fs/udev is still the de facto proper upstream /dev manager. What worries me is that Lennart has been able to get modifications done to the kernel, e.g. kdbus. I know this'll sound paranoid, but how long before he pushes a patch that requires systemd to run the linux kernel? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 11/11/14 07:20, Walter Dnes wrote: On Mon, Nov 10, 2014 at 05:48:49PM +0200, Samuli Suominen wrote I wouldn't worry about it at all, there is no way *sys-fs/udev ebuild* will ever need systemd. There might be a news item later, with instructions on moving to something else, but that's not something we are even planning at the moment, so sys-fs/udev is still the de facto proper upstream /dev manager. What worries me is that Lennart has been able to get modifications done to the kernel, e.g. kdbus. I know this'll sound paranoid, but how long before he pushes a patch that requires systemd to run the linux kernel? I expect systemd-udevd to be migrated into kdbus, which means libudev, libgudev-1.0 and the systemd-udevd binary itself will likely need the libsystemd-bus library, which we will then package and ship together with sys-fs/udev Or if systemd-udevd binary starts requiring a running service of some of the systemd services, then we will make those available as well and run the from the udev-init-scripts, or possibly even adjust sys-apps/openrc to compensate for the inadequaties Just trying to say, that even with kdbus pending, I'm not worried at all - Samuli
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Mon, Nov 10, 2014 at 11:20 PM, Walter Dnes waltd...@waltdnes.org wrote: On Mon, Nov 10, 2014 at 05:48:49PM +0200, Samuli Suominen wrote I wouldn't worry about it at all, there is no way *sys-fs/udev ebuild* will ever need systemd. There might be a news item later, with instructions on moving to something else, but that's not something we are even planning at the moment, so sys-fs/udev is still the de facto proper upstream /dev manager. What worries me is that Lennart has been able to get modifications done to the kernel, e.g. kdbus. I know this'll sound paranoid, but how long before he pushes a patch that requires systemd to run the linux kernel? Then you can take the very last commit to Linus' Git repository before that hypothetical change, and fork the Linux kernel into whatever direction your crazy heart desires. Business as usual in the Free Software world. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: I buy machines with one ethernet interface. What I find particularly annoying is this doublespeak about calling it predictable. Before the change, it was predicatbly eth0. Now, it's different on every different model. It's not doublespeak, the interfaces are named exactly according to where they are on the PCI bus. If you had two interfaces, they show up to the kernel in random order by time and sometimes eth0/eth1 are nto the same they were before the reboot. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. -- Neil Bothwick The gene pool could use a little chlorine. signature.asc Description: PGP signature
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: I buy machines with one ethernet interface. What I find particularly annoying is this doublespeak about calling it predictable. Before the change, it was predicatbly eth0. Now, it's different on every different model. It's not doublespeak, the interfaces are named exactly according to where they are on the PCI bus. If you had two interfaces, they show up to the kernel in random order by time and sometimes eth0/eth1 are nto the same they were before the reboot. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51 -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Fri, 26 Sep 2014 03:22:16 -0500, Canek Peláez Valdés wrote: That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. It certainly was the case. I couldn't test it directly because this laptop doesn't have support for such devices, but plugging, unplugging and replugging a USB ethernet adaptor resulted in a change of device number. I just switched to a different machine and it does indeed give the same name now, so things have been fixed and the interface names are now predictable. Ugly as hell, hard to remember, but they are predictable. -- Neil Bothwick Make it idiot proof and someone will make a better idiot. signature.asc Description: PGP signature
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/14 11:22, Canek Peláez Valdés wrote: On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: I buy machines with one ethernet interface. What I find particularly annoying is this doublespeak about calling it predictable. Before the change, it was predicatbly eth0. Now, it's different on every different model. It's not doublespeak, the interfaces are named exactly according to where they are on the PCI bus. If you had two interfaces, they show up to the kernel in random order by time and sometimes eth0/eth1 are nto the same they were before the reboot. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51 I've seen this happening once on a cheap laptop with a stripped down BIOS I can't even recall brand for, it had a kludge in the BIOS settings for hotplugging, turning it off, allowed the port to remain same, turning it on, some machine specific code gets executed and the kernel interprets the same port as different port Bad hardware, bad hardware settings, maybe missing exception for that particular hardware type in the code that determines the name... I'm not sure, I don't have the machine anymore - Samuli
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/14 11:47, Samuli Suominen wrote: On 26/09/14 11:22, Canek Peláez Valdés wrote: On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick n...@digimed.co.uk wrote: On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote: I buy machines with one ethernet interface. What I find particularly annoying is this doublespeak about calling it predictable. Before the change, it was predicatbly eth0. Now, it's different on every different model. It's not doublespeak, the interfaces are named exactly according to where they are on the PCI bus. If you had two interfaces, they show up to the kernel in random order by time and sometimes eth0/eth1 are nto the same they were before the reboot. That may be true for PCI devices but not for USB ones. If you unplug a USB device and plug it back into the same port, it will get a different device number. The naming is more predictable, but it's not there yet. That doesn't sound right. If unplugging a USB net device and plugging it again *in the same port* results in a different device *name*, then it is a bug and should be reported; the description of the algorithm in [1] sounds like it should get always the same name for the same port, unless I'm misunderstanding something. Regards. [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51 I've seen this happening once on a cheap laptop with a stripped down BIOS I can't even recall brand for, it had a kludge in the BIOS settings for hotplugging, turning it off, allowed the port to remain same, turning it on, some machine specific code gets executed and the kernel interprets the same port as different port Bad hardware, bad hardware settings, maybe missing exception for that particular hardware type in the code that determines the name... I'm not sure, I don't have the machine anymore - Samuli Later kernels *can mark interfaces predictable in a new form of metadata*, and udev = 209 can pick that information up, and then it won't do anykind of userspace renaming on it, since kernel has declared the interface name to be steady...predictable...always same, so I hope we are moving towards kernel assigning predictable names for all drivers and we can get rid of the userspace renaming of interfaces all together at some point I really believe this is a task for the kernel to provide predictable names, and all this userspace renaming is just a bandage we can hopefully soon rip off - Samuli
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Fri, 26 Sep 2014 12:04:47 +0300, Samuli Suominen (ssuomi...@gentoo.org) wrote about Re: [gentoo-user] Re: udev (viable) alternatives ? (in 54252c2f.1030...@gentoo.org): [snip] Later kernels *can mark interfaces predictable in a new form of metadata*, and udev = 209 can pick that information up, and then it won't do anykind of userspace renaming on it, since kernel has declared the interface name to be steady...predictable...always same, so I hope we are moving towards kernel assigning predictable names for all drivers and we can get rid of the userspace renaming of interfaces all together I hope these kernel-assigned interface names are configurable, as I have been naming the interfaces on my machines with *mnemonic* names for many years now. [These are names like inet and lan for interfaces that connect the machine to the Internet or my LAN.] I certainly do not want to go back to eth0 and the like -- or worse still, udev's predictable names -- as these are not mnemonic in any way. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/14 19:47, David W Noon wrote: On Fri, 26 Sep 2014 12:04:47 +0300, Samuli Suominen (ssuomi...@gentoo.org) wrote about Re: [gentoo-user] Re: udev (viable) alternatives ? (in 54252c2f.1030...@gentoo.org): [snip] Later kernels *can mark interfaces predictable in a new form of metadata*, and udev = 209 can pick that information up, and then it won't do anykind of userspace renaming on it, since kernel has declared the interface name to be steady...predictable...always same, so I hope we are moving towards kernel assigning predictable names for all drivers and we can get rid of the userspace renaming of interfaces all together I hope these kernel-assigned interface names are configurable, as I have been naming the interfaces on my machines with *mnemonic* names for many years now. [These are names like inet and lan for interfaces that connect the machine to the Internet or my LAN.] I certainly do not want to go back to eth0 and the like -- or worse still, udev's predictable names -- as these are not mnemonic in any way. Later kernel marks some drivers interface names predictable or stable, not sure which word is best to use here, and then udev won't rename it by default to anything. The kernel assigned name could be anything, and I doubt it's in the eth* namespace And they can still be renamed by custom rules, that won't change, it's just that they won't get renamed by *default* anymore
[gentoo-user] Re: udev (viable) alternatives ?
Samuli Suominen ssuominen at gentoo.org writes: Any other caveats (short term) on switching udev to eudev? in fact, from what I last checked, eudev's networking is at same level with udev-208, from time before the .link support at all ah, back when ethernet defaulted to eth0 not enp5s0 ? eudev is really useful only for sys-libs/musl users at this time, but you are free to experiment with it! so lilblue (Anthony's amd64 hardened gentoo) is the only candidate I can think of with musl? So I choose this, then profile must be set to: (eslect profile list): [16] hardened/linux/musl/amd64 I'd be better of with a fresh install of lilblue + musl + eudev is what you are really saying here? James
Re: [gentoo-user] Re: udev (viable) alternatives ?
James wrote: Samuli Suominen ssuominen at gentoo.org writes: Any other caveats (short term) on switching udev to eudev? in fact, from what I last checked, eudev's networking is at same level with udev-208, from time before the .link support at all ah, back when ethernet defaulted to eth0 not enp5s0 ? Mine still does here. It's been eth0, eth1 etc for ages even after switching. I don't recall doing anything to keep it that way. James Dale :-) :-)
Re: [gentoo-user] Re: udev (viable) alternatives ?
On Thu, Sep 25, 2014 at 07:03:02PM +, James wrote Samuli Suominen ssuominen at gentoo.org writes: Any other caveats (short term) on switching udev to eudev? in fact, from what I last checked, eudev's networking is at same level with udev-208, from time before the .link support at all ah, back when ethernet defaulted to eth0 not enp5s0 ? I buy machines with one ethernet interface. What I find particularly annoying is this doublespeak about calling it predictable. Before the change, it was predicatbly eth0. Now, it's different on every different model. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 26/09/2014 02:23, Walter Dnes wrote: On Thu, Sep 25, 2014 at 07:03:02PM +, James wrote Samuli Suominen ssuominen at gentoo.org writes: Any other caveats (short term) on switching udev to eudev? in fact, from what I last checked, eudev's networking is at same level with udev-208, from time before the .link support at all ah, back when ethernet defaulted to eth0 not enp5s0 ? I buy machines with one ethernet interface. What I find particularly annoying is this doublespeak about calling it predictable. Before the change, it was predicatbly eth0. Now, it's different on every different model. It's not doublespeak, the interfaces are named exactly according to where they are on the PCI bus. If you had two interfaces, they show up to the kernel in random order by time and sometimes eth0/eth1 are nto the same they were before the reboot. You are just looking at this from the wrong point of view. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: udev (viable) alternatives ?
On 25/09/14 22:03, James wrote: Samuli Suominen ssuominen at gentoo.org writes: Any other caveats (short term) on switching udev to eudev? in fact, from what I last checked, eudev's networking is at same level with udev-208, from time before the .link support at all ah, back when ethernet defaulted to eth0 not enp5s0 ? nope, 208 was back when 80-net-name-slot.rules predictable rules were used which ignored kernel metadata for predictable networking i.e. the insufficient implementatition, which got replaced by 99-default.link and 80-net-link-setup.rules what you are referring is the buggy pre-udev-197 networking, which you can unfortunately still get with USE=rule-generator, it will keep renaming your interfaces despite kernel telling not to, so kernel drivers that mark eth0 as stable, might get renamed to eg. eth1 if you have 2 cards it's really messy, only 209 (and higher) handles things right, the new .link setup, with kernel naming support eudev is really useful only for sys-libs/musl users at this time, but you are free to experiment with it! so lilblue (Anthony's amd64 hardened gentoo) is the only candidate I can think of with musl? So I choose this, then profile must be set to: (eslect profile list): [16] hardened/linux/musl/amd64 I'd be better of with a fresh install of lilblue + musl + eudev is what you are really saying here? that's the only usecase for eudev currently, yes, otherwise you have no reason to switch
