Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
2018-01-15 8:39 GMT-03:00 Laurent Bercot: > > The change is obviously incompatible with mdevd-0.0.1.0. It appears to > work for me, but please test it - especially Olivier who was missing > events with the old coldplug. If no problems are found, I'll cut the > 0.1.0.0 release. Worked for me too. All kernel modules loaded, same as when using eudev. G.
Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
I actually already have that trick used to log all events, so I can tell you that since I booted I've had 640 events processed. Just ran mdevd-coldplug again, and now I have 1172 events logged, so that's 532 events generated by mdevd-coldplug just now. In my log I have basically the output of "date && env && echo ---" and based on said log, those 532 events are around 120 KB. As for the 640 original events, around 140 KB. It seems it should all be under the 192 KB of the default buffer, but as observed with that buffer mdevd runs out of space... 1 MB is propably too much, I should try to see how much is actually needed. Next time I get to do some reboots I'll see what I can find. Cheers,
Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
And to answer your question, about what could cause such a burst of events, this time I have an easy answer: mdevd-coldplug ! Yes, I forgot to mention this. The kernel-generated events seem to be significantly heavier than the mdev-style synthetic ones. The DEVPATH is the full path without symlinks, which is usually pretty long, and there are also a bunch of misc variables with every event. It's very common for a kernel- generated event to reach 250 bytes, which means a 64kB buffer can only hold 256 events, and probably less because some events are easily 300 bytes long; so I tripled the buffer size. If it's not enough for a run-of-the-mill desktop PC, I should increase it again. 1 MB sounds really excessive though: it means it would be able to hold 3000 to 4000 events. Can you run mdevd-coldplug with a dry-run mdevd to count the number of events, you're getting and their approximate size? A nice trick to trace events is to add the following line at the top of your mdev.conf file: -.* 0:0 0600 ! @env which will send a bunch of lines to your catch-all logger. :) Thanks for testing! -- Laurent
Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
On Mon, 15 Jan 2018 11:39:19 + "Laurent Bercot" wrote: > The change is obviously incompatible with mdevd-0.0.1.0. It appears > to work for me, but please test it - especially Olivier who was > missing events with the old coldplug. If no problems are found, I'll > cut the 0.1.0.0 release. The good news is, it appears to work fine here as well, even with my fancy hardware :p As a side note however, note that when I updated I also reverted to the default buffer size (which I noticed you upped), but then not only did my audio card not show up (amongst other things, this one is noticable because of a service waiting for it...) but some hard disks seemed not to have been processed either. A quick look in the log showed my old friend was back: mdevd: fatal: unable to receive netlink message: No buffer space available And to answer your question, about what could cause such a burst of events, this time I have an easy answer: mdevd-coldplug ! My first try when I noticed the error was simply to re-run mdevd-coldplug, and I got the buffer error again (and still no audio/etc) Easy fix, I upped the buffer back to 1MB and everything went fine this time. Rebooted since, with the buffer set to 1MB, and everything works fine right away. So yay (but my fancy hardware requires a "larger-than-normal" buffer for mdevd it seems). Anyhow, it all works fine now, with mdevd & mdevd-coldplug. Thanks!
Re: skalibs: issue with strnlen() when statically linking with uclibc-ng
Thanks! skalibs-2.6.3.1 released. -- Laurent
Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
OK, I did this, I compared what I got by reading every /sys/class/*/*/uevent and /sys/bus/*/devices/*/uevent file (like mdevd-coldplug does for /sys/dev/*/*/uevent) with what I got by writing 'add' to them (like udevadm trigger does) and then using 'udevadm monitor --kernel --property' to watch the netlink events, and there's no difference. Ah, but you are too late, Mr. Bond! The change was already in motion, and all your competence cannot stop me from unleashing it upon the world. And you will be in a prime spot to witness and experience it firsthand, ha ha ha! Even though it's still possible to synthesize events, I find it cleaner, as in more architecturally correct, to let the kernel create them. The kernel is inherently more trustworthy than any userland process, so it loosens up the requirements on validation: there will be no fake events, and events will all be well-formed. The only reason why I did not do this before is that I was closely following the "mdev -s" model, for compatibility; but if the model is wrong, I'll switch to the "udevadm trigger" one in a heartbeat. This also solves Olivier's secondary problem, since "start the uevent manager first, then run the coldplug and have the existing uevent manager pick up events" becomes the correct - and only - way to make it work properly. The latest mdevd git head implements those changes: mdevd-netlink and mdevd have been merged, the mdevd-netlink binary has disappeared, and mdevd-coldplug doesn't print anything on stdout but triggers kernel events instead, scanning /sys/subsystem/*/devices/* when /sys/subsystem exists and /sys/class/*/* and /sys/bus/*/devices/* otherwise. mdevd uses the "-D fd" option to trigger readiness notification, since the -d switch was already used. The change is obviously incompatible with mdevd-0.0.1.0. It appears to work for me, but please test it - especially Olivier who was missing events with the old coldplug. If no problems are found, I'll cut the 0.1.0.0 release. -- Laurent
