Skip to contentSkip to conversation

remove dead tcp exports

PATCH In review Christoph Hellwig 5 participants 9 messages Oct 24, 2004 – Oct 26, 2004

Subsystems (2)
Networking TCP
lore
Share & tools
lore

Christoph Hellwig

author
#0 lore raw

PATCH 1/1 remove dead tcp exports

include/net/tcp.h +0 -1
@@ -159,7 +159,6 @@
 extern void tcp_bucket_destroy(struct tcp_bind_bucket *tb);
 extern void tcp_bucket_unlock(struct sock *sk);
 extern int tcp_port_rover;
-extern struct sock *tcp_v4_lookup_listener(u32 addr, unsigned short hnum, int dif);
 
 /* These are AF independent. */
 static __inline__ int tcp_bhashfn(__u16 lport)
net/ipv4/af_inet.c +0 -2
@@ -1165,8 +1165,6 @@
 EXPORT_SYMBOL(inet_stream_ops);
 EXPORT_SYMBOL(inet_unregister_protosw);
 EXPORT_SYMBOL(net_statistics);
-EXPORT_SYMBOL(tcp_protocol);
-EXPORT_SYMBOL(udp_protocol);
 
 #ifdef INET_REFCNT_DEBUG
 EXPORT_SYMBOL(inet_sock_nr);
net/ipv4/tcp.c +0 -1
@@ -2307,7 +2307,6 @@
 
 EXPORT_SYMBOL(tcp_accept);
 EXPORT_SYMBOL(tcp_close);
-EXPORT_SYMBOL(tcp_close_state);
 EXPORT_SYMBOL(tcp_destroy_sock);
 EXPORT_SYMBOL(tcp_disconnect);
 EXPORT_SYMBOL(tcp_getsockopt);
net/ipv4/tcp_input.c +0 -1
@@ -4963,7 +4963,6 @@
 
 EXPORT_SYMBOL(sysctl_tcp_ecn);
 EXPORT_SYMBOL(sysctl_tcp_reordering);
-EXPORT_SYMBOL(tcp_cwnd_application_limited);
 EXPORT_SYMBOL(tcp_parse_options);
 EXPORT_SYMBOL(tcp_rcv_established);
 EXPORT_SYMBOL(tcp_rcv_state_process);
net/ipv4/tcp_ipv4.c +2 -3
@@ -448,8 +448,8 @@
 }
 
 /* Optimize the common listener case. */
-inline struct sock *tcp_v4_lookup_listener(u32 daddr, unsigned short hnum,
-					   int dif)
+static inline struct sock *tcp_v4_lookup_listener(u32 daddr,
+		unsigned short hnum, int dif)
 {
 	struct sock *sk = NULL;
 	struct hlist_head *head;

@@ -2653,7 +2653,6 @@
 EXPORT_SYMBOL(tcp_v4_conn_request);
 EXPORT_SYMBOL(tcp_v4_connect);
 EXPORT_SYMBOL(tcp_v4_do_rcv);
-EXPORT_SYMBOL(tcp_v4_lookup_listener);
 EXPORT_SYMBOL(tcp_v4_rebuild_header);
 EXPORT_SYMBOL(tcp_v4_remember_stamp);
 EXPORT_SYMBOL(tcp_v4_send_check);
net/ipv4/tcp_output.c +0 -5
@@ -1719,12 +1719,7 @@
 	}
 }
 
-EXPORT_SYMBOL(tcp_acceptable_seq);
 EXPORT_SYMBOL(tcp_connect);
-EXPORT_SYMBOL(tcp_connect_init);
 EXPORT_SYMBOL(tcp_make_synack);
-EXPORT_SYMBOL(tcp_send_synack);
 EXPORT_SYMBOL(tcp_simple_retransmit);
 EXPORT_SYMBOL(tcp_sync_mss);
-EXPORT_SYMBOL(tcp_write_wakeup);
-EXPORT_SYMBOL(tcp_write_xmit);
#1 lore raw

Wheee, you had me scared for a moment. But indeed, not even tcpcp (tcpcp.sf.net) uses any of these. But I kind of wonder how you determine they're "dead" ?

