ieee80211.c is just too large to be maintainable. This patch series
splits it up into a few smaller files; it also has a few tiny
buglet-fixes.
Apparently 1 and 8 were too large:
(1)
http://johannes.sipsolutions.net/patches/kernel/all/2007-06-22-09:08/033-split-rx.patch
(8)
http://johannes.sipsolutions.net/patches/kernel/all/2007-06-22-09:08/040-split-out-tx-handlers.patch
johannes
On Fri, 2007-06-22 at 11:09 +0200, Johannes Berg wrote:
> Apparently 1 and 8 were too large:
>
> (1)
> http://johannes.sipsolutions.net/patches/kernel/all/2007-06-22-09:08/033-split-rx.patch
>
> (8)
> http://johannes.sipsolutions.net/patches/kernel/all/2007-06-22-09:08/040-split-out-tx-handlers.patch
I should have mentioned that these also reorder the rx handlers to be in
the same order as they're invoked in which makes reading that code a lot
easier since you can just read it top-down without worrying about
jumping around to find the correct order all the time.
johannes
On 7/11/07, Christoph Hellwig <[email protected]> wrote:
> On Tue, Jul 10, 2007 at 08:35:00PM +0200, Johannes Berg wrote:
> > I don't really see the big problem anyhow. As long as we don't want any
> > patches in upstream that depend on the refactoring we can delay pushing
> > the refactoring upstream. Once we do get patches we can decide to either
> > make two versions of them or at some point push the refactoring upstream
> > as well; problems will only arise if we delay too much pushing patches
> > upstream that are before the refactoring, those would need to be
> > rediffed.
>
> The normal Linux aproach is to push the refactoring as soon as possible.
> That way the other changes have to be rebased once and than you're done
> with it. If you keep the big refactoring in some staging tree porting
> things forth and back will be an endless pain.
This is true but the idea is to try to merge wireless-dev into
wireless-2.6 ASAP. We shouldn't stop wireless-dev tree changes as that
is what we need to help with development. I can only see this helping
us down the road. Jiri -- are you sure? :)
Luis
On 7/17/07, Luis R. Rodriguez <[email protected]> wrote:
> On 7/11/07, Christoph Hellwig <[email protected]> wrote:
> > On Tue, Jul 10, 2007 at 08:35:00PM +0200, Johannes Berg wrote:
> > > I don't really see the big problem anyhow. As long as we don't want any
> > > patches in upstream that depend on the refactoring we can delay pushing
> > > the refactoring upstream. Once we do get patches we can decide to either
> > > make two versions of them or at some point push the refactoring upstream
> > > as well; problems will only arise if we delay too much pushing patches
> > > upstream that are before the refactoring, those would need to be
> > > rediffed.
> >
> > The normal Linux aproach is to push the refactoring as soon as possible.
> > That way the other changes have to be rebased once and than you're done
> > with it. If you keep the big refactoring in some staging tree porting
> > things forth and back will be an endless pain.
>
> This is true but the idea is to try to merge wireless-dev into
> wireless-2.6 ASAP. We shouldn't stop wireless-dev tree changes as that
> is what we need to help with development. I can only see this helping
> us down the road. Jiri -- are you sure? :)
Nevermind... Johannes' patches won't apply anymore, except for the
ones he pinged about for recently...
Luis
On Fri, 22 Jun 2007 00:16:03 +0200, Johannes Berg wrote:
> ieee80211.c is just too large to be maintainable. This patch series
> splits it up into a few smaller files; it also has a few tiny
> buglet-fixes.
I agree. And I like these patches, they make sense.
But: It would make putting changes currently in wireless-dev to upstream a
nightmare. I wouldn't be able to take patches in the form they were
committed anymore and would need to heavily modify them.
Sorry, NAK for now. Let's do that after mac80211 is completely upstream.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
On Tue, 2007-07-10 at 15:34 +0200, Jiri Benc wrote:
> But: It would make putting changes currently in wireless-dev to upstream a
> nightmare. I wouldn't be able to take patches in the form they were
> committed anymore and would need to heavily modify them.
Why? We could just mirror these changes to upstream too.
johannes
On Tue, Jul 10, 2007 at 08:35:00PM +0200, Johannes Berg wrote:
> I don't really see the big problem anyhow. As long as we don't want any
> patches in upstream that depend on the refactoring we can delay pushing
> the refactoring upstream. Once we do get patches we can decide to either
> make two versions of them or at some point push the refactoring upstream
> as well; problems will only arise if we delay too much pushing patches
> upstream that are before the refactoring, those would need to be
> rediffed.
The normal Linux aproach is to push the refactoring as soon as possible.
That way the other changes have to be rebased once and than you're done
with it. If you keep the big refactoring in some staging tree porting
things forth and back will be an endless pain.
On Tue, 2007-07-10 at 13:12 -0400, John W. Linville wrote:
> > > which is not upstream. Merging it upstream would mean taking the patch from
> > > wireless-dev git and manually modifying it to fit a new structure. And we
> > > have a bunch of such patches which should go to 2.6.24 (yes, I really
> > > mean .24). Perhaps I'm lazy, but I'd like to avoid that. It's going to be a
> > > lot of unpleasant work even without this...
> Hmmmm...maybe. But, what would have been the perfect trigger to
> merge it? At least now we have less bits out-of-stream and have to
> do less API-chasing with every new kernel.
Dunno. I guess I didn't expect Jiri to block any patches based on the
fact that we have two trees now.
I don't really see the big problem anyhow. As long as we don't want any
patches in upstream that depend on the refactoring we can delay pushing
the refactoring upstream. Once we do get patches we can decide to either
make two versions of them or at some point push the refactoring upstream
as well; problems will only arise if we delay too much pushing patches
upstream that are before the refactoring, those would need to be
rediffed.
Oh well. Do what you feel is easiest. This is the second or third time
I've been burnt with significant mac80211 cleanups so I guess I'll just
learn my lesson here.
johannes
Johannes Berg wrote:
> On Tue, 2007-07-10 at 16:29 +0200, Jiri Benc wrote:
>
>> But even if it can be applied upstream, it doesn't solve anything. Imagine
>> a patch which was merged into wireless-dev before this restructuring and
>> which is not upstream. Merging it upstream would mean taking the patch from
>> wireless-dev git and manually modifying it to fit a new structure. And we
>> have a bunch of such patches which should go to 2.6.24 (yes, I really
>> mean .24). Perhaps I'm lazy, but I'd like to avoid that. It's going to be a
>> lot of unpleasant work even without this...
>
> Which all goes to say that pushing mac80211 for .22 was too fast.
Definitely not too fast.
The fact that people are using mac80211 from Linus' kernel tip is *GREAT*.
We have a lot of users now that can pull Linus' tree and use iwlwifi and
they no longer have to figure out how to patch a kernel, or pull from
wireless-dev.
The fact that people are working on making patches against mac80211 is
exactly what mac80211 needs. By pushing at least some bits out we now
have a larger audience testing, contributing, and working on making
mac80211 better.
James
On Wed, Jul 11, 2007 at 09:34:50AM -0700, jketreno wrote:
> Johannes Berg wrote:
...
> >Which all goes to say that pushing mac80211 for .22 was too fast.
>
> Definitely not too fast.
>
> The fact that people are using mac80211 from Linus' kernel tip is *GREAT*.
> We have a lot of users now that can pull Linus' tree and use iwlwifi and
> they no longer have to figure out how to patch a kernel, or pull from
> wireless-dev.
...
Which reminds me: Will the driver make it into .23?
ciao
Joerg
--
Joerg Mayer <[email protected]>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
On Tue, 10 Jul 2007 15:50:39 +0200, Johannes Berg wrote:
> On Tue, 2007-07-10 at 15:34 +0200, Jiri Benc wrote:
>
> > But: It would make putting changes currently in wireless-dev to upstream a
> > nightmare. I wouldn't be able to take patches in the form they were
> > committed anymore and would need to heavily modify them.
>
> Why? We could just mirror these changes to upstream too.
Unfortunately, content of upstream ieee80211.c is different - it doesn't
contain .11n and wmm pieces, etc.
But even if it can be applied upstream, it doesn't solve anything. Imagine
a patch which was merged into wireless-dev before this restructuring and
which is not upstream. Merging it upstream would mean taking the patch from
wireless-dev git and manually modifying it to fit a new structure. And we
have a bunch of such patches which should go to 2.6.24 (yes, I really
mean .24). Perhaps I'm lazy, but I'd like to avoid that. It's going to be a
lot of unpleasant work even without this...
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
On Tue, 2007-07-10 at 16:29 +0200, Jiri Benc wrote:
> But even if it can be applied upstream, it doesn't solve anything. Imagine
> a patch which was merged into wireless-dev before this restructuring and
> which is not upstream. Merging it upstream would mean taking the patch from
> wireless-dev git and manually modifying it to fit a new structure. And we
> have a bunch of such patches which should go to 2.6.24 (yes, I really
> mean .24). Perhaps I'm lazy, but I'd like to avoid that. It's going to be a
> lot of unpleasant work even without this...
Which all goes to say that pushing mac80211 for .22 was too fast.
joahnnes
On Tue, Jul 10, 2007 at 04:51:18PM +0200, Johannes Berg wrote:
> On Tue, 2007-07-10 at 16:29 +0200, Jiri Benc wrote:
> > which is not upstream. Merging it upstream would mean taking the patch from
> > wireless-dev git and manually modifying it to fit a new structure. And we
> > have a bunch of such patches which should go to 2.6.24 (yes, I really
> > mean .24). Perhaps I'm lazy, but I'd like to avoid that. It's going to be a
> > lot of unpleasant work even without this...
>
> Which all goes to say that pushing mac80211 for .22 was too fast.
Hmmmm...maybe. But, what would have been the perfect trigger to
merge it? At least now we have less bits out-of-stream and have to
do less API-chasing with every new kernel.
John
--
John W. Linville
[email protected]