Bug#1029848: hw-detect: decide how to configure firmware support
Hey kibi!
On Sat, Jan 28, 2023 at 08:09:58PM +0100, Cyril Brulebois wrote:
>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.
Yup.
>(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;
I was thinking "hw-detect/load_firmware" might be better - we may
want/need more firmware questions yet, so let's leave the namespace
open?
> - “firmware” or “fw” as an alias for shorter typing (“fw” feels like
> extremely short);
I'd just go for "firmware" here; "fw" might be confused with firewall
(I see Andy had a similar thought).
> - “never” value to skip firmware handling altogether, meaning skipping
> both mechanisms mentioned above.
Maybe, yeah. That's probably clearest. Then we'd default to "always".
>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.
Yup, good call. We can extend this more to add the nuanced options
once we've got the basics - let's do it incrementally!
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"C++ ate my sanity" -- Jon Rabone
Reply to: