When you guys go on these "make needlessly global code static" kicks you
should maybe consider that even functions that aren't currently used by any
other area of the tree might be useful for module writers.
Instead of just checking which functions are currently used by other parts of
the kernel perhaps you should think about what makes a logical API and stick
to that, even if not all of the functions are currently used.
In the case of net/core/datagram.c, why make skb_copy_datagram private but
leave skb_copy_datagram_iovec global? If the latter is a useful public
function why not the former?
In particular vmware used skb_copy_datagram. So 2.6.11 broke vmware for no
good reason.
<[email protected]>
[NET]: misc cleanups
The patch below contains the following cleanups:
- make needlessly global code static
- remove the following unused global functions:
- datagram.c: skb_copy_datagram
- iovec.c: memcpy_tokerneliovec
- remove the following unneeded EXPORT_SYMBOL's:
- datagram.c: skb_copy_datagram
- dev.c: ing_filter
- iovec.c: memcpy_tokerneliovec
- netpoll.c: netpoll_send_skb
- rtnetlink.c: rtnetlink_dump_ifinfo
- sock.c: sock_alloc_send_pskb
Signed-off-by: Adrian Bunk <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
--
greg
On Fri, 2005-03-18 at 10:33 -0500, Greg Stark wrote:
> In particular vmware used skb_copy_datagram. So 2.6.11 broke vmware for no
> good reason.
I don't know about the validity or otherwise of (un)exporting
skb_copy_datagram but for what it's worth
http://ftp.cvut.cz/vmware/vmware-any-any-update89.tar.gz has been
updated to work with 2.6.11.
Ian.
--
Ian Campbell
Current Noise: Entombed - Out of Heaven
Santa Claus is watching!
Hi Greg,
> When you guys go on these "make needlessly global code static" kicks
> you should maybe consider that even functions that aren't currently
> used by any other area of the tree might be useful for module writers.
>
> Instead of just checking which functions are currently used by other
> parts of the kernel perhaps you should think about what makes a
> logical API and stick to that, even if not all of the functions are
> currently used.
I'd second that. Cleanups are good and I do not deny that Adrian Bunk
has been doing a terrific work. However, unexporting or removing
functions just because they have no current user in the kernel tree is
not always a clever thing to do. Keeping things square and logical
should be taken into consideration, as should the possibility that some
function might be used outside of the kernel tree. I do *not* mean
entire interfaces only used outside of the kernel tree, because these
are highly questionable, but functions that are part of a larger set of
functions representing an interface, most of which are used inside the
kernel. In this specific case, dropping exports or removing functions
make very little sense to me and is sometimes calling for trouble, as
Greg just underlined. In some cases, the functions are likely to be
reintroduced/reexported a few months later and we certainly could use
our time in a more useful way than undoing and redoing things.
Thanks,
--
Jean Delvare
On Fri, 2005-03-18 at 13:49, Jean Delvare wrote:
> Hi Greg,
>
> > When you guys go on these "make needlessly global code static" kicks
> > you should maybe consider that even functions that aren't currently
> > used by any other area of the tree might be useful for module writers.
> >
> > Instead of just checking which functions are currently used by other
> > parts of the kernel perhaps you should think about what makes a
> > logical API and stick to that, even if not all of the functions are
> > currently used.
>
> I'd second that. Cleanups are good and I do not deny that Adrian Bunk
> has been doing a terrific work. However, unexporting or removing
> functions just because they have no current user in the kernel tree is
> not always a clever thing to do. Keeping things square and logical
> should be taken into consideration, as should the possibility that some
> function might be used outside of the kernel tree. I do *not* mean
> entire interfaces only used outside of the kernel tree, because these
> are highly questionable, but functions that are part of a larger set of
> functions representing an interface, most of which are used inside the
> kernel. In this specific case, dropping exports or removing functions
> make very little sense to me and is sometimes calling for trouble, as
> Greg just underlined. In some cases, the functions are likely to be
> reintroduced/reexported a few months later and we certainly could use
> our time in a more useful way than undoing and redoing things.
>
> Thanks,
So perhaps we can introduce a new term to linux kernel development,
reexporting a symbol can now be known as debunking?
(sorry, sorry, I couldn't resist)
On Fri, Mar 18, 2005 at 02:01:02PM -0500, John Kacur wrote:
>
> So perhaps we can introduce a new term to linux kernel development,
> reexporting a symbol can now be known as debunking?
>...
Are you saying unexporting a symbol was bunk? ;-)
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