iwlwifi.4: add a note on how to bootstrap firmware files

[bz]

Summary

In case someone ends up without any networking and no firmware files
add short instructions on how firmware can be bootstrapped manually.
This was prompted by PR287393 and D50777 during the 14.3-RELEASE days
after firmware was removed from the stable/14 and only available via
ports/package/fwget.

Sponsored by: The FreeBSD Foundation
MFC after: 3 days

[ziaee]

Warner asked about reducing boilerplate in manuals. I wonder if we can put this in intro(4). I'm working on something and will tag you when I get closer.

[bz]

In D50791#1159833, @ziaee wrote:

Warner asked about reducing boilerplate in manuals. I wonder if we can put this in intro(4). I'm working on something and will tag you when I get closer.

intro.4 is definitively not the place for this bit.

I am tagging @imp so he sees this comment as I have no idea where the original request was and what it was about.

I started with a simple bit initially but most of this "boiler plate text" became needed as almost all came out of PRs; it's also hard that the old way we did things has been overcome and it's done differently now and that's it. Frankly we told people for almost two decades to load drivers and firmware in loader and firmware was in base and was a .ko; it's hard to un-teach them; no matter how often you say it and post it to various mailing lists.

I agree that I'd love nothing of this in the SYNOPSIS (also not half that is there currently and I still don't know why we have to tell users how to compile kernels to get a feature or what to put in loader (anymore) or why we explain up to 4 ways these days that can possibly result in the same; it's more like "we don't know or don't agree the way our system should work and be used?).

The files section seems fine to me for the moment. I also agree that once linuxkpi_wlan is in ( D50790 ) half of the LinuxKPI 802.11 introduced bits can all go there and a simple .Xr with a sentence "see there" can do; that's why I started putting that together given we are dealing with 3 (and more coming) LinuxKPI 802.11 drivers now so redundancy can be factored out.

But I'd really prefer having the detailed repetitive text in each manual than nothing or no updates at all.

[ziaee]

I still don't know why we have to tell users how to compile kernels to get a feature or what to put in loader (anymore) or why we explain up to 4 ways these days that can possibly result in the same; it's more like "we don't know or don't agree the way our system should work and be used?).

Synopsis in every other section displays all the ways it can be used. Lots of our users build source, or use the source as a toolkit to build appliances, and how to build a driver in (or not) is a super important use-case.

But I'd really prefer having the detailed repetitive text in each manual than nothing or no updates at all.

Agree, of course!

[imp]

Yea, my worry. about the repeats I talked to @ziaee about was in DESCRIPTION which needs to be shorter. This is OK to be repeated since we don't have a good place to describe it and this is relatively short and the URL is stable.