[lkml]   [2011]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Backporting other subsystems on Linux
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
> > 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:
> 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/
> * linux-next-pending/
> * pending-stable/
> 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 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, 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.



 \ /
  Last update: 2011-02-02 23:29    [W:0.045 / U:3.292 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site