On Wed, Feb 02, 2011 at 02:09:26PM -0800, Luis Rodriguez wrote: > Increasing audience. > > On Wed, Feb 02, 2011 at 01:27:10PM -0800, Zhao, Shanyu wrote: > > Hi Luis, > > > > Thank you for the quick response. When I say USB, I didn't mean USB network > > drivers, I'm talking about USB host/device controller drivers or gadget > > drivers. For example, we can backport USB3 support to, say, 2.6.28. > > > > From what I understand, I can add any driver to your compat-wireless tree and > > build it the same way as other wireless drivers. Am I right? > > That's right. > > > Then your tree should really be called compat-drivers. :) I'm not sure if > > you're welcoming non-network related drivers. > > I see the value in providing backport support for not just 802.11 but > other drivers as well. Today compat-wireless backports: 802.11, Bluetooth, > Ethernet, and because some of these drivers require larger components like > the Sonic Silicon Backplane (ssb) for b44 an b43, it means it also backports > a bit more. > > I would be hesitant to allow for more drivers to go into compat-wireless if > it was not for the fact that I am actually getting a good slew of contributions > from other members and this helps me maintain this thing. So -- if are willing > to upkeep backport support for other non 802.11/Bluetooth/Ethernet drivers > in compat-wireless, I gladly welcome the changes. > > > What's the routine of maintaining a driver in compat-xxx? > > I use linux-next.git to suck out drivers and we apply backport stuff to them > during a kernel development cycle. Generic kernel backport crap goes into the > compat.git tree: new request_firmware API got added recently, so we have a > compat_firmware_class, and respective udev changes. Things that are specific to > the stuff you are backport get stuffed into the compat-wireless.git tree. > Typically this involves patches which apply onto the linux-next.git code we > suck out which we cannot backport through compat.git. Preference is to always > push for compat.git changes over some nasty patch with ifdefs, and only leave > as a last resort uses patches on compat-wireless. The patches in > compat-wireless patches/ directory are sorted by the API change that requires > patching the kernel. This helps add support for new drivers that we want to add > to compat-wireless. The offsets for patches are adjusted regularly through some > Quilt magic that Hauke Mehrtens implemented (./scripts/admin-update refresh). > When crap fails to compile we either remove the driver or fix it. PCMCIA for > example was deemed as pointless to backport on our last Linux wireless summit > so there is some desire to remove all that crap but so far no one has so we go > on with it. > > > Do you periodically > > run compat-xxx along with compat and latest kernel (mainstream) and fix any > > patch that no longer applies cleanly? How about stable kernel like 2.6.35.3? > > How do you align compat, compat-wireless and mainstream kernel? > > Apart from bleeding edge code from linux-next.git, I also make branches for > both compat-wireless.git and compat.git for each stable kernel release. This > follows the model H. Peter Anvin has implemented in the maintenance of the > linux-2.6-allstable.git tree. When a branch there say on linux-2.6.36.y gets a new > extraversion and I know it has some juicy stuff I update my linux-2.6.36.y trees > as well and make a release through the stable compat-wireless page: > > http://wireless.kernel.org/en/users/Download/stable/ > > It used to be that we only made bleeding edge releases based on linux-next.git but > that proved too unstable for some users. > > Check out the ChangeLog for the latest stable compat-wireless, I have automated > the ChangeLog release to include the git shortlog of all components involved > between each stable kernel release. > > The next question you have which you have not asked me yet is how do you address > cherry picks or patches not upstream. For that I have added three directories, > they are self described by their names with a URL to their respective README: > > * linux-next-cherry-picks/ http://bit.ly/h76wrL > * linux-next-pending/ http://bit.ly/eY4aCY > * pending-stable/ http://bit.ly/dOsi7J > > What I really need to get to at some point is to use implement a > menuconfig thingy, we already drag the Kconfigs in but use config.mk for > makefile/dependency mapping. Patches welcomed. BTW one idea I have as of recent is to consider using Hudson for automatic build testing for compat-wireless but haven't yet mucked with it. Eventually this will be more and more important as time goes by and we support older kernels. The goal is to at the *very least* always support down to the last stable 2.6 kernel listed on kernel.org, today that is 2.6.27 and I think its a safe promise to commit to backporting *at least* to that kernel. We go beyond 2.6.27 though today. [1] http://en.wikipedia.org/wiki/Hudson_(software) Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
