Re: Loading therm_* modules in d-i on Macs
Am Mit, den 30.06.2004 schrieb Colin Watson um 2:40:
> It'd be rather nice if the new debian-installer could load the
> therm_adt746x or therm_windtunnel modules, and register them so that
> they're automatically loaded by the installed system.
> I can take care of the d-i implementation, but what's the best way to
> decide whether the modules are required? As I see it, there are two
> obvious methods:
> (1) Probe each module unconditionally on powerpc/powermac_newworld,
> and register it in /etc/modules if modprobe exited 0. The modules
> in question check for the required hardware themselves and exit
> -ENODEV if they don't find it.
> Pros: simple; should be effective.
> Cons: brute-force approach; generates spurious errors which will
> probably have to be logged just in case anything real goes wrong;
> won't register the module if it's needed by the hardware but the
> probe failed for some installer-specific reason.
> (2) Take the logic from the respective module *_init functions,
> reimplement it in shell by poking about in /proc/device-tree (I've
> looked at the kernel code and believe this is straightforward),
> and probe and register whatever that says will work.
> Pros: accurate about what should go in /etc/modules, regardless of
> glitches in the installer environment; no spurious errors, only real
> Cons: code duplication, so would have to stay in sync with the
> kernel (although d-i's kernels won't rev very often once we go
> stable); more complex.
I don't really like the idea of special hardware detection code for one
piece of hardware, thus:
(3) If there is a chip on the PCI bus which contains the hardware for
these modules, they can be added to the discover hardware database. See
#256712 for a similar case. This is probably the easiest solution, but
it does not work if these devices can't be detected based on PCI IDs.
(4) Additionally support for detection of devices based on device-tree
nodes could be added to discover. This is probably the most general
> Do any kernel hackers have an opinion here?
Sorry, I don't qualify as kernel hacker, but I'm one of discover1's
> Colin Watson [firstname.lastname@example.org]