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

Re: My WLI-UC-GNM up crash

[Warner Losh]

The __aligned(8) likely isn't going to do anything. It says that you are 
guaranteeing to the compiler that you'll only ever allocate / cast pointers to 
this data type on a 8-byte boundary. __packed might help, but likely won't 
because that's for on-wire things and anything thing that wasn't already not 
marked packed that should be would already be broken, but broken giving bad 
data, not broken segfaulting.

__aligned(1) is what you want. But that has other performance problems...

Warner

On Jul 28, 2013, at 4:35 AM, Hans Petter Selasky wrote:

 Hi,
 
 Can you try the attached patch?
 
 --HPS
 radiotap.diff___
 freebsd-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-arm
 To unsubscribe, send any mail to freebsd-arm-unsubscr...@freebsd.org

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org

Re: My WLI-UC-GNM up crash

[Warner Losh]

Aren't structures already aligned to 4 bytes when placed inside other 
structures (unless marked __packed)?

Warner

On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrote:

 As long as that results in the radiotap structures being 4 or 8 byte
 padded when it's embedded in the softc - then yes, indeed.
 
 Xiao, can you try?
 
 
 -adrian
 
 On 28 July 2013 03:35, Hans Petter Selasky h...@bitfrost.no wrote:
 Hi,
 
 Can you try the attached patch?
 
 --HPS
 ___
 freebsd-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-arm
 To unsubscribe, send any mail to freebsd-arm-unsubscr...@freebsd.org

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org

Re: My WLI-UC-GNM up crash

[Warner Losh]

On Jul 29, 2013, at 11:58 AM, Hans Petter Selasky wrote:

 The aligned will make sure that the structure gets padded properly to the 
 size specified. Only on ARM/MIPS etc, structures get automatically aligned 
 according to the element in the structure requiring the greatest alignment.

I'd turn this around and say only on x86 do structures not get aligned this 
way. On any riscy architecture, unaligned accesses are expensive, which is why 
the ABI there mandates this.

 I've test-compiled the USB WLAN drivers, and the aligned makes a difference. 
 The problem is that the radiotap header skews some following elements, so 
 that they are no longer aligned. The radiotap header itself is packed, and 
 this is not a problem.

This suggests a bigger problem. How is the radiotap header being popualted? Is 
it by DMA or programmatically? If by DMA then we have cache line sharing, which 
is bad. If by program, why is it packed to start with?

Warner

 --HPS
 
  
 -Original message-
  From:Warner Losh i...@bsdimp.com
  Sent: Monday 29th July 2013 17:04
  To: Adrian Chadd adr...@freebsd.org
  Cc: Hans Petter Selasky hans.petter.sela...@bitfrost.no; freebsd-arm 
  freebsd-...@freebsd.org; freebsd-wireless@freebsd.org
  Subject: Re: My WLI-UC-GNM up crash
  
  Aren't structures already aligned to 4 bytes when placed inside other 
  structures (unless marked __packed)?
  
  Warner
  
  On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrote:
  
   As long as that results in the radiotap structures being 4 or 8 byte
   padded when it's embedded in the softc - then yes, indeed.
   
   Xiao, can you try?
   
   
   -adrian
   
   On 28 July 2013 03:35, Hans Petter Selasky h...@bitfrost.no wrote:
   Hi,
   
   Can you try the attached patch?
   
   --HPS
   ___
   freebsd-...@freebsd.org mailing list
   http://lists.freebsd.org/mailman/listinfo/freebsd-arm
   To unsubscribe, send any mail to freebsd-arm-unsubscr...@freebsd.org
  
  

___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org

Re: Offer: I'm going to automate FreeBSD-wireless AP builds, but what I need is hardware..

[Warner Losh]

On Apr 20, 2013, at 9:27 PM, Adrian Chadd wrote:

 Hiya,
 
 Now that the missing piece of support is almost done (hostap mode
 powersave/pspoll support) I'm going to move onto the next thing -
 doing automated FreeBSD builds for people to run on AP equipment.
 
 What I have that is publicly available:
 
 * Ubiquiti Routerstation
 * Ubiquiti Routerstation Pro
 * D-Link DIR-825
 * TP-Link TL-WR1043nd
 
 .. and lots of Atheros reference designs that are almost-but-not-quite
 what people actually ship. :-)
 
 I've had plenty of people ask me if I can supply builds for their
 various wifi APs so they don't have to build the software themselves.
 
 So here's my offer - if you'd like me to add to the above list of
 hardware that I'll do automatic builds for, I'll need some hardware.
 If you send me a supported AP, I'll snaffle the relevant bits from
 linux/openwrt/atheros and stick it into my build list.
 
 The 'supported hardware list:
 
 * .. openwrt runs on it. :-)
 * anything with an Atheros MIPS24k core - AR71xx, AR913x, AR724x, AR933x
 * Atheros 802.11n wifi
 * At least 32MB RAM
 * At least 8MB of flash
 
 The last two are annoying - yes, we could fit inside 16MB RAM and 4MB
 flash, but we need a lot more work done on the FreeBSD side. So I'm
 setting the minimum bar there.
 
 If you don't know what hardware is in the unit - take a look at the
 openwrt wiki.
 
 I'm just wrapping up some automated build scripts now and I expect to
 start building test images in the next week or so.

That sounds cool, but do we need another st of scripts to build images? What 
does yours give that others don't :)

Warner
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org