Some ideas regarding hardware detection and the installati..

During installation, and afterwards, there are a few things that could
be improved regarding hardware detection. Here are some ideas I have
on the topic.

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. I've also written a draft system to install debian packages
based on detected PCI and USB hardware. This system have a few flaws.
First of all, some hardware needing kernel modules are not acted on.
For example, to get CPU frequency scaling working, one need to detect
the CPU type and load a few kernel modules. Similar, to enable IPMI,
one need to detect if and which type of IPMI system is present.

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.

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. For this to keep
working when the kernel is upgraded, some system to rebuild the source
when required need to be in place.

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.

In short:

Hardware (PCI, DMI, CPU, USB, etc) mapped do one or more of
- Kernel module name
- X driver name
- Debian package
- Plain package driving the hardware
- Kernel module source package
- mapped to kernel module

Kernel modules mapped to
- Plain Debian package talking to the kernel module

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 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

- Mapping from kernel module to Debian package.
- User space dialog asking if a debian package should be installed.
- System to handle kernel source module packages (aka
module-assistant prepare/build/install).

What are your view on this? I plan to give a talk during DebConf
about these ideas, and wanted to run them past you all to get
feedback.

Friendly,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-boot-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Petter Reinholdtsen <pere.DeleteThis@hungry.com> writes:

[...]
> Hardware (PCI, DMI, CPU, USB, etc) mapped do one or more of
> - Kernel module name
> - X driver name

About X driver would be nice to have fallback options. For example, if
the user has the non-free driver for nvidia this should be choosen
instead of nv but if it's not available, nv should be used.

> 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
>
> - Mapping from kernel module to Debian package.
> - User space dialog asking if a debian package should be installed.
> - System to handle kernel source module packages (aka
> module-assistant prepare/build/install).
>
> What are your view on this? I plan to give a talk during DebConf
> about these ideas, and wanted to run them past you all to get
> feedback.

I'd love to have it in place and I'll probably be able to help on it
from by side.

I also think that before starting work on discover2 more closely we'd
remove discover1 completely from the system and drop their packages
from the archive. This would free us from support more then one
database (even being automaticaly produced using the v2 as origin).

--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio.DeleteThis@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."


--
To UNSUBSCRIBE, email to debian-boot-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org