proc: make grab_header static
Subsystems (3)
PATCH 3/3 proc: make grab_header static
fs/proc/proc_sysctl.c:69:25: warning: symbol 'grab_header' was not declared. Should it be static?
---
Appeared between next-20080716 and next-20080717
fs/proc/proc_sysctl.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
fs/proc/proc_sysctl.c +1 -1
@@ -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);
Signature · 1 line
1.5.6.3.536.g61aad
Quoted 14 lines · On Thu, 17 Jul 2008 14:22:35 -0700 Harvey Harrison <[email protected]>…
fs/proc/proc_sysctl.c:69:25: warning: symbol 'grab_header' was not declared. Should it be static?Signed-off-by Harvey Harrison <[email protected]>---
Appeared between next-20080716 and next-20080717fs/proc/proc_sysctl.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)fs/proc/proc_sysctl.c +0
-0
fs/proc/proc_sysctl.c static struct ctl_table *find_in_table(struct ctl_table *p, struct qstr *name) · line 72
Quoted 8 lines
fs/proc/proc_sysctl.c +1
-1@@ -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.
Quoted 7 lines · Andrew Morton
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
Quoted 9 lines · On Thu, 17 Jul 2008 15:15:37 -0700 Harvey Harrison <[email protected]>…
Quoted 7 lines · Andrew Morton
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.
Quoted 8 lines
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.
Quoted 5 lines · Andrew Morton
Quoted 1 line · On Thu, 17 Jul 2008 14:22:35 -0700 Harvey Harrison <[email protected]>…
fs/proc/proc_sysctl.c:69:25: warning: symbol 'grab_header' was not declared. Should it be static?
Quoted 7 lines
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 ;-/
Quoted 14 lines · On Fri, 18 Jul 2008 00:23:28 +0100 Al Viro <[email protected]> wrote:
Quoted 5 lines · Andrew Morton
Quoted 1 line · On Thu, 17 Jul 2008 14:22:35 -0700 Harvey Harrison <[email protected]>…
fs/proc/proc_sysctl.c:69:25: warning: symbol 'grab_header' was not declared. Should it be static?Quoted 7 lines
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.
Quoted 4 lines
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.