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. WarnerReceived 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