On 6/13/22 10:37 AM, Bjoern A. Zeeb wrote:
On Mon, 13 Jun 2022, Warner Losh wrote:
On Mon, Jun 13, 2022, 8:28 AM John Baldwin <[email protected]> wrote:
On 6/12/22 11:43 AM, Bjoern A. Zeeb wrote:
The branch main has been updated by bz:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0f7b9777f8f39fbc230b3e1de2f844d9f839adea
commit 0f7b9777f8f39fbc230b3e1de2f844d9f839adea
Author: Bjoern A. Zeeb <[email protected]>
AuthorDate: 2022-06-12 18:35:58 +0000
Commit: Bjoern A. Zeeb <[email protected]>
CommitDate: 2022-06-12 18:35:58 +0000
rtw88: split driver up into a core and pci part
Split the driver up into two modules (if_rtw88_pci.ko and
rtw88_core.ko).
This is in preparation for the hopefully eventually upcoming USB
support
using the same driver core.
Note: this changes the module name to load to if_rtw88_pci.ko
instead of
if_rtw88.ko. If using devmatch(8) everything should stay the same
as
the driver name (used for net.wlan.devices) stays rtw88. If using
kld_list in rc.conf or loader.conf you will need to adjust the name.
Update man page for this.
MFC after: 3 days
This sort of split in a .ko is kind of rare for drivers in the tree that
support
multiple bus attachments. Usually we just lump all the attachments into
the same
.ko. It's true that with the death of ISA, etc. we no longer have as many
drivers
with multiple bus attachments, but the norm has been to include them all
in a
single .ko. Is there a reason you can't follow the normal practice here?
I am not oppsed to one big blob but I wonder if it is "normal practise"
these days?
I honestly didn't think much beyond PCI is in PCI and USB load where I
plug USB in but I couldn't think of many times having both and more
code exposure than needed.
So you made me go and think a bit about it and look into it:
rtwn(4) is split up as "predecessor"; probably also influenced my
above thinking. Upstream has this one written in a way that it can
be split up natively between buses. In theory I this could be split
up into even per-chipset mostly apart from "core" and then one could
even start bundling chipset+fw together as an entity but that didn't
seem like "common practise".
I think the main argument is that this isn't just a few lines of bus
attachment but larger parts of the driver (PCI vs. USB to come) given the
PCI per-chipset files contain tables etc. and is way bigger than the
actual common code (and USB will be fairly small I believe).
-r-xr-xr-x 1 root wheel 308536 Jun 13 13:33 /boot/kernel/rtw88_core.ko
-r-xr-xr-x 1 root wheel 998712 Jun 13 13:33 /boot/kernel/if_rtw88_pci.ko
And I don't neccessarily want to pull in two bus dependencies into the
same driver even if that seems the historical way of thinking; "MINIMAL"
is still a goal we once set out for and a way of thinking and autoloading
does sort things out these days without users having to fiddle anything
in the default case.
Why do I need to load 1M file for PCI on a machine w/o PCI?
Even many SoC boards have PCI, and anything approaching desktop class
will have PCI, so lack of PCI is quite specious. That said, historically
per-bus attachment code was indeed much smaller. OTOH, you can also
selectively include files in the .ko at build-time, e.g. based on
whether or not the base kernel included 'device pci' by checking for
DEV_PCI in KERN_OPTS, something like:
.if ${KERN_OPTS:MDEV_PCI}
SRCS+= if_rtw88_pci.c
.endif
This more closely matches what happens in the kernel where you would have
the sys/conf/files line be 'if_rtw88_pci.c optional rtw88 pci'
Why do we have separate parts for ACPI vs. FDT?
Separate modules just for foo_acpi.c and foo_fdt.c? Those are probably bugs.
Why don't we have NTB support for AMD and Intel and ... together in
one .ko? Why is mac-* not one module? Why are geom part
implementations not one, or why are congestion control protocols, or
ipfw modules separate?
Why do I not get Panasonic, Fujitsu, Toshiba and HP ACPI modules on my
Thinkpad (even same bus attachments)?
This is not the same as these are differently named drivers in most
parts with different user interfaces. However, if you are going to have the
'foo0' interface, we assume that it loaded by 'if_foo.ko'. ifconfig(8)
even has this knowledge baked in.
Or why do we not put all firmware blobs for the same driver in one
file (given firmware 9 can)? Because there is no point in loading
12 firmware images into memory when 1 suffices?
Firmware is not user facing in that it doesn't show up in the UI.
Isn't it actually more common to put things apart these days for
various reasons?
Not for user-facing things. Note that urtwn and rtwn use different
driver names. I'm not sure that was really the best decision and
it is probably worth revisiting it in this case if it's really the
same hardware just with different bus attachments.
I'd tend to argue that time has moved on and making things self-contained
smaller and simpler is a good thing in a too complex world.
So the prior history is that I think ath(4) did this once and it was
a POLA nightmare due to things like ifconfig(8), etc.
--
John Baldwin
