[Pkg-acpi-devel] acpid module loading
Loïc Minier
lool at dooz.org
Wed Oct 29 16:34:27 UTC 2008
Hi folks
I discussed the module loading issue with Julien Blache on IRC, and his
case was that the default file /etc/default/acpid had the default value
of loading the hardcoded list of default modules to load, but his
self-built kernel had acpid modules built in, and no .ko files to load
at all.
He suggested improved the wording in the default file, and I noticed
additional issues in the init script to enhance / fix it further.
Now some things come to my attention:
- The list of modules which are listed by default in MODULES is
probably obsolete: these modules exist, but what about new modules,
or modules which might be added in the future? e.g. bay, dock, sbs
etc.
- Using a list of modules as the default doesn't play particularly nice
with people who have custom kernels who possibly lack these modules;
of course I could check whether the modules before loading it, but
that would also hide errors of listing bogus or obsolete modules and
seems generally wrong. A better default might be no module.
- The all setting is awful; it includes platform specific modules.
Beside, we completely paper over other interesting modules in other
directories.
- This is all more shell which gets run before acpid is started.
As a result, I'd like to propose dropping module loading entirely from
acpid.init and relying on udev to load modules based on what's present
on the system and not supported by the kernel (current behavior anyway:
the modules are already loaded when the acpid init script starts!).
People can use /etc/modules and modprobe.d blacklists to force or
prevent loading of modules, nothing specific to acpi here.
Perhaps I'm missing something, perhaps there are cases where we want to
keep this facility on upgrades?
What do you think?
If you like, compare lsmod output before and after booting with
MODULES="".
Another open point is why do people get acpid start errors on boot and
not on invoke-rc.d acpid start after boot. No clue here. One guess
could be that acpid starts too early, but this seems weird to me. If
that's the case though, I think we should patch acpid to wait for stuff
to appear instead of failing. I've requested more info to people
seeing this for now.
Thanks,
--
Loïc Minier
More information about the Pkg-acpi-devel
mailing list