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.

It is also fast, and has loaded a couple of extra modules, that no previous Puppy has discovered. This is on top of the extra couple that 4.1alpha2 loads. For example, 4.1alpha2, which I'm running right now, loads 'wmi.ko', but the new system using 'udevtrigger' also loads 'acer_wmi.ko' (which wmi.ko is a dependency of). I think it has something to do with the LEDs on my laptop.

Posted on 16 Jun 2008, 22:25


Comments:

Posted on 17 Jun 2008, 6:58 by Viking Sailor
Same device naming
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



Posted on 17 Jun 2008, 6:59 by Viking Sailor
Same device naming
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



Posted on 17 Jun 2008, 11:08 by tempestuous
kernel config for wifi
I just posted some information regarding kernel configuration for wifi in the (older) "Advance notice: 2.6.25.6 kernel" Developer section, and wanted to make sure this information is seen.


Posted on 17 Jun 2008, 18:49 by Dougal
udev
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.).


Posted on 17 Jun 2008, 20:41 by coolpup
udev 124
Latest version released 11th June.
http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/


Posted on 18 Jun 2008, 13:33 by BarryK
Re: rt2500usb and rt73usb
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.


Posted on 18 Jun 2008, 13:37 by BarryK
Re: rt2500usb and rt73usb
And looking at how it all works theoretically, I think that if you simply blacklist either rt2500usb or rt73usb using the BootManager gui or directly edit MODULESCONFIG, then the other will still load. But I haven't confirmed that yet.


Posted on 18 Jun 2008, 16:59 by Dougal
Re: rt2500usb and rt73usb
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...


Posted on 18 Jun 2008, 23:37 by BarryK
Re: udevtrigger
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.