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

Bug#1029848: hw-detect: decide how to configure firmware support



Package: hw-detect
Severity: important

Hi,


# Context

Quoting the text that was agreed to via the 2022 General Resolution
about non-free firmware:

    We will include non-free firmware packages from the "non-free-firmware"
    section of the Debian archive on our official media (installer images
    and live images).

This means that images built by debian-cd (like netinst) will have main
and non-free-firmware packages available under /firmware, with metadata
under /firmware/dep11, making it easy for hw-detect to:

 - Resolve firmware files (spotted as missing by looking at dmesg) into
   firmware packages (if available), deploy those packages in the
   installer environment, tweak apt-setup's default configuration, and
   install those packages in the target environment.

    → Implemented by check-missing-firmware (detection & deployment in
      the installer environment) and install-firmware hooks (enabling
      apt-setup/non-free-firmware if relevant, installing in target
      environment).

 - Detect firmware packages based on modalias information (in case
   missing firmware didn't trigger lines in dmesg), not deploying them
   in the installer environment, but queuing them for installation in
   the target environment (also tweaking apt-setup's default config).

    → Implemented by install-firmware hooks.

(Implementation detail: There are two install-firmware hooks, one after
base-installer, one before pkgsel.)


# Allowing for main-only

The next sentence of the text that was agreed to is:

    The included firmware binaries will normally be enabled by default
    where the system determines that they are required, but where
    possible we will include ways for users to disable this at boot
    (boot menu option, kernel command line etc.).

I'd like us to determine the following things:
 - the best name for an internal-only template for hw-detect;
 - the best alias for it, to be used e.g. on the Linux command line, to
   save some typing;
 - what values it should support;
 - what semantics should be attached to those values.

Even before working on non-free-firmware integration, there were many
possible combinations. With the ongoing work, we aim at making it easy
for most users to just get a successful installation, and I've proposed
to streamline alternate use cases (see #1029543), so that we can focus
on supporting maybe fewer things, but supporting them well.

hw-detect already has a loop, the concept of searching for firmware on
external media, the concept of asking, etc.

It really doesn't make sense to me to have any kind of per-file,
per-module, or per-package granularity. This would mean many prompts,
possibly with way too many lines (see how many files iwlwifi can
request), and wouldn't really help users make an informed decision.
Extra templates would also mean more work for translators…

Therefore, my current approach would be not to try and implement some
yes/ask/no trichoice as originally envisioned, but to provide users
wanting to avoid firmware altogether a way to do so.


I'm proposing:
 - “hw-detect/firmware” as template for hw-detect;
 - “firmware” or “fw” as an alias for shorter typing (“fw” feels like
   extremely short);
 - “never” value to skip firmware handling altogether, meaning skipping
   both mechanisms mentioned above.

That would leave us a rather important flexibility regarding other
behaviours that we might want to implement, depending on the use cases
that might get identified (#1029543), without having to make a decision
about those (names and associated semantic) right now.

Implementing this (and documenting it in the installation guide) would
make us comply with what was agreed to.


Swift feedback would be appreciated, thanks!


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Reply to: