|
Prev: [PATCH] spi: simple SPI framework
Next: 2.6.16-rc1-mm3
From: John W. Linville on 18 Jan 2006 15:10 First, the news everyone will like. Thanks to the kernel.org team I now have a place to publish a wireless tree: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git The tree there has a number of branches, so many that you need a scorecard... Branches -------- The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus changes I recently sent to Jeff. Those changes are also available on the "upstream-jgarzik" branch, but it is frozen to when I requested Jeff's pull. The tree also has "softmac" and "dscape" branches. The "softmac" branch includes the Johannes Berg softmac code as well as the the BCM43xx driver based upon that code. The "dscape" branch includes the DeviceScape patches from Jiri Benc as well as the BCM43xx driver ported to the DeviceScape stack. The fact that the BCM43xx team has ported their driver to both stacks provides us an excellent opportunity for some objective, "apples to apples" comparisons between the major stacks. I would like to take this opportunity to thank them for taking the trouble to do that work and to make both versions available for comparison. BTW, those trying to actually use the dscape code will want to poke around Jiri's kernel.org directories: http://www.kernel.org/pub/linux/kernel/people/jbenc/ Jiri has some information there that will likely be useful to you. The other branches are for administrative purposes, and can mostly be ignored. Patches ------- Along with bugfixes and enhancements to the current code (which will be targeting the "master" branch), I would like to see driver and stack patches for both the "softmac" and "dscape" branches. I would like to see what is really out there before making a final call on which stack to adopt permanently. If you have an out-of-tree driver which targets either (or both) stacks, please send patches. If you are working on porting an in-kernel driver to one of these stacks (either from the other stack or from its private stack), please send patches. If you have fixes or enhancements pending for either of these stacks, then please send patches. Don't waste any time with your patches. There is good reason to make a decision quickly, and plenty of pressure to do so. Your code could be a significant factor in making that decision. I know that many of you believe that this approach is a bad idea, for a variety of reasons. I find those arguments valid, and even persuasive. The point of this exercise is NOT to push two stacks forward into Linus' kernel. The point is to catalog the true state of affairs and to collect as large a wireless driver codebase as possible. You might think of this as a Domesday Book (http://en.wikipedia.org/wiki/Domesday_Book) for Linux wireless. Summary ------- Hopefully the act of collecting these patches will also allow the less motivated among us to have a chance to evaluate the stacks involved. There are bound to be some wise and skilled kernel hackers out there that are just a little too busy to track-down all these patches themselves... :-) I appreciate all the commentary and ideas expressed over the past couple of weeks. I also think the driver writers are doing a good job with what they've been given so far. I hope this helps to bring the driver guys in out of the cold, and to put some weight behind the discussions of where we need to go. Thanks, John -- John W. Linville linville(a)tuxdriver.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: John W. Linville on 18 Jan 2006 15:30 On Wed, Jan 18, 2006 at 09:19:20PM +0100, Michael Buesch wrote: > On Wednesday 18 January 2006 21:06, John W. Linville wrote: > > The tree also has "softmac" and "dscape" branches. The "softmac" > > branch includes the Johannes Berg softmac code as well as the the > > BCM43xx driver based upon that code. The "dscape" branch includes > > the DeviceScape patches from Jiri Benc as well as the BCM43xx driver > > ported to the DeviceScape stack. > > Are you going to keep it synced with our repository? > I think it should be possible to automatically send patches for > every change in our tree to you. I am not 100% sure (but 99%). > I will look at it tomorrow. If you'll send me patches, I'll apply them... John P.S. Please do what you can to make them comply w/ kernel patch posting conventions: http://linux.yyz.us/patch-format.html -- John W. Linville linville(a)tuxdriver.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Buesch on 18 Jan 2006 15:30 On Wednesday 18 January 2006 21:06, John W. Linville wrote: > The tree also has "softmac" and "dscape" branches. The "softmac" > branch includes the Johannes Berg softmac code as well as the the > BCM43xx driver based upon that code. The "dscape" branch includes > the DeviceScape patches from Jiri Benc as well as the BCM43xx driver > ported to the DeviceScape stack. Are you going to keep it synced with our repository? I think it should be possible to automatically send patches for every change in our tree to you. I am not 100% sure (but 99%). I will look at it tomorrow. -- Greetings Michael.
From: Jeff Garzik on 18 Jan 2006 15:40 John W. Linville wrote: > First, the news everyone will like. Thanks to the kernel.org team > I now have a place to publish a wireless tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git > > The tree there has a number of branches, so many that you need > a scorecard... > > Branches > -------- > > The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus > changes I recently sent to Jeff. Those changes are also available on > the "upstream-jgarzik" branch, but it is frozen to when I requested > Jeff's pull. Minor git administrative note... In my trees, the 'master' branch is always vanilla Linus, and I never ever apply my own changes to it. This enables commands such as git diff master..upstream > patch git log master..upstream > log.txt git log master..upstream | git shortlog > shortlog.txt to work as expected. Typically I do not update 'master' unless I am also updating 'upstream' with vanilla Linus changes, in order to avoid screwing up the tree heads and the diff. When I do update 'master' from 'upstream', it is a trivial matter to then pull those changes into 'upstream': git checkout -f upstream git pull . master Regards, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jeff Garzik on 18 Jan 2006 16:00
On Wed, Jan 18, 2006 at 03:48:49PM -0500, John W. Linville wrote: > On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote: > > John W. Linville wrote: > > > >The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus > > >changes I recently sent to Jeff. Those changes are also available on > > >the "upstream-jgarzik" branch, but it is frozen to when I requested > > >Jeff's pull. > > > Typically I do not update 'master' unless I am also updating 'upstream' > > with vanilla Linus changes, in order to avoid screwing up the tree heads > > and the diff. When I do update 'master' from 'upstream', it is a > > trivial matter to then pull those changes into 'upstream': > > Good info...thanks! > > FWIW, I have an "origin" branch that corresponds to Linus' tree. > I think that probably enables the same kind of usage as you noted...? Yep, it doesn't matter what you call it. I avoid 'origin' since a 'git pull' without arguments will automatically update that (and possibly master too). But it's just a name. Any branch with vanilla Linus tree in it will achieve the behavior I described. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |