[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Loading therm_* modules in d-i on Macs

On Thu, Jul 01, 2004 at 02:32:34PM +0200, Gaudenz Steinlin wrote:
> 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
> >     ones.
> > 
> >     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.

You are speaking discover2 here right, since discover1 only supports 1
module per pci id.

> (4) Additionally support for detection of devices based on device-tree
> nodes could be added to discover. This is probably the most general
> solution.

notice that the device-tree will probably in the future be replaced by a
sysfs based solution, so a sysfs probing solution should also be added.

But thenm maybe benh could comment more about this ?


Sven Luther

Reply to: