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

Re: Some ideas regarding hardware detection and the installation system



In general it is a setup I would support, but only for things that are 
rock solid. I mean only when you can be 100% sure that all (or at least a 
vast majority) owners of the hardware will want that feature _and_ that 
the feature will really work on all hardware it is installed on.

On Saturday 21 April 2007 12:56, Petter Reinholdtsen wrote:
> At the moment, we have a system in place to load kernel modules
> depending on the PCI (and USB) hardware detected during installation
> and boot.

Just an observation: this is extremely i386/amd64 centered! There are 
other busses etc. out there...

> Second, there is a maintenence problem as the mapping from PCI device
> to debian package sometimes is the wrong one.  Most packages support
> devices (aka kernel modules), and not PCI devices.  For instance RAID
> administration tools support one or more kernel module, and the kernel
> module support one or more PCI devices.

I see a few other challenges:
- how to gather and maintain the "mapping" data in a reliable fashion
- how do you make sure that packages/drivers are not installed on a too
  broad range of hardware

The second issue possibly requires an example: user A reports that his 
hardware works better with package X; a mapping is implemented that 
installs it on A's hardware; user C has hardware which also matches the 
mapping, but on his system the package is useless or breaks the system.
This is a problem for example on different models of e.g. the same laptop 
series.

I see these issues as by far the biggest challenges for implementation of 
such a scheme.

> Third, some hardware is supported by kernel modules which are for
> various reasons only distributed as source packages.  When such
> hardware is detected, the source package should be automatically
> installed and the kernel module built and installed.

Do you want to include support for non-free in this? If you do, there 
should be a very good definition of what can and cannot be supported 
based on licence requirements. Users should IMO also always give an 
explicit OK before anything from contrib or non-free is installed.

This touches on a BoF/workshop I will be holding at Debconf about 
supporting firmware and non-free drivers in D-I.

> Last, one do not only want to detect and act on hardwrae during
> installation and boot.  If I connect a USB scanner, I would like the
> Debian system to detect it and suggest to install the drivers required
> to get the scanner working.

Bad example? AFAIK most scanners don't need any drivers, just sane.

> In short:
>   Hardware (PCI, DMI, CPU, USB, etc) mapped do one or more of
>     - X driver name

Is that still needed with the way X.Org is developing (except for 
installing some non-free packages perhaps)?

>   Suggested Debian package should be installed automatically during
>   installation, and trigger some user/admin dialog asking if the
>   driver should be installed after installation.

I don't understand this. Installing a Debian package often means that it 
will be active automatically, and IMO that is how it should be. So the 
question should be asked _before_ the package is installed: "do you want 
this service or not".

> I suspect the discover v2 package might be a good base to implement
> this, as it already support mapping from various hardware types to
> kernel module, X driver and Debian package.  The missing parts are

AIUI the X Strikeforce plans to stop using discover for hardware detection 
sometime before lenny.

>  - System to handle kernel source module packages (aka
>    module-assistant prepare/build/install).

Have you seen Manoj proposal for kernel-package (d-kernel list May 1st)? 
That introduces hooks where you could drop in scripts to do this. It's 
currently uncertain if Debian kernels will keep using kernel-package, but 
I'd expect alternatives to implement the same structure.

Cheers,
FJP

Attachment: pgpaqfSBkzF1S.pgp
Description: PGP signature


Reply to: