| View previous topic :: View next topic |
| should eudev be default set for virtual/udev? |
| yes, eudev as default |
|
93% |
[ 73 ] |
| no, udev as default |
|
6% |
[ 5 ] |
|
| Total Votes : 78 |
|
| Author |
Message |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
 Posted: Thu Feb 11, 2016 5:34 pm Post subject: |
 |
|
We all know that systemdbust-udev is unsupported as Gentoo builds it.
Gentoo has been told this publicly, on at least two separate occasions. The edicts I recall handed down from on high were: "Gentoo, this is your wake-up call", and "Gentoo this is your final wake-up call" over a year later.
In both cases, Poeterring was talking to Samuli, as representative for Gentoo within systemdbust circles, maintaining the split udev.
We all recall how "udev will continue to be supported separately" turned out in reality: build all of systemdbust, and "separate udev still works" in your initramfs, but is otherwise unsupported (and we'll break the build-system to keep it like that.)
Meanwhile we broke separate /usr as well (but we're only the messenger, who insists you do everything like we tell you, or bad things will happen, mostly to do with how you're treated.)
Some Gentoo developers have tried to maintain that this clear violation of "upstream" (though as we've seen, they're more leeches than originators) wishes and intent is somehow irrelevant when it comes to systemdbust-udev, iow all the basic rules have changed, because they clearly have agendas to push wrt systemdbust.
That is why you always see the same faces, pushing the same non-sequitur arguments, and brow-beating of any dissent, as mgorny has done in that bug with his drivel about "incorrect and irrelevant" wrt his own statements.
But then, he's a great one for abusing his position on channels where "developers" are in charge of immoderation, ime, and hiding from any other discussion. |
|
| Back to top |
|
 |
miket
Guru
Joined: 28 Apr 2007
Posts: 489
Location: Gainesville, FL, USA
|
| Posted: Thu Feb 11, 2016 5:57 pm Post subject: |
|
|
I'm thinking of those default installs. We have virtual/editor in the system set because surely the user is going to need an editor to do much of anything once the new system is booted. It's not optional; we have one installed and ready in the stage3. In the same way, you have to take care of device management before you can go anywhere on the first boot--if it's a real host. (If the installation is for a chroot build host or for a container, you don't need a kernel. If you're building a VM guest, you can easily get by without a boot loader--for my part, I often don't). It can be argued that in these two cases the device manager isn't needed either, but three factors militate for including either udev or eudev in the stage 3:
- Anyone booting a bare-metal host or a VM guest is going to need to take care of device management.
- As opposed to the selection of editors, kernel configurations, and boot loaders, the great majority of users are going to want udev or eudev.
- As opposed to kernels and boot loaders, device managers are relatively svelte. There's not a huge size penalty that comes with including a device-manager in stage-3 tarballs.
Stage-3's are starting points anyway. I always install vim to replace nano, and replace udev with eudev (and also do some demoronization in /etc/udev/rules.d/). The point is that if I didn't, I'd still be able to boot once I'd taken care of what would run as kernel and how it would get started. If my path were instead to rebuild busybox with USE=mdev and/or make some device nodes by hand, this is the point where I know to do it.
As you might guess, my choice for that device manager is eudev. It's somewhat smaller than udev and less silly.
One more note about the Handbook: gad, the thing is getting long! Its table of contents has 42 sections. This is a big Too Bad: it was very useful to have alternate install instructions around that say things like "Do the steps in pages 1, 2, and 3 of the Handbook. At page 4, do Y instead of X. Continue with page 5 and then do ZZ instead of page 6." Now there are no nice anchors.
If you're contemplating adding a "build a device manager" step in the Handbook, consider how it would complicate things even further. There are 42 steps in the AMD-64 Handbook already. Surely we don't need to go past that magic number! |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Feb 11, 2016 6:17 pm Post subject: |
|
|
Oh I absolutely agree you need a device-manager in stage3, and it should be eudev (in-house, working reliably for years, and no entanglement, as well as a much lighter bootstrap.)
Anyone who chooses a systemd profile will automatically switch over to systemdbust-udev, as it incorporates that project and several others.
Thus the only thing to ensure is that portage handles such a switchover well enough, which from everything I have read, it does.
It's the other way round that appears deliberately borked.
I really don't see what the problem is: systemdiots can easily make a stage4; users have been doing that for years.
I just wish they wouldn't try to turn that into releng's problem, when it so clearly does not need to be. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Feb 11, 2016 8:31 pm Post subject: |
|
|
| miket wrote: | | I'm thinking of those default installs. We have virtual/editor in the system set because surely the user is going to need an editor to do much of anything once the new system is booted. It's not optional; we have one installed and ready in the stage3. |
miket ... I would see it somewhat differently, we have an editor in the stage3 because it is needed in the chroot. That's not true of virtual/dev-manager.
| miket wrote: | | In the same way, you have to take care of device management before you can go anywhere on the first boot--if it's a real host. (If the installation is for a chroot build host or for a container, you don't need a kernel. If you're building a VM guest, you can easily get by without a boot loader--for my part, I often don't). |
OK, but as a counter argument, there are any number of things a user might expect, or want, in the stage3, such as the various tools used to provide networking (such as for wireless, pppoe, etc, setups). Similarly, you can't "go anywhere on the first boot" without these, but they are not provided in the stage3 because needs vary. Yes, device management is somewhat different ... more on that below.
| miket wrote: | It can be argued that in these two cases the device manager isn't needed either, but three factors militate for including either udev or eudev in the stage 3: - Anyone booting a bare-metal host or a VM guest is going to need to take care of device management.
- As opposed to the selection of editors, kernel configurations, and boot loaders, the great majority of users are going to want udev or eudev.
- As opposed to kernels and boot loaders, device managers are relatively svelte. There's not a huge size penalty that comes with including a device-manager in stage-3 tarballs.
|
Well, really, users don't have a choice as to "what they want", device management is basically a shoe in for udev (of whatever colour). If a user selected to install mdev, and then attempt to install the current stable sys-apps/usbutils (due to a systmed dev having co-opted usbids) it now requires udev (in order to build). Similarly, udev (in some form) is required for net-wireless/crda, and net-wireless/wpa_supplicant has a hardcoded dep for crda. So, whatever "udev" is chosen, its the same claws, and the same hook used to keep everyone requiring udev.
So, if we want to argue which of the packages providing virtual/dev-manager most matches the bulletlist, I would say that package is sys-apps/busybox[mdev] (though, imo, it would be better if it were provided by a seperate package) ...
1). it does device management (and no crda, or whatever, isn't device management)
2). it's a "svelte" 26K standalone.
3). doesn't run as a "daemon" ... and why would it need to, it recieves uevents from the kernel!
4). configurable, and can call scripts on events, yeah, actual shell scripts.
5). can coexist with other things, and doesn't want to force you to use it by making everything depend on it, or its libraries.
6). eat my API ... see points 4, 7, and 8.
7). written by a sane person (though probably more hands involved now) who doesn't think that by using /sys you get to own it.
8). isn't written by GKH, KS, LP ... who (either collectively or individually) own device management, and whatever "API" udev is exposing in /sys.
8). asigning a device name to MAC is simple (/etc/mactab).
... but none of that matters, due to reasons provided above ;) Nothing can replace udev, not even eudev, because nothing can replace udev.
best ... khay |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2285
Location: Adendorf, Germany
|
| Posted: Fri Feb 12, 2016 7:02 am Post subject: |
|
|
IIRC to boot you do not need a device manager. A kernel maintained devfs is enough. You only need a device manager if you want to change /dev *after* booting, like when hotplugging external media.
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6053
Location: Removed by Neddy
|
|
| Back to top |
|
|
berferd
Tux's lil' helper
Joined: 13 May 2004
Posts: 117
|
| Posted: Sun Feb 14, 2016 3:14 am Post subject: |
|
|
| Eudev, please. I've been using it for years now on several systems with absolutely no problems. The reasons for not making it default for those of us who choose not to use systemd are embarrassingly political. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sun Feb 14, 2016 3:35 pm Post subject: |
|
|
| khayyam wrote: | So, if we want to argue which of the packages providing virtual/dev-manager most matches the bulletlist, I would say that package is sys-apps/busybox[mdev] (though, imo, it would be better if it were provided by a seperate package) ...
[...]
3). doesn't run as a "daemon" ... and why would it need to, it recieves uevents from the kernel! |
Listening for netlink events is a ton more efficient than forking a program for every single hotplug event (which can be three digit numbers at boot on a modern PC).
But you don't have to use *udev for that: sys-apps/s6-linux-utils has a set of programs that uses netlink and doesn't suck (and yes, you can configure it to run shell scripts if you really want to - it's proper unix-y engineering). |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Feb 14, 2016 4:43 pm Post subject: |
|
|
| Ant P. wrote: | | khayyam wrote: | | 3). doesn't run as a "daemon" ... and why would it need to, it recieves uevents from the kernel! |
Listening for netlink events is a ton more efficient than forking a program for every single hotplug event (which can be three digit numbers at boot on a modern PC). |
Ant ... yeah, argeed, you also need to make sure to serialise hotplug events at boot.
| Ant P. wrote: | | But you don't have to use *udev for that: sys-apps/s6-linux-utils has a set of programs that uses netlink and doesn't suck (and yes, you can configure it to run shell scripts if you really want to - it's proper unix-y engineering). |
I looked at s6-uevent-listener, s6-uevent-spawner, and a similar 'netlink' uevent listener nldev with that in mind, I forget the details but I do remember spending some time reading various lists and such ... and nothing got done. Thanks for the pointer, I'll take another look.
best ... khay |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sun Feb 14, 2016 4:53 pm Post subject: |
|
|
| Haven't heard of nldev before, thanks for that too. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3200
|
| Posted: Sun Feb 14, 2016 6:51 pm Post subject: |
|
|
| Quote: | | Listening for netlink events is a ton more efficient than forking a program for every single hotplug event (which can be three digit numbers at boot on a modern PC). |
| Code: | $ S=$SECONDS; i=1000000; while [ $i -gt 0 ]; do i=$(($i - 1)); echo 1 > /dev/null; done; echo runtime was: $(($SECONDS-$S))
runtime was: 19 |
So... the loop itself takes 7 seconds, loop with echo takes 19, and there is a 6 digit number there. 3 digit number would increase my boot time by stunning 0,2 sec. This is under (false) assumption that udev and mdev are otherwise equal.
0.2 sec once in a blue moon. Too little to be a point. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Sun Feb 14, 2016 7:24 pm Post subject: |
|
|
| szatox wrote: | | Quote: | | Listening for netlink events is a ton more efficient than forking a program for every single hotplug event (which can be three digit numbers at boot on a modern PC). |
| Code: | $ S=$SECONDS; i=1000000; while [ $i -gt 0 ]; do i=$(($i - 1)); echo 1 > /dev/null; done; echo runtime was: $(($SECONDS-$S))
runtime was: 19 |
|
I think you missed that "echo" is an internal command. To understand the cost of forking use /bin/echo or at the very least (echo ...) (i.e. with braces). Then your loop will take hours unless you remove 2-3 of the zeroes of i=.... |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Feb 14, 2016 9:04 pm Post subject: |
|
|
| mv wrote: | | To understand the cost of forking [...] |
mv, ant, szatox, et al ... having given it some thought I don't think there is much in the way of forking involved. At boot 'mdev -s' is run once, this populates /dev, then on hotplug events mdev is called again, it parses /etc/mdev.conf and acts accordingly, so, ownership, perms, and (optionally) calls a script to do some extra setup (ie, what to name a network interface, etc). So, there aren't triple digit forks at boot, and once booted hotplug events are fairly infrequent.
As far as forking goes, I'm not sure mv is correct, you can get exessive forking (ie, a fork bomb) with the use builtins, eg:
That's not to say that using a builtin won't necessary involve less forks ... but it's not cost free.
NOTE: please don't try that code ... it will exhaust your machine and bring it to a standstill (without some limits in place).
best ... khay |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3200
|
| Posted: Sun Feb 14, 2016 10:18 pm Post subject: |
|
|
Challenge accepted:
| Code: | i=1000000; time while [ $i -gt 0 ]; do i=$(($i - 1)); /bin/echo 1 > /dev/null; done
real 25m21.207s
user 12m10.130s
sys 4m47.580s
|
I had some heavy compilation running in the background (nice=19)
| Code: | (25*60+21)/1000
1.521 |
I admit it's much worse than 0.2 now, but whatever. | Quote: | | and once booted hotplug events are fairly infrequent. |
Yup. Can someone estimate the cost of daemon running all the time just to handle a pendrive slammed into that port once per hour?  |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Feb 14, 2016 10:27 pm Post subject: |
|
|
| szatox wrote: | | Can someone estimate the cost of daemon running all the time just to handle a pendrive slammed into that port once per hour? :lol: |
szatox ... sure, about what it costs to send a group of RHCE to the bahamas for a systemd conference ;)
best ... khay |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Mon Feb 15, 2016 10:39 pm Post subject: |
|
|
| khayyam wrote: | | As far as forking goes, I'm not sure mv is correct, you can get exessive forking (ie, a fork bomb) with the use builtins |
Sure. But you have to use forking; in this example, the forking (of a subshell) happens through a pipe. I had suggested to use either an external program or a subshell (via round braces). If you do neither - as in the original code - you have no forking at all but just code which is evaluated inside the shell. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Mon Feb 15, 2016 10:45 pm Post subject: |
|
|
| khayyam wrote: | | At boot 'mdev -s' is run once, this populates /dev, then on hotplug events mdev is called again |
I haven't looked at details, but I would guess that there is no guarantee that the first mdev -s already sees all devices. Perhaps in the worst case it might see almost no device if most drivers have been initialized when mdev -s is called. In this case, every single device might arise through a hotplug event. Not sure how probable this is, but I would guess that at least in theory it might happen. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Feb 15, 2016 11:42 pm Post subject: |
|
|
| mv wrote: | | khayyam wrote: | | At boot 'mdev -s' is run once, this populates /dev, then on hotplug events mdev is called again |
I haven't looked at details, but I would guess that there is no guarantee that the first mdev -s already sees all devices. Perhaps in the worst case it might see almost no device if most drivers have been initialized when mdev -s is called. In this case, every single device might arise through a hotplug event. Not sure how probable this is, but I would guess that at least in theory it might happen. |
mv ... no, it would, like udev it is looking in /sys and acts on what it finds, the only difference is there is no attempt made to make sure x,y,z gets the deluxe treatment (ie, firmware loading, {un,}predictable network names, etc), all this needs to be scripted if needed.
The point is whether mdev is forking some x hundred times to do what udev does, but I don't think this is in fact happening, the process is run once, it finds x,y,z in /sys, and sets up devices nodes. Once complete then any additional hotplug events are handled (by calling /sbin/mdev) as and when devices, or what-have-you, are connected.
best ... khay |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3200
|
| Posted: Tue Feb 16, 2016 6:21 pm Post subject: |
|
|
Any idea how can hotplug devices in qemu using monitor interface?
I didn't see any hotplug events after inserting modules, but I wanna see if I set it properly... Sure there is some sort of help, but it's not as smooth as it says. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Feb 16, 2016 10:32 pm Post subject: |
|
|
| szatox wrote: | | Any idea how can hotplug devices in qemu using monitor interface? I didn't see any hotplug events after inserting modules, but I wanna see if I set it properly... Sure there is some sort of help, but it's not as smooth as it says. |
szatox ... if I understand correctly, you can get some idea of whats going on with the following:
| hotplug.sh: | #/bin/sh
env >> /var/log/hotplug.log |
... then set this script as 'hotplug':
| Code: | | # echo /path/to/hotplug.sh > /proc/sys/kernel/hotplug |
You can then use the output to create your mdev.conf entry (I am right in thinking you're asking in regard to mdev?).
So, for example:
| /etc/mdev.conf: | | ACTION="add";SUBSYSTEM=foo;.* root:root 660 */path/to/some-script-to-run.sh |
HTH & best ... khay |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Wed Feb 17, 2016 7:30 am Post subject: |
|
|
| khayyam wrote: | | like udev it is looking in /sys and acts on what it finds |
My argument was: Why should /sys be already completely filled in the moment when mdev -s is called? Perhaps it might be still almost empty if almost no kernel driver was initialized yet... |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Wed Feb 17, 2016 2:22 pm Post subject: |
|
|
| mv wrote: | | khayyam wrote: | | like udev it is looking in /sys and acts on what it finds |
My argument was: Why should /sys be already completely filled in the moment when mdev -s is called? Perhaps it might be still almost empty if almost no kernel driver was initialized yet... |
mv ... its not arbitrary, mdev, like udev, also depends on 'sysfs' ...
| awk '{RS="\n\n"}/^depend/' /etc/init.d/mdev: | depend()
{
provide dev
need sysfs
} |
... so, like udev, it will find 'modalias' within /sys, and like udev, load such modules as are needed to provide device nodes. All this happens without hotplug, as events can be injected into /sys/*/uevent, and this is what mdev initialisation does as part of init. So, rather than coded into the device manager (ie, udev), it is separate, the process however is the same, except that mdev doesn't sit around listening to netlink.
So, again, the question is whether mdev is inefficient ITR, I think not, its basically doing what udev does (at boot), the difference is what happens subsequently, and given the number of uevents that may happen once up and running its fairly modest to fork mdev for those.
That being said, its up to you to decide which best suits your use case, the problem I have is that udev is also used (exclusively) for crda, which is beyond its remit as a "device manager", and the way in which it situates itself as the *only* method of doing device management, and so be irreplaceable.
best ... khay |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3200
|
| Posted: Wed Feb 17, 2016 5:37 pm Post subject: |
|
|
| Quote: | . if I understand correctly, you can get some idea of whats going on with the following:
hotplug.sh:
#/bin/sh
env >> /var/log/hotplug.log |
I went for:
| Quote: | | echo echo BUMP > /proc/sys/kernel/hotplug |
inside /init.
The point is without triggering an actual hotplug I can't be sure whether it didn't print anything to shell because there are no events or because kernel swallows the messages. I guess it wasn't the best idea ever, but I didn't feel like rebuilding that image again when I noticed the failure.
Either way, it didn't announce any hotplug events upon loading modules (done via /init after setting hotplug helper to echo. Procfs, sysfs and devfs mounted before.) |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6053
Location: Removed by Neddy
|
| Posted: Sat Feb 27, 2016 8:08 pm Post subject: |
|
|
And it appears its going to be.
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 648
|
| Posted: Sat Feb 27, 2016 8:58 pm Post subject: |
|
|
The council has approved the following decision 7-0:
"In light of the support for eudev among Gentoo non-systemd users, and
a lack of strong technical drivers to block a change, the Council
approves changing the default virtual/udev provider for non-systemd
users to eudev. The council encourages all maintainers to try to
support either provider and cooperate with those who provide patches
when necessary." |
|
| 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
|
|
Gentoo Chat
