--- 1.96/include/net/tcp.h 2004-10-21 06:58:39 +02:00
+++ edited/include/net/tcp.h 2004-10-23 13:54:49 +02:00
@@ -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)
--- 1.77/net/ipv4/af_inet.c 2004-09-23 07:26:42 +02:00
+++ edited/net/ipv4/af_inet.c 2004-10-23 13:53:38 +02:00
@@ -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);
--- 1.81/net/ipv4/tcp.c 2004-10-03 23:26:12 +02:00
+++ edited/net/ipv4/tcp.c 2004-10-23 13:50:23 +02:00
@@ -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);
--- 1.81/net/ipv4/tcp_input.c 2004-10-03 23:31:39 +02:00
+++ edited/net/ipv4/tcp_input.c 2004-10-23 13:52:46 +02:00
@@ -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);
--- 1.101/net/ipv4/tcp_ipv4.c 2004-10-20 06:50:24 +02:00
+++ edited/net/ipv4/tcp_ipv4.c 2004-10-23 13:55:16 +02:00
@@ -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);
--- 1.70/net/ipv4/tcp_output.c 2004-10-22 07:37:25 +02:00
+++ edited/net/ipv4/tcp_output.c 2004-10-23 13:57:15 +02:00
@@ -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);
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
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
On Tue, 26 Oct 2004 00:07:10 -0300
Werner Almesberger <[email protected]> wrote:
> 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.
David S. Miller wrote:
> 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
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
On Mon, 2004-10-25 at 20:41 -0700, David S. Miller wrote:
> On Tue, 26 Oct 2004 00:07:10 -0300
> Werner Almesberger <[email protected]> wrote:
>
> > 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
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.
On Mon, 2004-10-25 at 21:52 -0700, David S. Miller wrote:
> 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
On Tue, 2004-10-26 at 00:41 -0400, Lee Revell 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.
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)
--
On Tue, Oct 26, 2004 at 12:41:05AM -0400, Lee Revell wrote:
> On Mon, 2004-10-25 at 20:41 -0700, David S. Miller wrote:
> > On Tue, 26 Oct 2004 00:07:10 -0300
> > Werner Almesberger <[email protected]> wrote:
> >
> > > 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.
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.