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

[Adrian Chadd]

On 22 May 2017 at 13:17, John Baldwin  wrote:

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

Oh yeah, I could also do that to reduce POLA. :)

Ok, I'll add that to the TODO list before I submit a review. I'll
rename if_ath to if_ath_drv or something.

-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Warner Losh]

On Mon, May 22, 2017 at 2:17 PM, John Baldwin  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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[John Baldwin]

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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Adrian Chadd]

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.

Thanks!



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"