On Tue, Jan 20, 2009 at 2:37 PM, Greg KH <greg@xxxxxxxxx> wrote: > On Tue, Jan 20, 2009 at 05:08:10PM -0500, Kyle McMartin wrote: >> >> *sigh* I don't know, and don't really want to argue about it. ;-) People >> with backports are pretty much always going to get screwed. What's the >> use case for wireless-testing backports? bugfixes or new features? Could >> we improve the stable process to help wireless stuff get into 2.6.$(x-1) >> more easily so this won't happen in the future? > > I don't think we want to start adding entire new drivers to the -stable > releases, which is what the wireless backport stuff is for, right? Amongst a good amount of other things, yes, getting new drivers is one reason for it. compat-wireless allows users of stable series to get bleeding edge updates on the wireless subsystem. Sometimes this may mean even non-oops fixes to drivers or mac80211 which may be too big to be merged into the stable release series. Basically anything that John maintains on his wireless-testing tree get pulled into the compat-crap except the ancient drivers. Another reason for it is that if you want a bleeding edge mac80211 driver, say foo you will also need bleeding edge mac80211 and cfg80211 and since iwlwifi and ath9k drivers depend on mac80211 and cfg80211 as well for example, so we just provide backport work for all mac80211 drivers. This should prevent vendors from doing nutty things like pushing their own version of mac80211, say foo_mac80211, for their own drivers which can cause divergence and patch hogging through unintended forks. >That > would really be adding new features, which is not the goal. Sure. 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
