| View previous topic :: View next topic |
| Author |
Message |
gotyaoi
Tux's lil' helper
Joined: 01 Apr 2013
Posts: 137
|
 Posted: Fri Nov 08, 2013 7:47 am Post subject: |
 |
|
So, from looking around a bit, this is what I have discovered so far (caveat; I may have no idea what I'm talking about):
Under normal operation, when a device is plugged in, the kernel creates a folder for it under /sys somewhere which contains various files who's contents are the attributes of the new device. It also generates a 'uevent', which it both sends out over the netlink socket as well as storing in the new folder under /sys. If udev is currently running, it is listening on the netlink socket, receives the uevent, runs it through the rules and takes appropriate action.
For the case where udev is not yet running, the uevent sent over netlink is ignored. When udev starts is where things happen.
The udev init script calls
| Code: | udevadm trigger --type=subsystems --action=add
udevadm trigger --type=device --action=add |
looking into the source code here: http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udevadm-trigger.c
we see that this eventually boils down to a call to udev_enumerate_scan_subsystems or udev_enumerate_scan_devices, which can be found here: http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev-enumerate.c
As they say, these functions scan /sys for kernel subsystems or devices respectively and adds them. So it seems that there's not really a buffer per-se, except the /sys tree. |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Nov 08, 2013 2:40 pm Post subject: |
|
|
Thanks for your reply.
So there are two possibilities:
1. The loss of the uevent (finally, I know the right term) is severe for some devices which need udev care and which perhaps do not appear in /sys correspondingly. If this is the case this make all early boot techniques (including initrd) very questionable since you have a built-in race for all attached such devices.
2. All kernel drivers follow the rule that the later trigger actually has the same effect as an uevent would have (I did not check the sources carefully, but I assume that at least the standard udev rules will be carried out for the devices started with adevadm trigger).
If the latter is the case, I do not understand the whole arguments for separate /usr: You just need the early-boot dependencies correctly and start udev only afterwards. This should work with any sane init-system and all claims about e.g. bluetooth needing stuff would just be nonsense, since one could just mount /usr before starting to accept uevents. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Fri Nov 08, 2013 3:06 pm Post subject: |
|
|
| mv wrote: | | If the latter is the case, I do not understand the whole arguments for separate /usr: |
it's simple really, they want people to only look at things one way.
I'm not sure why a distro based on building source from scratch thinks that blindly following binary distros is a good idea.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Fri Nov 08, 2013 4:24 pm Post subject: |
|
|
| mv wrote: |
If the latter is the case, I do not understand the whole arguments for separate /usr: You just need the early-boot dependencies correctly and start udev only afterwards. This should work with any sane init-system and all claims about e.g. bluetooth needing stuff would just be nonsense, since one could just mount /usr before starting to accept uevents. |
Because there is a political agenda. The technical merits have long been debunked multiple times and there are easy solutions which are intentionally being withheld, because zealotry wins the day.
_________________
Ryzen 3700X, Asus Prime X570-Pro, 64 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Nov 08, 2013 5:03 pm Post subject: |
|
|
I am still not convinced that case 2 of the possibilities I mentioned above is really true. You all seem to assume this tacitly.
| saellaven wrote: | | Because there is a political agenda. The technical merits have long been debunked multiple times |
Not really: It was always claimed that with systemd it is not possible.
But if case 2 of the above possibilities actually is true, it should also be trivial to do this even with systemd: Essentially you just have to depend (with Wants= and After=) on usr.mount and make sure that the latter depends on whatever you need to mount /usr (and all contain DefaultDependencies=No). Only systemd itself would have to be moved to /, but this move was a gentoo decision against upstream... |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Fri Nov 08, 2013 5:55 pm Post subject: |
|
|
| mv wrote: | I am still not convinced that case 2 of the possibilities I mentioned above is really true. You all seem to assume this tacitly.
| saellaven wrote: | | Because there is a political agenda. The technical merits have long been debunked multiple times |
Not really: It was always claimed that with systemd it is not possible.
But if case 2 of the above possibilities actually is true, it should also be trivial to do this even with systemd: Essentially you just have to depend (with Wants= and After=) on usr.mount and make sure that the latter depends on whatever you need to mount /usr (and all contain DefaultDependencies=No). Only systemd itself would have to be moved to /, but this move was a gentoo decision against upstream... |
It's not possible with systemd because the developer of systemd doesn't want it to be possible. systemd (formerly udev) managed a separate /usr just fine until he decided to intentionally remove the functionality. He sees "more purpose" for a separate /var but doesn't promise that won't go away if he desires at some point as well.
He doesn't really care about the technical merits. He just does what he wants and assumes that his way is the one true way that everyone must follow. Outside of some corner cases, none of this stuff was broken until he decided to break it and in doing so, he's breaking the majority of systems that just worked before. Today, it's my pet piece of functionality, tomorrow it's going to be someone else's, yesterday it was network renaming which totally fails his stated purpose of making it persistent when the solution was always there (assigning by MAC address).
_________________
Ryzen 3700X, Asus Prime X570-Pro, 64 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Nov 08, 2013 8:12 pm Post subject: |
|
|
| saellaven wrote: | | It's not possible with systemd because the developer of systemd doesn't want it to be possible. |
This is not true: Despite giving his post an opposite title, Poettering claims that systemd itself is fine with separate /usr, and only bluetooth etc. are blaimed. With setting the dependencies as I mentioned, things like these should not be a problems. I really see no technical obstacle why a separate /usr shouldn't work with systemd (again: if case 2 is true).
Of course, with systemd installed in /usr as by the gentoo ebuild, there is no chance, but Poettering himself claimed that this is not a good idea. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Nov 10, 2013 6:38 pm Post subject: |
|
|
| ulenrich wrote: | By giving SteveL Your feedback, you pushed him to announce a big step forward:
| steveL wrote: | Thanks, saellaven, that's great info to have. I've updated the title to reflect that the patches are confirmed to work with eudev.
The way things are going with upstream "systemd-udev-dbus-syslog-kitchen_sink" it looks like I'll have to switch soon as well: |
He finally has promised to use this alternative! This hopefully will foster further development and he will overcome his Stockholm syndrome as he writes about it. |
WTF are you on about? You apparently cannot even read, and want to attribute a symptom I describe, with a quote showing said symptom, to me. You are deliberately misquoting me and twisting my words, and I do not like it.
Don't do that.
Further more I am free to use whatever I want: it's not your place to declaim that "finally" I have promised to use an alternative. I'm the one who's kept upstream udev working without an initramfs for the last 2 years. I do not at all appreciate you injecting your ignorance and attributing your position to me: I have not promised to use anything at all. What I choose to use in the future, is my business. So GTFO with your politically-motivated claptrap.
And learn to think about what you are saying, before you post such blatant nonsense in the future. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Nov 10, 2013 6:47 pm Post subject: |
|
|
| mv wrote: | So there are two possibilities:
1. The loss of the uevent (finally, I know the right term) is severe for some devices which need udev care and which perhaps do not appear in /sys correspondingly. If this is the case this make all early boot techniques (including initrd) very questionable since you have a built-in race for all attached such devices.
2. All kernel drivers follow the rule that the later trigger actually has the same effect as an uevent would have (I did not check the sources carefully, but I assume that at least the standard udev rules will be carried out for the devices started with adevadm trigger).
If the latter is the case, I do not understand the whole arguments for separate /usr: You just need the early-boot dependencies correctly and start udev only afterwards. This should work with any sane init-system and all claims about e.g. bluetooth needing stuff would just be nonsense, since one could just mount /usr before starting to accept uevents. |
I sincerely doubt that the device enumeration scan is not as encompassing as the uevents. In any event as you point out, the same thing happens in both cases: there is always a delay between system boot and udev startup: there has to be, since all local drives must be mounted by that point, as Greg K-H initially outlined on the mailing-list. So it really makes no difference, and as you say, you just need the early boot dependencies available, however you do it.
WRT bluetooth, apparently the device (keyboard) is needed in order to interact with the system during early boot. Not sure if that's grub (if so, how do you get grub to load it, and what does that have to do with udev since the kernel has not started up?) or just being able to interrupt the boot process, eg for "interactive" startup with openrc. In any event, the chicken-and-egg nature of needing udev-started devices in order to start udev has never been explained, but it's not my problem, so I don't really care too much. |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3267
Location: Canada
|
| Posted: Sun Nov 10, 2013 10:02 pm Post subject: |
|
|
| steveL wrote: |
WRT bluetooth, apparently the device (keyboard) is needed in order to interact with the system during early boot. Not sure if that's grub (if so, how do you get grub to load it, and what does that have to do with udev since the kernel has not started up?) or just being able to interrupt the boot process, |
I, for one, can't develop much sympathy to that problem. I think it is not much to ask user to connect physical keyboard if one is to play with interactive boot. Otherwise one may put out an argument that one needs a networking stack in grub to be able to early ssh into the machine while it is booting etc. There are limits how much of different hardware can be available during early boot, or it is not early at all. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Nov 11, 2013 7:53 am Post subject: |
|
|
| steveL wrote: | | [I sincerely doubt that the device enumeration scan is not as encompassing as the uevents. In any event as you point out, the same thing happens in both cases: there is always a delay between system boot and udev startup |
This was also my thought, but OTOH, it wouldn't be the first time that udev has an obvious race which nobody noticed for years...
(Recall the net naming disaster. And e.g. once or twice a year it still happens that my camera and tv card get exchanged links, despite they should be setup depending on "DRIVER" which should be unique for these two devices...) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Nov 11, 2013 12:48 pm Post subject: |
|
|
| dmpogo wrote: | | steveL wrote: | | WRT bluetooth, apparently the device (keyboard) is needed in order to interact with the system during early boot. Not sure if that's grub or just being able to interrupt the boot process, |
I, for one, can't develop much sympathy to that problem. I think it is not much to ask user to connect physical keyboard if one is to play with interactive boot. Otherwise one may put out an argument that one needs a networking stack in grub to be able to early ssh into the machine while it is booting etc. There are limits how much of different hardware can be available during early boot, or it is not early at all. |
Well, ISTR that the device was basically a tablet, or some such, that only did bluetooth for keyboard. As you say, an esoteric setup, and one for which I have no issue with an initrd/ramfs: if you need it, by all means use it.
I just don't accept that we should make the simple cases complex, in order to deal with the complex cases. As we've discussed, the same thing happens in both instances, whether you're booting via initramfs, or directly via rootfs. So we should just focus on those issues (which aren't that difficult, ffs, they've been with us since the beginning if we consider eg encrypted root) instead of arguing about why people should just do things "our way" which is never the right approach. Or we wouldn't be able to work, since one size really would fit all.
I don't see that happening any time soon, and even if it does, Gentoo is predicated on the exact opposite approach to computing.
| mv wrote: | | steveL wrote: | | [I sincerely doubt that the device enumeration scan is not as encompassing as the uevents. In any event as you point out, the same thing happens in both cases: there is always a delay between system boot and udev startup |
This was also my thought, but OTOH, it wouldn't be the first time that udev has an obvious race which nobody noticed for years...
(Recall the net naming disaster. And e.g. once or twice a year it still happens that my camera and tv card get exchanged links, despite they should be setup depending on "DRIVER" which should be unique for these two devices...) |
There may well be a "race" in that uevents may be fired before udev starts up and does a scan. Just from what I recall (for PCI), I'd expect that scan to initialise the drivers, ie call the device driver and tell it we're starting up. Granted some devices may already have started up (some will have to, such as our disk) but isn't that something expected?
The important point is that it's inherent in the whole process, and thus it makes no difference whether you are in an initramfs or not.
Either way you need "local" drives mounted before udev starts, and initramfs is meant to handle the shiny "new" world of /usr over the network, so there is no way anyone can tell me that it does not also imply a delay between bootup and udev startup, which requires /usr mounted before it starts.
If there is an issue, then it needs to be addressed for both setups, and the "traditional" method (with udev delayed after localmount) is no worse than initramfs in this regard. It simply cannot be, if one is looking to fix the "race". |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Nov 12, 2013 10:59 am Post subject: |
|
|
| steveL wrote: | | it makes no difference whether you are in an initramfs or not |
True, but since usually initramfs is finished very quickly, this might mask some race which always existed. |
|
| 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
|
|
Kernel & Hardware
