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

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.

-- 
John Baldwin