Re: Backporting other subsystems on Linux

[Luis R. Rodriguez]

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.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/