* [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. @ 2009-04-16 3:07 Paul Mundt 2009-04-16 8:11 ` Benny Halevy 0 siblings, 1 reply; 14+ messages in thread From: Paul Mundt @ 2009-04-16 3:07 UTC (permalink / raw) To: linux-next; +Cc: Benny Halevy, Andy Adamson, Trond Myklebust Caught with the sh allmodconfig: ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [sub-make] Error 2 find_last_bit.o is currently built with lib-y, which ends up breaking the nfs module build after the ("nfs41: free slot") commit. Move it to obj-y so the EXPORT_SYMBOL() actually has some effect. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Cc: Benny Halevy <bhalevy@panasas.com> Cc: Andy Adamson <andros@netapp.com> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> --- diff --git a/lib/Makefile b/lib/Makefile index d6edd67..33a40e4 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -38,7 +38,7 @@ lib-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o lib-$(CONFIG_GENERIC_FIND_FIRST_BIT) += find_next_bit.o lib-$(CONFIG_GENERIC_FIND_NEXT_BIT) += find_next_bit.o -lib-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o +obj-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o obj-$(CONFIG_GENERIC_HWEIGHT) += hweight.o obj-$(CONFIG_LOCK_KERNEL) += kernel_lock.o obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-16 3:07 [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules Paul Mundt @ 2009-04-16 8:11 ` Benny Halevy 2009-04-23 6:50 ` Paul Mundt 0 siblings, 1 reply; 14+ messages in thread From: Benny Halevy @ 2009-04-16 8:11 UTC (permalink / raw) To: Paul Mundt, Trond Myklebust; +Cc: linux-next, Andy Adamson, Fredric Isaman On Apr. 16, 2009, 6:07 +0300, Paul Mundt <lethal@linux-sh.org> wrote: > Caught with the sh allmodconfig: > > ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined! > make[2]: *** [__modpost] Error 1 > make[1]: *** [modules] Error 2 > make: *** [sub-make] Error 2 > > find_last_bit.o is currently built with lib-y, which ends up breaking > the nfs module build after the ("nfs41: free slot") commit. Move it > to obj-y so the EXPORT_SYMBOL() actually has some effect. > > Signed-off-by: Paul Mundt <lethal@linux-sh.org> > Cc: Benny Halevy <bhalevy@panasas.com> ACK. and thanks! FYI, Fred's original patch can be found here: http://patchwork.kernel.org/patch/14572/ It is also queued in the linux-pnfs tree: http://git.linux-nfs.org/?p=bhalevy/linux-pnfs.git;a=commitdiff;h=1e3a7552d9de2ba101b76deed99605f0145fc4d5 but I haven't submitted it to Trond since I expected it to get upstream (and to -next) via linux-kbuild. Trond, would you like to pull this change to your nfsv41 branch? (should appear before "nfs41: free slot" as Paul noticed) Benny > Cc: Andy Adamson <andros@netapp.com> > Cc: Trond Myklebust <Trond.Myklebust@netapp.com> > > --- > > diff --git a/lib/Makefile b/lib/Makefile > index d6edd67..33a40e4 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -38,7 +38,7 @@ lib-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o > lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o > lib-$(CONFIG_GENERIC_FIND_FIRST_BIT) += find_next_bit.o > lib-$(CONFIG_GENERIC_FIND_NEXT_BIT) += find_next_bit.o > -lib-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o > +obj-$(CONFIG_GENERIC_FIND_LAST_BIT) += find_last_bit.o > obj-$(CONFIG_GENERIC_HWEIGHT) += hweight.o > obj-$(CONFIG_LOCK_KERNEL) += kernel_lock.o > obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-16 8:11 ` Benny Halevy @ 2009-04-23 6:50 ` Paul Mundt 2009-04-23 10:12 ` Benny Halevy 0 siblings, 1 reply; 14+ messages in thread From: Paul Mundt @ 2009-04-23 6:50 UTC (permalink / raw) To: Benny Halevy Cc: Trond Myklebust, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell On Thu, Apr 16, 2009 at 11:11:02AM +0300, Benny Halevy wrote: > On Apr. 16, 2009, 6:07 +0300, Paul Mundt <lethal@linux-sh.org> wrote: > > Caught with the sh allmodconfig: > > > > ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined! > > make[2]: *** [__modpost] Error 1 > > make[1]: *** [modules] Error 2 > > make: *** [sub-make] Error 2 > > > > find_last_bit.o is currently built with lib-y, which ends up breaking > > the nfs module build after the ("nfs41: free slot") commit. Move it > > to obj-y so the EXPORT_SYMBOL() actually has some effect. > > > > Signed-off-by: Paul Mundt <lethal@linux-sh.org> > > Cc: Benny Halevy <bhalevy@panasas.com> > > ACK. and thanks! > > FYI, Fred's original patch can be found here: > http://patchwork.kernel.org/patch/14572/ > > It is also queued in the linux-pnfs tree: > http://git.linux-nfs.org/?p=bhalevy/linux-pnfs.git;a=commitdiff;h=1e3a7552d9de2ba101b76deed99605f0145fc4d5 > but I haven't submitted it to Trond since I expected > it to get upstream (and to -next) via linux-kbuild. > > Trond, would you like to pull this change to your nfsv41 branch? > (should appear before "nfs41: free slot" as Paul noticed) > Ok, so we have two different trivial patches for fixing the same thing, and a week later it is still broken. I realize it is a trivial patch, but it does break builds. If folks aren't going to take these sorts of things more seriously, then their tree should be dropped after a grace period (say 2 days or so). Beyond that, it doesn't seem like -next has any sort of coherent policy for dealing with trivial patches. If the emphasis is on the tree that introduced the regression to deal with it, then trees need to be aggressively dropped when these things go unfixed. Having builds broken for a week for an issue that has been spotted and fixed by several people is simply unacceptable. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-23 6:50 ` Paul Mundt @ 2009-04-23 10:12 ` Benny Halevy 2009-04-23 10:29 ` Paul Mundt 0 siblings, 1 reply; 14+ messages in thread From: Benny Halevy @ 2009-04-23 10:12 UTC (permalink / raw) To: Paul Mundt, Rusty Russell, Ingo Molnar Cc: Trond Myklebust, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Apr. 23, 2009, 9:50 +0300, Paul Mundt <lethal@linux-sh.org> wrote: > On Thu, Apr 16, 2009 at 11:11:02AM +0300, Benny Halevy wrote: >> On Apr. 16, 2009, 6:07 +0300, Paul Mundt <lethal@linux-sh.org> wrote: >>> Caught with the sh allmodconfig: >>> >>> ERROR: "find_last_bit" [fs/nfs/nfs.ko] undefined! >>> make[2]: *** [__modpost] Error 1 >>> make[1]: *** [modules] Error 2 >>> make: *** [sub-make] Error 2 >>> >>> find_last_bit.o is currently built with lib-y, which ends up breaking >>> the nfs module build after the ("nfs41: free slot") commit. Move it >>> to obj-y so the EXPORT_SYMBOL() actually has some effect. >>> >>> Signed-off-by: Paul Mundt <lethal@linux-sh.org> >>> Cc: Benny Halevy <bhalevy@panasas.com> >> ACK. and thanks! >> >> FYI, Fred's original patch can be found here: >> http://patchwork.kernel.org/patch/14572/ >> >> It is also queued in the linux-pnfs tree: >> http://git.linux-nfs.org/?p=bhalevy/linux-pnfs.git;a=commitdiff;h=1e3a7552d9de2ba101b76deed99605f0145fc4d5 >> but I haven't submitted it to Trond since I expected >> it to get upstream (and to -next) via linux-kbuild. >> >> Trond, would you like to pull this change to your nfsv41 branch? >> (should appear before "nfs41: free slot" as Paul noticed) >> > Ok, so we have two different trivial patches for fixing the same thing, > and a week later it is still broken. > > I realize it is a trivial patch, but it does break builds. If folks > aren't going to take these sorts of things more seriously, then their > tree should be dropped after a grace period (say 2 days or so). > > Beyond that, it doesn't seem like -next has any sort of coherent policy > for dealing with trivial patches. If the emphasis is on the tree that > introduced the regression to deal with it, then trees need to be > aggressively dropped when these things go unfixed. > > Having builds broken for a week for an issue that has been spotted and > fixed by several people is simply unacceptable. Paul, that's a valid point but I don't set these polices. Trond suggested to just commit this to 2.6.30 and I asked Rusty's Ack here: http://lkml.org/lkml/2009/4/21/489 Like I said there, I'm not sure who to send this patch to. Ingo? Benny ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-23 10:12 ` Benny Halevy @ 2009-04-23 10:29 ` Paul Mundt 2009-04-23 12:59 ` Trond Myklebust 0 siblings, 1 reply; 14+ messages in thread From: Paul Mundt @ 2009-04-23 10:29 UTC (permalink / raw) To: Benny Halevy Cc: Rusty Russell, Ingo Molnar, Trond Myklebust, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Thu, Apr 23, 2009 at 01:12:54PM +0300, Benny Halevy wrote: > On Apr. 23, 2009, 9:50 +0300, Paul Mundt <lethal@linux-sh.org> wrote: > > Ok, so we have two different trivial patches for fixing the same thing, > > and a week later it is still broken. > > > > I realize it is a trivial patch, but it does break builds. If folks > > aren't going to take these sorts of things more seriously, then their > > tree should be dropped after a grace period (say 2 days or so). > > > > Beyond that, it doesn't seem like -next has any sort of coherent policy > > for dealing with trivial patches. If the emphasis is on the tree that > > introduced the regression to deal with it, then trees need to be > > aggressively dropped when these things go unfixed. > > > > Having builds broken for a week for an issue that has been spotted and > > fixed by several people is simply unacceptable. > > Paul, that's a valid point but I don't set these polices. > Trond suggested to just commit this to 2.6.30 > and I asked Rusty's Ack here: > http://lkml.org/lkml/2009/4/21/489 > > Like I said there, I'm not sure who to send this patch to. > Ingo? > I was under the impression that a tree that caused a build regression would be dropped until it had it sorted out, but that seems to be more the exception than the rule. -next is good at finding bugs in build configurations folks haven't considered, which should serve as a pretty good platform for getting those types of fixes merged quickly, whether it be in to the tree that caused the regression or -next directly. Unfortunately it seems like build regressions are more of an afterthought than a show stopper. I count at least 3 on the sh builds in the last couple weeks that are all averaging a week or longer to unbreak, while patches have been available almost immediately. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-23 10:29 ` Paul Mundt @ 2009-04-23 12:59 ` Trond Myklebust 2009-04-23 13:18 ` Benny Halevy 2009-04-23 13:25 ` Paul Mundt 0 siblings, 2 replies; 14+ messages in thread From: Trond Myklebust @ 2009-04-23 12:59 UTC (permalink / raw) To: Paul Mundt Cc: Benny Halevy, Rusty Russell, Ingo Molnar, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Thu, 2009-04-23 at 19:29 +0900, Paul Mundt wrote: > On Thu, Apr 23, 2009 at 01:12:54PM +0300, Benny Halevy wrote: > > On Apr. 23, 2009, 9:50 +0300, Paul Mundt <lethal@linux-sh.org> wrote: > > > Ok, so we have two different trivial patches for fixing the same thing, > > > and a week later it is still broken. > > > > > > I realize it is a trivial patch, but it does break builds. If folks > > > aren't going to take these sorts of things more seriously, then their > > > tree should be dropped after a grace period (say 2 days or so). > > > > > > Beyond that, it doesn't seem like -next has any sort of coherent policy > > > for dealing with trivial patches. If the emphasis is on the tree that > > > introduced the regression to deal with it, then trees need to be > > > aggressively dropped when these things go unfixed. > > > > > > Having builds broken for a week for an issue that has been spotted and > > > fixed by several people is simply unacceptable. > > > > Paul, that's a valid point but I don't set these polices. > > Trond suggested to just commit this to 2.6.30 > > and I asked Rusty's Ack here: > > http://lkml.org/lkml/2009/4/21/489 > > > > Like I said there, I'm not sure who to send this patch to. > > Ingo? > > > I was under the impression that a tree that caused a build regression > would be dropped until it had it sorted out, but that seems to be more > the exception than the rule. > > -next is good at finding bugs in build configurations folks haven't > considered, which should serve as a pretty good platform for getting > those types of fixes merged quickly, whether it be in to the tree that > caused the regression or -next directly. > > Unfortunately it seems like build regressions are more of an afterthought > than a show stopper. I count at least 3 on the sh builds in the last > couple weeks that are all averaging a week or longer to unbreak, while > patches have been available almost immediately. In this case, the tree in question is exposing a bug that already exists in mainline; a function that is explicitly labelled as being exported for use by arbitrary modules, and yet isn't being compiled into the kernel. Shooting the messenger isn't going to fix that. In any case, this patch does not belong in the NFS tree since it touches generic library code, not NFS code. Benny, if nobody else wants to shepherd it, then just send it directly to Linus. Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-23 12:59 ` Trond Myklebust @ 2009-04-23 13:18 ` Benny Halevy 2009-04-23 13:25 ` Paul Mundt 1 sibling, 0 replies; 14+ messages in thread From: Benny Halevy @ 2009-04-23 13:18 UTC (permalink / raw) To: Trond Myklebust Cc: Paul Mundt, Rusty Russell, Ingo Molnar, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Apr. 23, 2009, 15:59 +0300, Trond Myklebust <Trond.Myklebust@netapp.com> wrote: > On Thu, 2009-04-23 at 19:29 +0900, Paul Mundt wrote: >> On Thu, Apr 23, 2009 at 01:12:54PM +0300, Benny Halevy wrote: >>> On Apr. 23, 2009, 9:50 +0300, Paul Mundt <lethal@linux-sh.org> wrote: >>>> Ok, so we have two different trivial patches for fixing the same thing, >>>> and a week later it is still broken. >>>> >>>> I realize it is a trivial patch, but it does break builds. If folks >>>> aren't going to take these sorts of things more seriously, then their >>>> tree should be dropped after a grace period (say 2 days or so). >>>> >>>> Beyond that, it doesn't seem like -next has any sort of coherent policy >>>> for dealing with trivial patches. If the emphasis is on the tree that >>>> introduced the regression to deal with it, then trees need to be >>>> aggressively dropped when these things go unfixed. >>>> >>>> Having builds broken for a week for an issue that has been spotted and >>>> fixed by several people is simply unacceptable. >>> Paul, that's a valid point but I don't set these polices. >>> Trond suggested to just commit this to 2.6.30 >>> and I asked Rusty's Ack here: >>> http://lkml.org/lkml/2009/4/21/489 >>> >>> Like I said there, I'm not sure who to send this patch to. >>> Ingo? >>> >> I was under the impression that a tree that caused a build regression >> would be dropped until it had it sorted out, but that seems to be more >> the exception than the rule. >> >> -next is good at finding bugs in build configurations folks haven't >> considered, which should serve as a pretty good platform for getting >> those types of fixes merged quickly, whether it be in to the tree that >> caused the regression or -next directly. >> >> Unfortunately it seems like build regressions are more of an afterthought >> than a show stopper. I count at least 3 on the sh builds in the last >> couple weeks that are all averaging a week or longer to unbreak, while >> patches have been available almost immediately. > > In this case, the tree in question is exposing a bug that already exists > in mainline; a function that is explicitly labelled as being exported > for use by arbitrary modules, and yet isn't being compiled into the > kernel. Shooting the messenger isn't going to fix that. > > In any case, this patch does not belong in the NFS tree since it touches > generic library code, not NFS code. Benny, if nobody else wants to > shepherd it, then just send it directly to Linus. Will do. Regardless, Paul's observation seems valid. I wonder if linux-next should have a branch or pull a tree holding trivial fixes fitting no other specific tree... Benny > > Trond ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-23 12:59 ` Trond Myklebust 2009-04-23 13:18 ` Benny Halevy @ 2009-04-23 13:25 ` Paul Mundt 2009-04-23 13:59 ` Trond Myklebust 1 sibling, 1 reply; 14+ messages in thread From: Paul Mundt @ 2009-04-23 13:25 UTC (permalink / raw) To: Trond Myklebust Cc: Benny Halevy, Rusty Russell, Ingo Molnar, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Thu, Apr 23, 2009 at 08:59:49AM -0400, Trond Myklebust wrote: > On Thu, 2009-04-23 at 19:29 +0900, Paul Mundt wrote: > > I was under the impression that a tree that caused a build regression > > would be dropped until it had it sorted out, but that seems to be more > > the exception than the rule. > > > > -next is good at finding bugs in build configurations folks haven't > > considered, which should serve as a pretty good platform for getting > > those types of fixes merged quickly, whether it be in to the tree that > > caused the regression or -next directly. > > > > Unfortunately it seems like build regressions are more of an afterthought > > than a show stopper. I count at least 3 on the sh builds in the last > > couple weeks that are all averaging a week or longer to unbreak, while > > patches have been available almost immediately. > > In this case, the tree in question is exposing a bug that already exists > in mainline; a function that is explicitly labelled as being exported > for use by arbitrary modules, and yet isn't being compiled into the > kernel. Shooting the messenger isn't going to fix that. > Nor is bantering on semantics going to change the fact that you caused a build regression and have so far refused to even acknowledge that that is a problem. If anyone had bothered to test the module build, this would have shown up immediately and would have rightly been fixed before that change was merged. Claiming that the two are completely unrelated after the fact is rather disingenuous, and does nothing to address the process problem. > In any case, this patch does not belong in the NFS tree since it touches > generic library code, not NFS code. Benny, if nobody else wants to > shepherd it, then just send it directly to Linus. > That's a complete cop-out, if there had been no export at all how would you have proceeded? How is this situation any different? I am willing to monitor my builds regularly and send out trivial patches to fix whatever ends up breaking, but I do expect people who have caused regressions to take these matters seriously rather than sweep them under the carpet and pretend like they either don't exist or are somehow someone else's problem. Any tree that causes a regression should simply be dropped until it gets it sorted out, as it's abundantly obvious that people aren't even prepared to do the bare minimum to keep things working after they've been pulled from. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-23 13:25 ` Paul Mundt @ 2009-04-23 13:59 ` Trond Myklebust 2009-04-23 14:12 ` Paul Mundt 0 siblings, 1 reply; 14+ messages in thread From: Trond Myklebust @ 2009-04-23 13:59 UTC (permalink / raw) To: Paul Mundt Cc: Benny Halevy, Rusty Russell, Ingo Molnar, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote: > > In any case, this patch does not belong in the NFS tree since it touches > > generic library code, not NFS code. Benny, if nobody else wants to > > shepherd it, then just send it directly to Linus. > > > That's a complete cop-out, if there had been no export at all how would > you have proceeded? How is this situation any different? Please see Documentation/SubmittingPatches. If we were requesting a new kernel feature, I'd go looking for the maintainer and get an ACK or get said maintainer to include the patch in their tree. As it is, said kernel feature exists, but is broken. The correct thing to do is to fix the kernel feature. Sooner, rather than later. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-23 13:59 ` Trond Myklebust @ 2009-04-23 14:12 ` Paul Mundt 2009-04-23 16:38 ` Trond Myklebust 0 siblings, 1 reply; 14+ messages in thread From: Paul Mundt @ 2009-04-23 14:12 UTC (permalink / raw) To: Trond Myklebust Cc: Benny Halevy, Rusty Russell, Ingo Molnar, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Thu, Apr 23, 2009 at 09:59:28AM -0400, Trond Myklebust wrote: > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote: > > > In any case, this patch does not belong in the NFS tree since it touches > > > generic library code, not NFS code. Benny, if nobody else wants to > > > shepherd it, then just send it directly to Linus. > > > > > That's a complete cop-out, if there had been no export at all how would > > you have proceeded? How is this situation any different? > > Please see Documentation/SubmittingPatches. If we were requesting a new > kernel feature, I'd go looking for the maintainer and get an ACK or get > said maintainer to include the patch in their tree. > > As it is, said kernel feature exists, but is broken. The correct thing > to do is to fix the kernel feature. Sooner, rather than later. > And until that feature is working, you have absolutely no business merging crap in to the kernel that uses it. You made an assumption that it was working, which turned out to be wrong (which you also failed to validate through any form of testing), and subsequently caused a regression. Mistakes happen and are expected in -next, refusing to deal with them at all on the other hand.. The first course of action any responsible maintainer would have taken would be to revert the offending changeset once the issue was pointed out until its dependencies were sorted out. Not only have you failed to do that, you couldn't even be bothered replying to the email with patch that pointed out the build failure in the first place. This created the mistaken conclusion that you were actually doing something about the regression you caused rather than just dismissing it out of hand. The nfs tree should be dropped on the floor immediately until this issue is resolved. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-23 14:12 ` Paul Mundt @ 2009-04-23 16:38 ` Trond Myklebust 2009-04-26 12:49 ` Rusty Russell 0 siblings, 1 reply; 14+ messages in thread From: Trond Myklebust @ 2009-04-23 16:38 UTC (permalink / raw) To: Paul Mundt Cc: Benny Halevy, Rusty Russell, Ingo Molnar, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Thu, 2009-04-23 at 23:12 +0900, Paul Mundt wrote: > On Thu, Apr 23, 2009 at 09:59:28AM -0400, Trond Myklebust wrote: > > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote: > > > > In any case, this patch does not belong in the NFS tree since it touches > > > > generic library code, not NFS code. Benny, if nobody else wants to > > > > shepherd it, then just send it directly to Linus. > > > > > > > That's a complete cop-out, if there had been no export at all how would > > > you have proceeded? How is this situation any different? > > > > Please see Documentation/SubmittingPatches. If we were requesting a new > > kernel feature, I'd go looking for the maintainer and get an ACK or get > > said maintainer to include the patch in their tree. > > > > As it is, said kernel feature exists, but is broken. The correct thing > > to do is to fix the kernel feature. Sooner, rather than later. > > > And until that feature is working, you have absolutely no business > merging crap in to the kernel that uses it. You made an assumption that > it was working, which turned out to be wrong (which you also failed to > validate through any form of testing), and subsequently caused a > regression. Mistakes happen and are expected in -next, refusing to deal > with them at all on the other hand.. > > The first course of action any responsible maintainer would have taken > would be to revert the offending changeset once the issue was pointed out > until its dependencies were sorted out. Not only have you failed to do > that, you couldn't even be bothered replying to the email with patch that > pointed out the build failure in the first place. This created the > mistaken conclusion that you were actually doing something about the > regression you caused rather than just dismissing it out of hand. > > The nfs tree should be dropped on the floor immediately until this issue > is resolved. Whatever... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-23 16:38 ` Trond Myklebust @ 2009-04-26 12:49 ` Rusty Russell 2009-04-26 16:42 ` Ingo Molnar 0 siblings, 1 reply; 14+ messages in thread From: Rusty Russell @ 2009-04-26 12:49 UTC (permalink / raw) To: Trond Myklebust Cc: Paul Mundt, Benny Halevy, Ingo Molnar, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Fri, 24 Apr 2009 02:08:50 am Trond Myklebust wrote: > > > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote: > > > > > In any case, this patch does not belong in the NFS tree since it touches > > > > > generic library code, not NFS code. Benny, if nobody else wants to > > > > > shepherd it, then just send it directly to Linus. ... > > The nfs tree should be dropped on the floor immediately until this issue > > is resolved. > > Whatever... FWIW Trond, I would have taken the patch and pushed it. It happens: it's not your fault, but it suddenly became your problem. And Paul: being right doesn't excuse being an asshole.[1] Thanks, Rusty. [1] As this rule applies to this message, I ponder my own failings. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-26 12:49 ` Rusty Russell @ 2009-04-26 16:42 ` Ingo Molnar 2009-04-26 17:29 ` Trond Myklebust 0 siblings, 1 reply; 14+ messages in thread From: Ingo Molnar @ 2009-04-26 16:42 UTC (permalink / raw) To: Rusty Russell Cc: Trond Myklebust, Paul Mundt, Benny Halevy, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp * Rusty Russell <rusty@rustcorp.com.au> wrote: > On Fri, 24 Apr 2009 02:08:50 am Trond Myklebust wrote: > > > > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote: > > > > > > In any case, this patch does not belong in the NFS tree since it touches > > > > > > generic library code, not NFS code. Benny, if nobody else wants to > > > > > > shepherd it, then just send it directly to Linus. > ... > > > The nfs tree should be dropped on the floor immediately until this issue > > > is resolved. > > > > Whatever... > > FWIW Trond, I would have taken the patch and pushed it. It > happens: it's not your fault, but it suddenly became your problem. To double check things: is it clear now who pushes the fix and when? I'm obviously acking it and can push it to Linus if needed. Thanks, Ingo ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules. 2009-04-26 16:42 ` Ingo Molnar @ 2009-04-26 17:29 ` Trond Myklebust 0 siblings, 0 replies; 14+ messages in thread From: Trond Myklebust @ 2009-04-26 17:29 UTC (permalink / raw) To: Ingo Molnar Cc: Rusty Russell, Paul Mundt, Benny Halevy, linux-next, Andy Adamson, Fredric Isaman, Stephen Rothwell, Alexander Beregalov, Subrata Modak, sachinp On Sun, 2009-04-26 at 18:42 +0200, Ingo Molnar wrote: > * Rusty Russell <rusty@rustcorp.com.au> wrote: > > > On Fri, 24 Apr 2009 02:08:50 am Trond Myklebust wrote: > > > > > On Thu, 2009-04-23 at 22:25 +0900, Paul Mundt wrote: > > > > > > > In any case, this patch does not belong in the NFS tree since it touches > > > > > > > generic library code, not NFS code. Benny, if nobody else wants to > > > > > > > shepherd it, then just send it directly to Linus. > > ... > > > > The nfs tree should be dropped on the floor immediately until this issue > > > > is resolved. > > > > > > Whatever... > > > > FWIW Trond, I would have taken the patch and pushed it. It > > happens: it's not your fault, but it suddenly became your problem. > > To double check things: is it clear now who pushes the fix and when? > I'm obviously acking it and can push it to Linus if needed. Linus has already merged it as commit a5422a5111811401f7756345e4c237ff06cf6d1e Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-04-26 17:30 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-04-16 3:07 [PATCH -next] lib: Move find_last_bit.o to obj-y to enable use by modules Paul Mundt 2009-04-16 8:11 ` Benny Halevy 2009-04-23 6:50 ` Paul Mundt 2009-04-23 10:12 ` Benny Halevy 2009-04-23 10:29 ` Paul Mundt 2009-04-23 12:59 ` Trond Myklebust 2009-04-23 13:18 ` Benny Halevy 2009-04-23 13:25 ` Paul Mundt 2009-04-23 13:59 ` Trond Myklebust 2009-04-23 14:12 ` Paul Mundt 2009-04-23 16:38 ` Trond Myklebust 2009-04-26 12:49 ` Rusty Russell 2009-04-26 16:42 ` Ingo Molnar 2009-04-26 17:29 ` Trond Myklebust
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.