[parisc-linux] Re: Fw: Another problem with making things static

[Adrian Bunk]

First of all thanks to Andrew for forwarding this email to me - it's 
otherwise a bit hard to defend against an email that doesn't reach me.

>...
> 
> We're going to need this one reverting for parisc.  If you remember
> we've been trying to push a compat_sys_rt_sigqueueinfo but Andi keeps
> objecting, so it's remained local to our tree (an hence so has the
> symbol usage).
> 
> However, can we *please* stop this indiscriminate rampage through all
> the sybsystems making things static just because we can.  The true test
> of whether a symbol should be static or not is whether it forms part of
> a sensible API or not.  For subsystems with a well defined API, this is
> quite easy (although it hasn't prevented attempts to make even those
> symbols static).  For some of our core subsystems (like the kernel API
> in this case) it's much less well defined ... although we have a good
> solid white area of things that must be part of the API and a good solid
> black area of things that mustn't, we still have a large grey area which
> things like kill_proc_info() fall into.
> 
> For any person who wants to make a static symbol exported, we force an
> explanation out of them about what they're trying to do and why.  Might
> I suggest we apply the same standard to anyone trying to make something
> static?  i.e. they need to explain clearly why the symbol shouldn't be
> part of any rational API.

And by how many percent will this bloat the kernel more in the long 
term?

> Thanks,
> 
> James
> Date: Thu, 8 Feb 2007 22:33:21 -0500
> From: Kyle McMartin <kyle at mcmartin.ca>
> To: Matthew Wilcox <matthew at wil.cx>
> Cc: Kyle McMartin <kyle at mcmartin.ca>,
> 	parisc-linux <parisc-linux at lists.parisc-linux.org>
> Subject: Re: [parisc-linux] 64-bit kernel broken.
> 
> On Thu, Feb 08, 2007 at 08:24:54PM -0700, Matthew Wilcox wrote:
> > On Thu, Feb 08, 2007 at 07:43:14PM -0500, Kyle McMartin wrote:
> > > > Right. This got inadvertantly reverted with some other stuff. Fixed in a
> > > > second.
> > > 
> > > Fixed in 1736b4bbf2bbfebaad06114d569f3617517524d1.
> > 
> > make.err:/home/willy/nicol-2.6/arch/parisc/kernel/signal32.c:519:
> > warning: implicit declaration of function 'kill_proc_info'
> > make.err:(.text.compat_sys_rt_sigqueueinfo+0x80): undefined reference to
> > `kill_proc_info'
> > 
> 
> Guess who came home for Christmas
> 
> commit d3228a887cae75ef2b8b1211c31c539bef5a5698
> Author: Adrian Bunk <bunk at stusta.de>
> Date:   Wed Dec 6 20:38:22 2006 -0800
> 
>     [PATCH] make kernel/signal.c:kill_proc_info() static
> 
>     Signed-off-by: Adrian Bunk <bunk at stusta.de>
>     Signed-off-by: Andrew Morton <akpm at osdl.org>
>     Signed-off-by: Linus Torvalds <torvalds at osdl.org>

There are hundreds of such patches of mine that got included in Linus' 
tree and that didn't cause problems. Besides making the kernel smaller, 
they regularly find "it should have been used" bugs.

In this one case, a patch that made something static that wasn't used 
from other files during the over 9 years of it's existence clashes with 
another patch that adds a user.

Can we agree that it's not a usual case that the first user gets added 
after more than 9 years?

And making it global again when a user gets included isn't really that 
hard.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed