Another problem with making things static

James Bottomley <[email protected]>
Newsgroups gmane.linux.ports.hppa
Message-ID <[email protected]>
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.

Thanks,

James

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
(unnamed) (message/rfc822, 5.5 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.