udev utilities work!

With reference to my previous post, yep, it works. There were some minor issues and I've sorted out most of them.

Puppy now has the 'udevtrigger' and 'udevsettle' utilities, from the udev version 114 package, that was compiled statically with T2 back when I build the original packages for the Puppy4 series. To clarify that this is not the full udev package, I have created a PET package named 'udev_cut-114-static' for Unleashed.

So, Puppy has become slightly "udevified". Actually, if we ever decided to, it would probably be quite easy to slot in the full udev package. Quite simply, 'udevd' would replace my 'pup_event_backend_d'. The main difficulty would be figuring out the udev rules to make udevd send appropriate messages to my 'pup_event_frontend_d' script.

---

Comments

Same device naming
Username: Viking Sailor
Berry, One thing udev does is provide the same port naming across boots. That way a app that requires a certain physical port can be assured that it will be assigned to say ETH0. Does your implementation provide this feature? Thanks, Paul

Same device naming
Username: Viking Sailor
"Berry, One thing udev does is provide the same port naming across boots. That way a app that requires a certain physical port can be assured that it will be assigned to say ETH0. Does your implementation provide this feature? Thanks, Paul

udev
Username: Dougal
"I got Udev working in Puppy about a month ago, but there's a basic problem with it that I couldn't find a solution to: it loaded for me both rt2500usb and rt73usb -- and there's no way in the rules to specify a preference, like we do in a shell script. (using udev would also require learning the scripting language used in the rules... to be able to solve some problems -- I had some using the rules from Debian.) Viking: you don't need udev for that, there are other, simpler, ways to rename interfaces (I think it is the ifplugd package that allows you to configure the networks to match a HW id to a interface name, then will automatically rename it at boot.).

udev 124
Username: coolpup
"Latest version released 11th June. http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/

Re: rt2500usb and rt73usb
Username: BarryK
"Dougal, I simply incorporated all of our existing mechanisms, that is, the PCI_OVERRIDES, SKIPLIST and ADDLIST variables in /etc/rc.d/MODULESCONFIG. In the latest incarnation that is using udevtrigger and pup_event_backend_d, the latter script reads MODULESCONFIG. It is no longer done in /etc/rc.d/rc.modules or rc.modules2, and as the pup_event_backend_d continues to run, those rules in MODULESCONFIG continue to work for hotplugging.

Re: rt2500usb and rt73usb
Username: Dougal
"Yes, I know you can blacklist them. What I meant is that using udevd, which works solely with the udev rules, seems like it could be problematic. (what is normally done with multiple modules -- like e100 and eepro100 -- is that one is completely blacklsted, in the modprobe blacklist file [udev runs "modprobe -b" with the aliases], which is not good, since the devices those modules support don't all overlap...) I'm also not sure it's worth using udevtrigger, since it takes a few seconds and gives you a list of ~1000 lines to parse through, which takes about ten times as long than just getting the aliases with "find" (yes, you also get other info, like devices to create, but Puppy still uses the static /dev, so it's not likely anything critical will be missing at boot time). It might be worth running from somewhere like delayedrun, so it is all parsed in the background when no-one notices. Using udevd to send the info to your script could be good, but that forces you to have to deal with the rules, to make them send you only relevant info...

Re: udevtrigger
Username: BarryK
"You can tell udevtrigger to narrow down the search, like this: #udevtrigger --attr-match=modalias --attr-match=firmware ...that works well. However I have for now left it at just 'udevtrigger' as subjectively it seems very fast. Yeah, I know it spits out an awful lot of stuff. Fortunately that is done with compiled code so that come very fast, and my script ignores most of them. Yes Puppy does have a static /dev, and currently pup_event_backend_d is ignoring all requests to create a devnode, except for block devices. So if someone has a lot of drives and partitions not covered by the static ones then they will get automatically generated. After 4.1alpha3 comes out, there can be some speed testing, especially on old hardware, and tweaks applied if necessary.

Tags: puppy