- Werner

Signature · 3 lines
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         [email protected] /
/_http://www.almesberger.net/____________________________________________/
maintainer
#2 lore raw
Quoted 3 lines · On Tue, 26 Oct 2004 00:07:10 -0300 Werner Almesberger <[email protected]>…

Wheee, you had me scared for a moment. But indeed, not even tcpcp (tcpcp.sf.net) uses any of these. But I kind of wonder how you determine they're "dead" ?

There are scripts which build everything as possible as modules then greps the symbol tables of the object files to see which symbols exported by the kernel are actually used.

#3 lore raw
Quoted 3 lines · David S. Miller

There are scripts which build everything as possible as modules then greps the symbol tables of the object files to see which symbols exported by the kernel are actually used.

Hmm yes, modules maintained outside of the tree live dangerously ...

- Werner

Signature · 3 lines
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         [email protected] /
/_http://www.almesberger.net/____________________________________________/
#4 lore raw
In reply to David S. Miller
Quoted 10 lines · David S. Miller
Quoted 3 lines · On Tue, 26 Oct 2004 00:07:10 -0300 Werner Almesberger <[email protected]>…

Wheee, you had me scared for a moment. But indeed, not even tcpcp (tcpcp.sf.net) uses any of these. But I kind of wonder how you determine they're "dead" ?

There are scripts which build everything as possible as modules then greps the symbol tables of the object files to see which symbols exported by the kernel are actually used.

Is this really a compelling reason to remove them? For example ALSA provides an API for driver writers, just because a certain function happens not to be used by any does not mean is never will be or that it should not.

Lee

maintainer
#5 lore raw
Quoted 4 lines · On Tue, 26 Oct 2004 00:41:05 -0400 Lee Revell <[email protected]> wrote:

Is this really a compelling reason to remove them? For example ALSA provides an API for driver writers, just because a certain function happens not to be used by any does not mean is never will be or that it should not.

These are actually TCP internals, not a "well defined driver API" as ALSA defines.

#6 lore raw
Quoted 11 lines · David S. Miller
Quoted 4 lines · On Tue, 26 Oct 2004 00:41:05 -0400 Lee Revell <[email protected]> wrote:

Is this really a compelling reason to remove them? For example ALSA provides an API for driver writers, just because a certain function happens not to be used by any does not mean is never will be or that it should not.

These are actually TCP internals, not a "well defined driver API" as ALSA defines.

Yeah but there was also a patch posted that removed a bunch of "dead exports" from ALSA. I was wondering in general what the standard is for distinguishing the two cases.

Lee

#7 lore raw
In reply to Lee Revell
Quoted 4 lines · Lee Revell

Is this really a compelling reason to remove them? For example ALSA provides an API for driver writers, just because a certain function happens not to be used by any does not mean is never will be or that it should not.

sometimes such "spurious" exports still make sense. Most of the time they don't, and during these cleanups we've found several functions for which the only "user" was the export, eg entirely dead code. Also nobody in the entire tree using a part of the API is a pretty good sign that the API isn't good or even supposed to be used. (again, exceptions possible, which is why cleaning this stuff is manual work and not a script to just nuke it all)

author
#8 lore raw
In reply to Lee Revell
Quoted 8 lines · Lee Revell
Quoted 7 lines · David S. Miller
Quoted 3 lines · On Tue, 26 Oct 2004 00:07:10 -0300 Werner Almesberger <[email protected]>…

Wheee, you had me scared for a moment. But indeed, not even tcpcp (tcpcp.sf.net) uses any of these. But I kind of wonder how you determine they're "dead" ?

Quoted 8 lines
Quoted 3 lines

There are scripts which build everything as possible as modules then greps the symbol tables of the object files to see which symbols exported by the kernel are actually used.

Is this really a compelling reason to remove them? For example ALSA provides an API for driver writers, just because a certain function happens not to be used by any does not mean is never will be or that it should not.

I've excluded functions where I thoug hthe API makes sense. Of course I don't know all code in the kernel nor do I always make the right decision, so I ask the maintainers for their opinion.