[PATCH 3/3] proc: make grab_header static

[PATCH 3/3] proc: make grab_header static

[Harvey Harrison]

fs/proc/proc_sysctl.c:69:25: warning: symbol 'grab_header' was not declared. Should it be static?

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
Appeared between next-20080716 and next-20080717

 fs/proc/proc_sysctl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index f9a8b89..84f58e8 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -66,7 +66,7 @@ static struct ctl_table *find_in_table(struct ctl_table *p, struct qstr *name)
 	return NULL;
 }
 
-struct ctl_table_header *grab_header(struct inode *inode)
+static struct ctl_table_header *grab_header(struct inode *inode)
 {
 	if (PROC_I(inode)->sysctl)
 		return sysctl_head_grab(PROC_I(inode)->sysctl);
-- 
1.5.6.3.536.g61aad

Re: [PATCH 3/3] proc: make grab_header static

[Andrew Morton]

On Thu, 17 Jul 2008 14:22:35 -0700
Harvey Harrison <harvey.harrison@gmail.com> wrote:

> fs/proc/proc_sysctl.c:69:25: warning: symbol 'grab_header' was not declared. Should it be static?
> 
> Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
> ---
> Appeared between next-20080716 and next-20080717
> 
>  fs/proc/proc_sysctl.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> index f9a8b89..84f58e8 100644
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/proc_sysctl.c
> @@ -66,7 +66,7 @@ static struct ctl_table *find_in_table(struct ctl_table *p, struct qstr *name)
>  	return NULL;
>  }
>  
> -struct ctl_table_header *grab_header(struct inode *inode)
> +static struct ctl_table_header *grab_header(struct inode *inode)
>  {
>  	if (PROC_I(inode)->sysctl)
>  		return sysctl_head_grab(PROC_I(inode)->sysctl);

urgh.  We need to do something here.

People are dumping large hunks of 2.6.28 material into linux-next
during the merge window.  This screws me up because I haven't merged
into 2.6.27 yet, and my patch queue is based on linux-next.  And I
_have_ to do that, because lots of the git trees haven't merged into
mainline yet.

So to maintain my tree I need to forward-port patches on top of the
newly-added 2.6.28 material, then backport it all onto mainline for
merging (which will wreck the next linux-next release).

I hadn't anticipated this.

It's nothing new - it used to happen when -mm was a collection of 70
git-foo.patch as well.


See, for the purposes of tree maintainers who haven't merged yet,
linux-next is still the 2.6.27 candidate tree.  For those who _have_
merged, linux-next becomes the 2.6.28 candidate tree.

We'll see how it goes, but we might need a "don't merge 2.6.x+1 stuff
into linux-next until 2.6.x-rc1 has been released" rule.

Re: [PATCH 3/3] proc: make grab_header static

[Harvey Harrison]

On Thu, 2008-07-17 at 15:09 -0700, Andrew Morton wrote:
> urgh.  We need to do something here.
> 
> People are dumping large hunks of 2.6.28 material into linux-next
> during the merge window.  This screws me up because I haven't merged
> into 2.6.27 yet, and my patch queue is based on linux-next.  And I
> _have_ to do that, because lots of the git trees haven't merged into
> mainline yet.

Good luck.

I'll keep plugging away with my daily allyesconfig of each -next snapshot
to try and keep new warnings from going in....and over time hopefully get
the number to decrease.

Should I CC: you on on those fix patches, or try to get them directly through
the tree they came in from?

Cheers,

Harvey

Re: [PATCH 3/3] proc: make grab_header static

[Andrew Morton]

On Thu, 17 Jul 2008 15:15:37 -0700
Harvey Harrison <harvey.harrison@gmail.com> wrote:

> On Thu, 2008-07-17 at 15:09 -0700, Andrew Morton wrote:
> > urgh.  We need to do something here.
> > 
> > People are dumping large hunks of 2.6.28 material into linux-next
> > during the merge window.  This screws me up because I haven't merged
> > into 2.6.27 yet, and my patch queue is based on linux-next.  And I
> > _have_ to do that, because lots of the git trees haven't merged into
> > mainline yet.
> 
> Good luck.
> 
> I'll keep plugging away with my daily allyesconfig of each -next snapshot
> to try and keep new warnings from going in....and over time hopefully get
> the number to decrease.
> 
> Should I CC: you on on those fix patches, or try to get them directly through
> the tree they came in from?

Both, I suggest.  Fixes are important, and subsystem maintainers lose
stuff distressingly often.

Re: [PATCH 3/3] proc: make grab_header static

[Al Viro]

On Thu, Jul 17, 2008 at 03:09:50PM -0700, Andrew Morton wrote:
> On Thu, 17 Jul 2008 14:22:35 -0700
> Harvey Harrison <harvey.harrison@gmail.com> wrote:
> 
> > fs/proc/proc_sysctl.c:69:25: warning: symbol 'grab_header' was not declared. Should it be static?

> urgh.  We need to do something here.
> 
> People are dumping large hunks of 2.6.28 material into linux-next
> during the merge window.  This screws me up because I haven't merged
> into 2.6.27 yet, and my patch queue is based on linux-next.  And I
> _have_ to do that, because lots of the git trees haven't merged into
> mainline yet.

FWIW, you are slightly misreading the situation - it *is* my fault, but
in a different way.  What's happening is not development going into that
branch - it's untangling a huge pile of pending patches into sequence.
And yes, it should've gone public as-is a couple of weeks ago ;-/

Re: [PATCH 3/3] proc: make grab_header static

[Andrew Morton]

On Fri, 18 Jul 2008 00:23:28 +0100
Al Viro <viro@ZenIV.linux.org.uk> wrote:

> On Thu, Jul 17, 2008 at 03:09:50PM -0700, Andrew Morton wrote:
> > On Thu, 17 Jul 2008 14:22:35 -0700
> > Harvey Harrison <harvey.harrison@gmail.com> wrote:
> > 
> > > fs/proc/proc_sysctl.c:69:25: warning: symbol 'grab_header' was not declared. Should it be static?
> 
> > urgh.  We need to do something here.
> > 
> > People are dumping large hunks of 2.6.28 material into linux-next
> > during the merge window.  This screws me up because I haven't merged
> > into 2.6.27 yet, and my patch queue is based on linux-next.  And I
> > _have_ to do that, because lots of the git trees haven't merged into
> > mainline yet.
> 
> FWIW, you are slightly misreading the situation - it *is* my fault, but
> in a different way.  What's happening is not development going into that
> branch - it's untangling a huge pile of pending patches into sequence.
> And yes, it should've gone public as-is a couple of weeks ago ;-/

So this is actually late-breaking 2.6.27 material?  In that case: ouch,
but OK.

But the core problem remains: linux-next is the 2.6.27 integration tree
and remains the 2.6.27 integration tree *for some people* until
2.6.28-rc1 is released.

If people start putting lots of 2.6.x+1 material into linux-next prior
to the 2.6.x-rc1 release then we'll need to point this out and ask
people to tweak their practices a bit.

This happened yesterday with git-security-testing and James just moved
piles of new stuff into a "devel" tree which he'll transfer to
linux-next after -rc1, no probs.