Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:38369 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753032Ab0KUAcJ convert rfc822-to-8bit (ORCPT ); Sat, 20 Nov 2010 19:32:09 -0500 MIME-Version: 1.0 In-Reply-To: References: <20101118164552.GC2855@kroah.com> Date: Sun, 21 Nov 2010 08:32:05 +0800 Message-ID: Subject: Re: Challenges with doing hardware bring up with Linux first From: Adrian Chadd To: "Luis R. Rodriguez" Cc: Greg KH , linux-kernel@vger.kernel.org, linux-wireless , David Miller , "John W. Linville" , Stephen Hemminger , "Perez-Gonzalez, Inaky" , Charles Marker , Jouni Malinen , Kevin Hayes , Zhifeng Cai , Don Breslin , Doug Dahlby , Julia Lawall Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 19 November 2010 00:53, Luis R. Rodriguez wrote: >> Also, please review the past multi-os driver initiatives that have >> sprung up over the years (about 1 every 10 years it seems). ?Please >> learn from the past as to why those have failed every single time, and >> why we don't want to even try to do that again. > > :-) thanks, just testing waters to see what's possible and what > direction to focus more on. Being involved atm in the "re-multi-OS'ing" of ath code (ie, merging some ath9k bits and pieces back into FreeBSD's HAL), I really appreciate how the bulk of the hardware-fiddling bits are OS agnostic. There's some messiness surrounding the 802.11 stack flags (which the FreeBSD HAL "indirects" via HAL flags, hiding away some of the net80211 internals) but a lot of the net80211 stuff is still tightly integrated with the HAL. There's some platform specific stuff in hardware twiddling functions (eg "am I a 40mhz channel? Am i a 2ghz channel") but so far it's been straightforward to translate the macros. Now that I've just begun testing (what seems like!) functioning 11n TX/RX in my HAL, I plan on starting to merge in more ath9k related driver code in. I'll provide some more feedback to the ath9k-devel list as I do this. I'm hoping that large chunks of the hardware related code (eg AR9002 calibration) can be thrown in with very minor changes. But so far, I have this to say: * decoupling the hardware twiddling stuff from OS/802.11 stack specific stuff is helpful; * some of the base types are different (eg integer type layout, bool, etc), but that's relatively straightforward to merge over; * keeping the bits that need locking in "higher level" files (ie, separate from hardware twiddling as much as possible) is also helpful. * trying to make the actual interface related code (eg "if_ath.c" in FreeBSD; it's been broken out in ath9k) platform agnostic is likely very difficult and a path to the parent posters "fail." Adrian