Re: [rfc] breaking out if_ath into ... lots of modules

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 22 May 2017 14:44:06 -0600
On Mon, May 22, 2017 at 2:17 PM, John Baldwin <jhb_at_freebsd.org> wrote:

> On Monday, May 22, 2017 12:29:15 PM Adrian Chadd wrote:
> > Hi,
> >
> > I've been putting this off for a few years, but now I've reached a
> > point where I kind of need to do this.
> >
> > The TL;DR is this - I'd like to break the ath driver /back/ out into
> > separate modules, and then have them be run-time loadable. It's part
> > for space savings, and part for the upcoming ath10k work where I need
> > to reuse the regulatory EEPROM code.
> >
> > The reason? I can't easily build a modular ath driver without
> > compiling in /everything/. For the AR933x/AR934x embedded platforms
> > which don't require the previous HAL chipset code, this is almost
> > 800kbyte extra binary code in the kernel that doesn't ever get run.
> > For earlier boards (say the AR9280 embedded boards), it's roughly
> > 600kbyte of AR9300 HAL code that doesn't ever get run.
> >
> > I have a patchset (which I'll push up soon) which turns if_ath into:
> >
> > * if_ath - only the driver;
> > * (if_ath_pci / if_ath_ahb stay the same);
> > * ath_hal - only the shared, global HAL code (osdep routines, HAL
> > core, regulatory code);
> > * ath_rate - the ath rate control code (either sample, amrr, onoe);
> > * ath_dfs - just dfs_null for now, but this will eventually be a radar
> detector;
> > * ath_hal_{ar5210,ar5211,ar5212,ar5416,ar9300} - the individual chipset
> HALs.
> >
> > Now, I'm thinking of further breaking out ar5416 into
> > {ar5416,ar9001,ar9002} just to save space for the embedded builds
> > (like AR9103/AR9106 which some people still use) but that can come
> > later.
> >
> > There's no AR2312/AR5312 11abg + MIPS4k core support in FreeBSD, so
> > I'll go and look at making the AR5312 wifi support work. That'll
> > become another HAL module.
> >
> > On the regulatory side, I then need to divorce the EEPROM regulatory
> > code from ath_hal and turn /it/ into a separate module because,
> > surprise, the ath10k 11ac hardware uses the same regulatory code. I'll
> > do this particular step later.
> >
> > What does this mean?
> >
> > * If you compile up a kernel with everything in it, nothing will
> > change - hopefully this is the majority of users;
> > * If you compile a modular kernel or embedded platform - you need to
> > load ath_hal and the relevant HAL modules before you load if_ath /
> > if_ath_pci otherwise it won't find your hardware.
> >
> > I realise this is a bit of a POLA change, but I'd like to get it into
> > -HEAD before FreeBSD-12 is cut.
>
> Why not have if_ath.ko just be a wrapper module that depends on everything
> like dtraceall.ko?  That would let 'kldload if_ath' and the auto-loading
> code in ifconfig still DTRT.  You could name the "only the driver" module
> ath.ko or some such.
>

I like this a lot. There's much magic in places like netstat and people's
loader.conf files that this solution would preseve that yours would break.

Warner
Received on Mon May 22 2017 - 18:44:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC