On Saturday, July 20, 2013 02:34:58 PM Kay Sievers wrote:
> On Sat, Jul 20, 2013 at 1:47 PM, Kay Sievers <kay@xxxxxxxx> wrote:
> > On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
