udev: New default rule for autoloading kernel modules matching CPU modalias

udev: New default rule for autoloading kernel modules matching CPU modalias

[Rafael J. Wysocki]

Hi Kay,

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
MODALIAS:

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?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: udev: New default rule for autoloading kernel modules matching CPU modalias

[Rafael J. Wysocki]

On Saturday, July 20, 2013 12:56:54 PM Rafael J. Wysocki wrote:
> Hi Kay,
> 
> 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
> MODALIAS:
> 
> 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}"

That should have been:

ACTION=="add", SUBSYSTEM=="cpu", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"

sorry about the mistake.

> 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?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: udev: New default rule for autoloading kernel modules matching CPU modalias

[Kay Sievers]

On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw@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
> MODALIAS:
>
> 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.

Thanks,
Kay

Re: udev: New default rule for autoloading kernel modules matching CPU modalias

[Kay Sievers]

On Sat, Jul 20, 2013 at 1:47 PM, Kay Sievers <kay@vrfy.org> wrote:
> On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw@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
>> MODALIAS:
>>
>> 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:
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=bf7f800f2b3e93ccd1229d4717166f3a4d3af72f

Thanks,
Kay

Re: udev: New default rule for autoloading kernel modules matching CPU modalias

[Rafael J. Wysocki]

On Saturday, July 20, 2013 02:34:58 PM Kay Sievers wrote:
> On Sat, Jul 20, 2013 at 1:47 PM, Kay Sievers <kay@vrfy.org> wrote:
> > On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw@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
> >> MODALIAS:
> >>
> >> 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:
>   http://cgit.freedesktop.org/systemd/systemd/commit/?id=bf7f800f2b3e93ccd1229d4717166f3a4d3af72f

Many thanks!

Rafael