Hi,
this will most likely be unpopular, but it was a thing that needed to
be done to make mac80211 tree manageable again.
I rebased all mac80211 patches which are not in vanilla. Now, mac80211
tree is solely based on vanilla and has the following branches:
- up-2.6 - this is a branch with patches I'd like to push to vanilla.
It contains, among other things, Johannes' restructuring patches. I'll
send a pull request later today.
- up-dev - a branch based on up-2.6 with all mac80211 patches currently
in wireless-dev. See below.
- master - a branch with the newest stuff. Currently the same as up-dev.
Creating the up-dev branch meant modifying all mac80211 patches in
wireless-dev, as they sit on top of Johannes' restructuring patches
now. When I was in it, I merged 11n and WMM patches with later fixes. I
also moved a bunch of patches currently in wireless-dev only before 11n
and WMM patches (merging parts of them that affected 11n and WMM
patches directly into them) so they can be pushed upstream.
All mac80211 patches submitted in past few days were modified to apply
after restructuring and applied to up-2.6 or up-dev branch as
appropriate.
I started to do the same with cfg80211 and nl80211 patches but it
turned out that many cfg/nl80211 commits overwrite each other as the
interface was evolving and being rewritten. So I decided to throw away
the history and make a patch (surprisingly, it's quite a nice and
relatively small patch in the end) that brings cfg80211/nl80211 to the
state in which it was when mac80211 was merged to vanilla. Patches that
were committed afterwards are committed separately on the top of it.
What are the advantages?
- Johannes' restructuring patches go in.
- We have patches prepared for merging of wireless-dev into vanilla.
- mac80211 patches can go to vanilla and will appear automatically and
correctly in wireless-dev.
What I'm proposing to do now?
- Throw away current wireless-dev and start it from scratch from the
current vanilla.
- Apply patches from up-dev branch of mac80211 tree.
- Apply all drivers. That's a bit tricky and I'm aware that some people
won't agree but I think it's easiest to apply them as one big patch
for each (that's the form in which they will be submitted to vanilla
anyway). They have been moved out of mac80211 directory recently so
perhaps it's a good time to do that. I can help with creating such
patches.
[In fact, I'd like more another approach but I'm not sure how feasible
it is: apply mac80211 drivers to a separate branch than mac80211 in
wireless-dev and pull both of them into a common branch. That way I'd be
able to rebase mac80211 tree to keep mac80211 patches always on the top
(and modify them gradually as fixes, especially to 11n and WMM,
appear). The big disadvantage is that pulling from wireless-dev would
become much harder.]
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
Jiri Benc wrote:
> What I'm proposing to do now?
> - Throw away current wireless-dev and start it from scratch from the
> current vanilla.
> - Apply patches from up-dev branch of mac80211 tree.
> - Apply all drivers. That's a bit tricky and I'm aware that some people
> won't agree but I think it's easiest to apply them as one big patch
> for each (that's the form in which they will be submitted to vanilla
> anyway). They have been moved out of mac80211 directory recently so
> perhaps it's a good time to do that. I can help with creating such
> patches.
Do we really need two git trees in the future? And do we need all
those different branches in a public tree?
I suggest that we go back now to a single wireless tree, that
should have only those three branches:
master - latest tree put together by John
up - tree with patches going into mainline
up-2.6.x.y - bug fixes against last released mainline
Will John have more branches in its private tree? Sure! Will the
wireless developers have their own public trees? Certainly! But I
really question the value of two wireless trees with a larger
number of branches.
--
Uli Kunitz
Hi Jiri,
> this will most likely be unpopular, but it was a thing that needed to
> be done to make mac80211 tree manageable again.
Why unpopular? The general reaction I've seen (and I second) was
"awesome" :)
> Creating the up-dev branch meant modifying all mac80211 patches in
> wireless-dev, as they sit on top of Johannes' restructuring patches
> now.
Whee :)
> I started to do the same with cfg80211 and nl80211 patches but it
> turned out that many cfg/nl80211 commits overwrite each other as the
> interface was evolving and being rewritten. So I decided to throw away
> the history and make a patch (surprisingly, it's quite a nice and
> relatively small patch in the end) that brings cfg80211/nl80211 to the
> state in which it was when mac80211 was merged to vanilla. Patches that
> were committed afterwards are committed separately on the top of it.
Sounds good to me. It was changing quite a bit at the time, yeah. It'll
probably continue to do so if somebody works on it again...
> What are the advantages?
> - Johannes' restructuring patches go in.
> - We have patches prepared for merging of wireless-dev into vanilla.
> - mac80211 patches can go to vanilla and will appear automatically and
> correctly in wireless-dev.
Cool
> [In fact, I'd like more another approach but I'm not sure how feasible
> it is: apply mac80211 drivers to a separate branch than mac80211 in
> wireless-dev and pull both of them into a common branch. That way I'd be
> able to rebase mac80211 tree to keep mac80211 patches always on the top
> (and modify them gradually as fixes, especially to 11n and WMM,
> appear). The big disadvantage is that pulling from wireless-dev would
> become much harder.]
Actually, that just means that John has to pull both mac80211 and
drivers into master everytime he updates one of them. Or something.
Good job!
johannes
On Tue, Jul 31, 2007 at 08:13:24PM -0400, Daniel Drake wrote:
> Jiri Benc wrote:
> >- up-2.6 - this is a branch with patches I'd like to push to vanilla.
> > It contains, among other things, Johannes' restructuring patches. I'll
> > send a pull request later today.
>
> John, will you be pulling this into wireless-dev anytime soon? I have
> some further mac80211 development work to do but am not sure which tree
> I should be working on. Also my patch titled "don't allow scanning in
> monitor mode" has got lost somewhere and I'm not sure whether it would
> be beneficial for me to re-submit based on Jiri/Johannes' restructuring.
It isn't lost, I've got it. I haven't been in a hurry with
2.6.24-destined patches, although I suppose I could have put it in
wireless-dev. As you know, of course, that exact state of wireless-dev
is uncertain.
I do plan to adopt Jiri's git work. I'm sorry I haven't got it
prepared yet. It might be worthwhile for you to reformulate your
patch based on the restructuring.
John
--
John W. Linville
[email protected]
On Tue, 31 Jul 2007 20:13:24 -0400, Daniel Drake wrote:
> Also my patch titled "don't allow scanning in
> monitor mode" has got lost somewhere and I'm not sure whether it would
> be beneficial for me to re-submit based on Jiri/Johannes' restructuring.
It's there,
http://git.kernel.org/?p=linux/kernel/git/jbenc/mac80211.git;a=commit;h=2923882423db52642e9f2fc131972842cfa05e82
Jiri
--
Jiri Benc
SUSE Labs
Jiri Benc wrote:
> - up-2.6 - this is a branch with patches I'd like to push to vanilla.
> It contains, among other things, Johannes' restructuring patches. I'll
> send a pull request later today.
John, will you be pulling this into wireless-dev anytime soon? I have
some further mac80211 development work to do but am not sure which tree
I should be working on. Also my patch titled "don't allow scanning in
monitor mode" has got lost somewhere and I'm not sure whether it would
be beneficial for me to re-submit based on Jiri/Johannes' restructuring.
Thanks,
Daniel