Re: Backporting other subsystems on Linux

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

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