[systemd-devel] udev: New default rule for autoloading kernel modules matching CPU modalias

Kay Sievers kay at vrfy.org
Sat Jul 20 05:34:58 PDT 2013

On Sat, Jul 20, 2013 at 1:47 PM, Kay Sievers <kay at vrfy.org> wrote:
> On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
>> After a recent change present in 3.11-rc1 there is a driver, called processor,
>> that can be bound to the CPU devices whose sysfs directories are located under
>> /sys/devices/system/cpu/.  A side effect of this is that, after the driver has
>> been bound to those devices, the kernel adds DRIVER=processor to ENV for CPU
>> uevents and they don't match the default rule for autoloading modules matching
>> DRIVER!="?*", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"
>> any more.  However, there are some modules whose module aliases match specific
>> CPU features through the modalias string and those modules should be loaded
>> automatically if a compatible CPU is present.  Yet, with the processor driver
>> bound to the CPU devices the above rule is not sufficient for that, so we need
>> a new default udev rule allowing those modules to be autoloaded even if the
>> CPU devices have drivers.
>> On my test systems I added the following rule for that:
>> ACTION="add", SUBSYSTEM=="cpu", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"
>> in a separate file, but I'm not a udev expert, so I guess it may be done in a
>> better way.
>> Can you please consider adding such a rule to the default set of udev rules?
> The DRIVER!="?*" is an optimization which made a huge difference at
> the time we called out to /sbin/modprobe from udev rules and all the
> devices which already had a driver would not cause needless execution
> of the rather expensive modprobe binary.
> This obviously can't do the right thing for the completely generic,
> not bound to a driver-state, CPU modaliases when they have a driver
> now. :)
> These days we load the entire kmod modalias database into the udev
> process, and lookup what we need to load and load the module from
> within the udev worker process. It could be, that the optimization is
> not measurable on today's systems, if that's the case I'll remove it,
> which would be the simplest and most future proof option. Otherwise
> I'll add the CPU specific rule.
> I'll find that out and let you know.

I cannot see any measurable difference here that justifies that
optimization, so I removed it:


More information about the systemd-devel mailing list