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:
pgp61sTyVincN.pgp
Description: PGP signature