On Mon, 3 Mar 2008, Matt Fleming wrote:
On Mon, Mar 03, 2008 at 09:43:25AM +0000, Stephen Borrill wrote:I think we could do with restructuring ath and contrib/dev/ath so that an alternative HAL and (if necessary) a struct translatation layer can be specified. This means that we could specify a different HAL (the HAL in your patch requires has the relevant struct re-arranged) in a kernel config file (in a similar way to specifying a different vesafs splashscreen), e.g. OPTIONS ATH_HAL_PATH="contrib/dev/ath_eee"Whilst I can understand your concern, I'm not sure we should be encouraging multiple HALs to be in the tree at once. Keeping the ath code up to date is pain enough without introducing extra maintenance costs of having more than one (non-backwards compatible) versions of it.
I wouldn't say that it's encouraging it. Atheros clearly have no qualms in releasing incompatible HALs and at the moment, I can't use the same tree to build kernels for standard in-tree ath devices as well as for my EeePC.
This wouldn't be introducing extra versions to maintain in the tree. It would be allowing someone who had an extra, non-compatible version to drop it in without causing them too much grief.
I'll just say that the latest madwifi release (0.9.4) from 13/2/08 mentions the lack of AR5007 support under "Known Issues" and has a link to the experimental patch for i386. So, I'm assuming that support for this chipset must be in reasonable demand and that it'll appear in a release at some point.
That's good news! -- Stephen