Netdev List
 help / color / mirror / Atom feed
* Re: [ICMP]: change "struct socket *" percpu var to a "struct sock *"
From: David Miller @ 2008-01-02  3:21 UTC (permalink / raw)
  To: dada1; +Cc: netdev
In-Reply-To: <477A8A7D.3000301@cosmosbay.com>

From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 01 Jan 2008 19:46:21 +0100

> Instead of storing a pointer to a 'struct socket' and dereferencing ->sk
> to get "struct sock *" from it, just store a "struct sock *" pointer.
> 
> This saves 75 bytes of text on x86
> 
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

Applied, thanks Eric.

^ permalink raw reply

* Re: [IPSEC] flow : NUMA aware hash table allocation
From: David Miller @ 2008-01-02  3:23 UTC (permalink / raw)
  To: dada1; +Cc: netdev
In-Reply-To: <477A359F.20902@cosmosbay.com>

From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 01 Jan 2008 13:44:15 +0100

> Using __get_free_pages() has some drawbacks :
> 
> 1) Not NUMA aware
> 
> 2) 2^X page granularity :
> On arches with big PAGE_SIZE, we waste some ram for each cpu.
> 
> (We currently use 1024 pointers, that is at most 8192 bytes, but
> PAGE_SIZE can be 65536 for example : With say 64 possible cpus,
> thats about 56*64 Kbytes that are wasted)
> 
> Using kmalloc_node() can help to solve these two points.
> 
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

Applied, thanks Eric.

It reminds me that flow_hash_shift should at some point be dynamically
sized.  However, currently the flow cache isn't so heavily used and
there are more important fish to fry right now.

^ permalink raw reply

* Re: [IPSEC] flow : Remove an unecessary ____cacheline_aligned
From: David Miller @ 2008-01-02  3:24 UTC (permalink / raw)
  To: dada1; +Cc: netdev
In-Reply-To: <477A5D4D.6000800@cosmosbay.com>

From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 01 Jan 2008 16:33:33 +0100

> We use a percpu variable named flow_hash_info, which holds 12 bytes.
> 
> It is currently marked as ____cacheline_aligned, which makes linker
> skip space to properly align this variable.
> 
> Before :
> c065cc90 D per_cpu__softnet_data
> c065cd00 d per_cpu__flow_tables
> <Here, hole of 124 bytes>
> c065cd80 d per_cpu__flow_hash_info
> <Here, hole of 116 bytes>
> c065ce00 d per_cpu__flow_flush_tasklets
> c065ce14 d per_cpu__rt_cache_stat
> 
> 
> This alignement is quite unproductive, and removing it reduces the
> size of percpu data (by 240 bytes on my x86 machine), and improves
> performance (flow_tables & flow_hash_info can share a single cache
> line)
> 
> After patch :
> c065cc04 D per_cpu__softnet_data
> c065cc4c d per_cpu__flow_tables
> c065cc50 d per_cpu__flow_hash_info
> c065cc5c d per_cpu__flow_flush_tasklets
> c065cc70 d per_cpu__rt_cache_stat
> 
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

Also applied, thanks a lot for these patches Eric.

^ permalink raw reply

* Re: [2.6 patch] the scheduled shaper removal
From: David Miller @ 2008-01-02  3:27 UTC (permalink / raw)
  To: alan; +Cc: bunk, shemminger, netdev, linux-kernel
In-Reply-To: <20080101142430.27e0ef66@the-village.bc.nu>

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Tue, 1 Jan 2008 14:24:30 +0000

> On Tue, 1 Jan 2008 15:47:35 +0200
> Adrian Bunk <bunk@kernel.org> wrote:
> 
> > This patch contains the scheduled removal of the shaper driver.
> > 
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> 
> Acked-by: Alan Cox <alan@redhat.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-2.6.25] [IPV4] Remove three declarations of unimplemented methods and correct a typo in include/net/ip.h
From: David Miller @ 2008-01-02  5:13 UTC (permalink / raw)
  To: ramirose; +Cc: netdev
In-Reply-To: <eb3ff54b0801010030g36bef670n6150af5b683c4345@mail.gmail.com>

From: "Rami Rosen" <ramirose@gmail.com>
Date: Tue, 1 Jan 2008 10:30:53 +0200

> These three declarations in include/net/ip.h are not implemented
> anywhere:
> ip_mc_dropsocket(), ip_mc_dropdevice() and ip_net_unreachable().
> 
> Also, correct a comment to be "Functions provided by ip_fragment.c"
> (instead of by ip_fragment.o) in consistency with the other comments in this
> header.
> 
> Signed-off-by: Rami Rosen <ramirose@gmail.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-2.6.25] [IPV4] Remove declaration of unimplemented method and remove unused definition from include/net/ip_vs.h
From: David Miller @ 2008-01-02  5:17 UTC (permalink / raw)
  To: ramirose; +Cc: netdev
In-Reply-To: <eb3ff54b0801010119u49e2831eyfdaa001637fb8af0@mail.gmail.com>

From: "Rami Rosen" <ramirose@gmail.com>
Date: Tue, 1 Jan 2008 11:19:49 +0200

> In include/net/ip_vs.h:
> - The ip_vs_secure_tcp_set() method is not implemented anywhere.
> - IP_VS_APP_TYPE_FTP is an unused definition.
> 
> Signed-off-by: Rami Rosen <ramirose@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-2.6.25] [BRIDGE] Remove useless code in net/bridge/br_netfilter.c
From: David Miller @ 2008-01-02  5:20 UTC (permalink / raw)
  To: ramirose; +Cc: netdev
In-Reply-To: <eb3ff54b0801010248t65d296ccm481202d50fad7c4f@mail.gmail.com>

From: "Rami Rosen" <ramirose@gmail.com>
Date: Tue, 1 Jan 2008 12:48:14 +0200

> These following two commands in br_nf_forward_arp() achieve nothing and
> should be removed; the d variable is not used later in this method:
> 
> 	...
> 	struct net_device **d = (struct net_device **)(skb->cb);
> 	...
> 	*d = (struct net_device *)in;
> 	...
> 
> Signed-off-by: Rami Rosen <ramirose@gmail.com>

It's a pointer dereference assignment, this last line has a
side effect, therefore you can't remove it.

The code is equivalent to:

struct skb_bridge_info {
	struct net_device *dev;
};

	struct skb_bridge_info *d;

	d = (struct skb_bridge_info *) skb->cb;

	d->dev = in;

What automated tool showed this as useless to you?

Please correct it's logic so it doesn't mark real side effects like
this as superfluous.

Thanks.

^ permalink raw reply

* Re: [RFC: 2.6 patch] remove IrPORT and the old dongle drivers
From: David Miller @ 2008-01-02  5:20 UTC (permalink / raw)
  To: bunk; +Cc: samuel, netdev
In-Reply-To: <20080101134851.GO2360@does.not.exist>

From: Adrian Bunk <bunk@kernel.org>
Date: Tue, 1 Jan 2008 15:48:51 +0200

> This patch removes IrPORT and the old dongle drivers (all off them 
> have replacement drivers).
> 
> Signed-off-by: Adrian Bunk <bunk@kernel.org>

I'll let Sam make the call on this one.

^ permalink raw reply

* [NET] Sparse annotations
From: Eric Dumazet @ 2008-01-02  5:50 UTC (permalink / raw)
  To: David S. Miller; +Cc: Linux Netdev List

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

Add __acquires() and __releases() annotations to suppress some sparse warnings.

example of warnings :

net/ipv4/udp.c:1555:14: warning: context imbalance in 'udp_seq_start' - wrong 
count at exit
net/ipv4/udp.c:1571:13: warning: context imbalance in 'udp_seq_stop' - 
unexpected unlock


Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

  net/core/dev.c             |    2 ++
  net/core/dev_mcast.c       |    2 ++
  net/core/gen_stats.c       |    1 +
  net/core/neighbour.c       |    2 ++
  net/core/sock.c            |    2 ++
  net/ipv4/fib_hash.c        |    2 ++
  net/ipv4/inet_hashtables.c |    1 +
  net/ipv4/udp.c             |    2 ++
  net/ipv6/anycast.c         |    2 ++
  net/ipv6/ip6_flowlabel.c   |    2 ++
  net/ipv6/mcast.c           |    4 ++++
  net/netlink/af_netlink.c   |    4 ++++
  net/sched/sch_generic.c    |    4 ++++
  net/sunrpc/cache.c         |    2 ++
  net/unix/af_unix.c         |    2 ++
  net/xfrm/xfrm_state.c      |    2 ++
  16 files changed, 36 insertions(+)


[-- Attachment #2: net_sparse.patch --]
[-- Type: text/plain, Size: 10495 bytes --]

diff --git a/net/core/dev.c b/net/core/dev.c
index aca6dad..ea43c02 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2364,6 +2364,7 @@ static int dev_ifconf(struct net *net, char __user *arg)
  *	in detail.
  */
 void *dev_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(dev_base_lock)
 {
 	struct net *net = seq_file_net(seq);
 	loff_t off;
@@ -2390,6 +2391,7 @@ void *dev_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 void dev_seq_stop(struct seq_file *seq, void *v)
+	__releases(dev_base_lock)
 {
 	read_unlock(&dev_base_lock);
 }
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 63f0b33..cadbfbf 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -186,6 +186,7 @@ EXPORT_SYMBOL(dev_mc_unsync);
 
 #ifdef CONFIG_PROC_FS
 static void *dev_mc_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(dev_base_lock)
 {
 	struct net *net = seq_file_net(seq);
 	struct net_device *dev;
@@ -206,6 +207,7 @@ static void *dev_mc_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void dev_mc_seq_stop(struct seq_file *seq, void *v)
+	__releases(dev_base_lock)
 {
 	read_unlock(&dev_base_lock);
 }
diff --git a/net/core/gen_stats.c b/net/core/gen_stats.c
index bcc2559..8073561 100644
--- a/net/core/gen_stats.c
+++ b/net/core/gen_stats.c
@@ -55,6 +55,7 @@ rtattr_failure:
 int
 gnet_stats_start_copy_compat(struct sk_buff *skb, int type, int tc_stats_type,
 	int xstats_type, spinlock_t *lock, struct gnet_dump *d)
+	__acquires(lock)
 {
 	memset(d, 0, sizeof(*d));
 
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index bd899d5..8024933 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -2313,6 +2313,7 @@ static void *neigh_get_idx_any(struct seq_file *seq, loff_t *pos)
 }
 
 void *neigh_seq_start(struct seq_file *seq, loff_t *pos, struct neigh_table *tbl, unsigned int neigh_seq_flags)
+	__acquires(tbl->lock)
 {
 	struct neigh_seq_state *state = seq->private;
 	loff_t pos_minus_one;
@@ -2356,6 +2357,7 @@ out:
 EXPORT_SYMBOL(neigh_seq_next);
 
 void neigh_seq_stop(struct seq_file *seq, void *v)
+	__releases(tbl->lock)
 {
 	struct neigh_seq_state *state = seq->private;
 	struct neigh_table *tbl = state->tbl;
diff --git a/net/core/sock.c b/net/core/sock.c
index 3804e7d..3d7757e 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2025,6 +2025,7 @@ EXPORT_SYMBOL(proto_unregister);
 
 #ifdef CONFIG_PROC_FS
 static void *proto_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(proto_list_lock)
 {
 	read_lock(&proto_list_lock);
 	return seq_list_start_head(&proto_list, *pos);
@@ -2036,6 +2037,7 @@ static void *proto_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void proto_seq_stop(struct seq_file *seq, void *v)
+	__releases(proto_list_lock)
 {
 	read_unlock(&proto_list_lock);
 }
diff --git a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c
index 481de47..d32385c 100644
--- a/net/ipv4/fib_hash.c
+++ b/net/ipv4/fib_hash.c
@@ -935,6 +935,7 @@ static struct fib_alias *fib_get_idx(struct seq_file *seq, loff_t pos)
 }
 
 static void *fib_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(fib_hash_lock)
 {
 	void *v = NULL;
 
@@ -951,6 +952,7 @@ static void *fib_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void fib_seq_stop(struct seq_file *seq, void *v)
+	__releases(fib_hash_lock)
 {
 	read_unlock(&fib_hash_lock);
 }
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 2e5814a..88a059e 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -96,6 +96,7 @@ EXPORT_SYMBOL(inet_put_port);
  * exclusive lock release). It should be ifdefed really.
  */
 void inet_listen_wlock(struct inet_hashinfo *hashinfo)
+	__acquires(hashinfo->lhash_lock)
 {
 	write_lock(&hashinfo->lhash_lock);
 
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 3532843..02fcccd 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1550,6 +1550,7 @@ static struct sock *udp_get_idx(struct seq_file *seq, loff_t pos)
 }
 
 static void *udp_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(udp_hash_lock)
 {
 	read_lock(&udp_hash_lock);
 	return *pos ? udp_get_idx(seq, *pos-1) : (void *)1;
@@ -1569,6 +1570,7 @@ static void *udp_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void udp_seq_stop(struct seq_file *seq, void *v)
+	__releases(udp_hash_lock)
 {
 	read_unlock(&udp_hash_lock);
 }
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index f915c4d..5c41900 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -504,6 +504,7 @@ static struct ifacaddr6 *ac6_get_idx(struct seq_file *seq, loff_t pos)
 }
 
 static void *ac6_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(dev_base_lock)
 {
 	read_lock(&dev_base_lock);
 	return ac6_get_idx(seq, *pos);
@@ -518,6 +519,7 @@ static void *ac6_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void ac6_seq_stop(struct seq_file *seq, void *v)
+	__releases(dev_base_lock)
 {
 	struct ac6_iter_state *state = ac6_seq_private(seq);
 	if (likely(state->idev != NULL)) {
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index d0babea..2b7d9ee 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -629,6 +629,7 @@ static struct ip6_flowlabel *ip6fl_get_idx(struct seq_file *seq, loff_t pos)
 }
 
 static void *ip6fl_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(ip6_fl_lock)
 {
 	read_lock_bh(&ip6_fl_lock);
 	return *pos ? ip6fl_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
@@ -647,6 +648,7 @@ static void *ip6fl_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void ip6fl_seq_stop(struct seq_file *seq, void *v)
+	__releases(ip6_fl_lock)
 {
 	read_unlock_bh(&ip6_fl_lock);
 }
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 82b1294..ab228d1 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -2373,6 +2373,7 @@ static struct ifmcaddr6 *igmp6_mc_get_idx(struct seq_file *seq, loff_t pos)
 }
 
 static void *igmp6_mc_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(dev_base_lock)
 {
 	read_lock(&dev_base_lock);
 	return igmp6_mc_get_idx(seq, *pos);
@@ -2387,6 +2388,7 @@ static void *igmp6_mc_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void igmp6_mc_seq_stop(struct seq_file *seq, void *v)
+	__releases(dev_base_lock)
 {
 	struct igmp6_mc_iter_state *state = igmp6_mc_seq_private(seq);
 	if (likely(state->idev != NULL)) {
@@ -2516,6 +2518,7 @@ static struct ip6_sf_list *igmp6_mcf_get_idx(struct seq_file *seq, loff_t pos)
 }
 
 static void *igmp6_mcf_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(dev_base_lock)
 {
 	read_lock(&dev_base_lock);
 	return *pos ? igmp6_mcf_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
@@ -2533,6 +2536,7 @@ static void *igmp6_mcf_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void igmp6_mcf_seq_stop(struct seq_file *seq, void *v)
+	__releases(dev_base_lock)
 {
 	struct igmp6_mcf_iter_state *state = igmp6_mcf_seq_private(seq);
 	if (likely(state->im != NULL)) {
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index dbd7cad..be07f1b 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -171,6 +171,7 @@ static void netlink_sock_destruct(struct sock *sk)
  */
 
 static void netlink_table_grab(void)
+	__acquires(nl_table_lock)
 {
 	write_lock_irq(&nl_table_lock);
 
@@ -193,6 +194,7 @@ static void netlink_table_grab(void)
 }
 
 static inline void netlink_table_ungrab(void)
+	__releases(nl_table_lock)
 {
 	write_unlock_irq(&nl_table_lock);
 	wake_up(&nl_table_wait);
@@ -1728,6 +1730,7 @@ static struct sock *netlink_seq_socket_idx(struct seq_file *seq, loff_t pos)
 }
 
 static void *netlink_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(nl_table_lock)
 {
 	read_lock(&nl_table_lock);
 	return *pos ? netlink_seq_socket_idx(seq, *pos - 1) : SEQ_START_TOKEN;
@@ -1776,6 +1779,7 @@ static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void netlink_seq_stop(struct seq_file *seq, void *v)
+	__releases(nl_table_lock)
 {
 	read_unlock(&nl_table_lock);
 }
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 9be2f15..ea5a05b 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -40,12 +40,16 @@
  */
 
 void qdisc_lock_tree(struct net_device *dev)
+	__acquires(dev->queue_lock)
+	__acquires(dev->ingress_lock)
 {
 	spin_lock_bh(&dev->queue_lock);
 	spin_lock(&dev->ingress_lock);
 }
 
 void qdisc_unlock_tree(struct net_device *dev)
+	__releases(dev->ingress_lock)
+	__releases(dev->queue_lock)
 {
 	spin_unlock(&dev->ingress_lock);
 	spin_unlock_bh(&dev->queue_lock);
diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
index 8e05557..73f053d 100644
--- a/net/sunrpc/cache.c
+++ b/net/sunrpc/cache.c
@@ -1127,6 +1127,7 @@ struct handle {
 };
 
 static void *c_start(struct seq_file *m, loff_t *pos)
+	__acquires(cd->hash_lock)
 {
 	loff_t n = *pos;
 	unsigned hash, entry;
@@ -1183,6 +1184,7 @@ static void *c_next(struct seq_file *m, void *p, loff_t *pos)
 }
 
 static void c_stop(struct seq_file *m, void *p)
+	__releases(cd->hash_lock)
 {
 	struct cache_detail *cd = ((struct handle*)m->private)->cd;
 	read_unlock(&cd->hash_lock);
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 63a9239..eea7588 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2033,6 +2033,7 @@ static struct sock *unix_seq_idx(struct unix_iter_state *iter, loff_t pos)
 
 
 static void *unix_seq_start(struct seq_file *seq, loff_t *pos)
+	__acquires(unix_table_lock)
 {
 	struct unix_iter_state *iter = seq->private;
 	spin_lock(&unix_table_lock);
@@ -2055,6 +2056,7 @@ static void *unix_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 }
 
 static void unix_seq_stop(struct seq_file *seq, void *v)
+	__releases(unix_table_lock)
 {
 	spin_unlock(&unix_table_lock);
 }
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 8a9166c..4dec655 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -211,6 +211,7 @@ static struct xfrm_state_afinfo *xfrm_state_lock_afinfo(unsigned int family)
 }
 
 static void xfrm_state_unlock_afinfo(struct xfrm_state_afinfo *afinfo)
+	__releases(xfrm_state_afinfo_lock)
 {
 	write_unlock_bh(&xfrm_state_afinfo_lock);
 }
@@ -1907,6 +1908,7 @@ static struct xfrm_state_afinfo *xfrm_state_get_afinfo(unsigned int family)
 }
 
 static void xfrm_state_put_afinfo(struct xfrm_state_afinfo *afinfo)
+	__releases(xfrm_state_afinfo_lock)
 {
 	read_unlock(&xfrm_state_afinfo_lock);
 }

^ permalink raw reply related

* Re: [NET] Sparse annotations
From: David Miller @ 2008-01-02  5:58 UTC (permalink / raw)
  To: dada1; +Cc: netdev
In-Reply-To: <477B2616.4090409@cosmosbay.com>

From: Eric Dumazet <dada1@cosmosbay.com>
Date: Wed, 02 Jan 2008 06:50:14 +0100

> Add __acquires() and __releases() annotations to suppress some sparse warnings.
> 
> example of warnings :
> 
> net/ipv4/udp.c:1555:14: warning: context imbalance in 'udp_seq_start' - wrong 
> count at exit
> net/ipv4/udp.c:1571:13: warning: context imbalance in 'udp_seq_stop' - 
> unexpected unlock
> 
> 
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

Applied, thanks Eric.

^ permalink raw reply

* Re: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
From: Greg KH @ 2008-01-02  6:00 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andreas Mohr, Ingo Molnar, Alexey Dobriyan, Andrew Morton,
	David Woodhouse, Eric W. Biederman, Linus Torvalds,
	Rafael J. Wysocki, Pavel Machek, kernel list, netdev,
	Pavel Emelyanov, Denis V. Lunev, USB list
In-Reply-To: <20071231192643.GA25341@kroah.com>

On Mon, Dec 31, 2007 at 11:26:43AM -0800, Greg KH wrote:
> On Mon, Dec 31, 2007 at 12:49:52PM -0500, Alan Stern wrote:
> > On Sun, 30 Dec 2007, Greg KH wrote:
> > 
> > > > It looks like Greg misused the debugfs API -- which is ironic, because
> > > > he wrote debugfs in the first place!  :-)
> > > 
> > > Oh crap, sorry, I did mess that up :(

Ok, no, I didn't write that patch, I'm getting very confused here.

In 2.6.24-rc6 there is no usage of debugfs in the ohci driver.

In the -mm tree there is a patch, from Tony Jones, that moves some debug
code out of sysfs and into debugfs where it belongs.  It does it for
both the ehci and ohci USB host controller drivers, and this is the code
that is incorrect if CONFIG_DEBUGFS is not enabled.

So, for the 2.6.24 release, nothing needs to be changed, all is good,
and there is no regression.

Right?  Or am I still confused about this whole thing?

I will go fix up Tony's patches in the -mm tree that do not handle the
error return values from debugfs properly, but that is not such a rush,
as Tony is on vacation for a few weeks, and those patches are going to
be going in only after 2.6.24 is out.

Hm, I wonder if this means I can go back to drinking more holiday
wine... :)

thanks,

greg k-h

^ permalink raw reply

* Re: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
From: Andreas Mohr @ 2008-01-02  6:04 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andreas Mohr, Ingo Molnar, Alexey Dobriyan, Andrew Morton,
	David Woodhouse, Eric W. Biederman, Linus Torvalds,
	Rafael J. Wysocki, Pavel Machek, kernel list, netdev,
	Pavel Emelyanov, Denis V. Lunev, Greg KH
In-Reply-To: <Pine.LNX.4.44L0.0712301526090.1963-100000@netrider.rowland.org>

Hi,

On Sun, Dec 30, 2007 at 03:34:45PM -0500, Alan Stern wrote:
> It looks like Greg misused the debugfs API -- which is ironic, because
> he wrote debugfs in the first place!  :-)
> 
> Let me know if this patch fixes the problem.  If it does, I'll submit 
> it to Greg with all the proper accoutrements.

Finally a 2.6.24-rc6-mm1 with working USB WLAN. :)
IOW I can confirm that this was the cause of the USB problem I was having.

Thanks!

Andreas Mohr

^ permalink raw reply

* Re: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
From: Andreas Mohr @ 2008-01-02  6:13 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Stern, Andreas Mohr, Ingo Molnar, Alexey Dobriyan,
	Andrew Morton, David Woodhouse, Eric W. Biederman, Linus Torvalds,
	Rafael J. Wysocki, Pavel Machek, kernel list, netdev,
	Pavel Emelyanov, Denis V. Lunev, USB list
In-Reply-To: <20080102060006.GA27693@kroah.com>

Hi,

On Tue, Jan 01, 2008 at 10:00:06PM -0800, Greg KH wrote:
> Ok, no, I didn't write that patch, I'm getting very confused here.
> 
> In 2.6.24-rc6 there is no usage of debugfs in the ohci driver.
> 
> In the -mm tree there is a patch, from Tony Jones, that moves some debug
> code out of sysfs and into debugfs where it belongs.  It does it for
> both the ehci and ohci USB host controller drivers, and this is the code
> that is incorrect if CONFIG_DEBUGFS is not enabled.
> 
> So, for the 2.6.24 release, nothing needs to be changed, all is good,
> and there is no regression.
> 
> Right?  Or am I still confused about this whole thing?

Probably, since I also wasn't sure about this getting added to the
post-2.6.23 regressions. I'd expect this problem to be -mm only myself,
but then I didn't actively verify it in code (and I haven't tried -rc6
proper on that machine yet either, build takes ages ;).
OK, since I cannot really offer anything other than positive feelings about
this being non-rc6 breakage, should I try -rc6 proper, too?

> Hm, I wonder if this means I can go back to drinking more holiday
> wine... :)

.....even more confusion? :)

Thanks for your help,

Andreas Mohr

^ permalink raw reply

* Re: [PATCH net-2.6.25] [BRIDGE] Remove useless code in net/bridge/br_netfilter.c
From: Rami Rosen @ 2008-01-02  6:16 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20080101.212026.187527188.davem@davemloft.net>

Hi,
> It's a pointer dereference assignment,
Sorry, I was wrong here !

> What automated tool showed this as useless to you?
> Please correct it's logic so it doesn't mark real side effects like
> this as superfluous.

I am not using any automated tool, only my eyes. And I
missed the intention here. It could be implemnted differently
but since it not marked as superfluous anywhere I suggest
to leave it as it is.

Sorry,

Regards,
Rami Rosen





On Jan 2, 2008 7:20 AM, David Miller <davem@davemloft.net> wrote:
> From: "Rami Rosen" <ramirose@gmail.com>
> Date: Tue, 1 Jan 2008 12:48:14 +0200
>
> > These following two commands in br_nf_forward_arp() achieve nothing and
> > should be removed; the d variable is not used later in this method:
> >
> >       ...
> >       struct net_device **d = (struct net_device **)(skb->cb);
> >       ...
> >       *d = (struct net_device *)in;
> >       ...
> >
> > Signed-off-by: Rami Rosen <ramirose@gmail.com>
>
> It's a pointer dereference assignment, this last line has a
> side effect, therefore you can't remove it.
>
> The code is equivalent to:
>
> struct skb_bridge_info {
>         struct net_device *dev;
> };
>
>         struct skb_bridge_info *d;
>
>         d = (struct skb_bridge_info *) skb->cb;
>
>         d->dev = in;
>
> What automated tool showed this as useless to you?
>
> Please correct it's logic so it doesn't mark real side effects like
> this as superfluous.
>
> Thanks.
>

^ permalink raw reply

* Re: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
From: Greg KH @ 2008-01-02  7:14 UTC (permalink / raw)
  To: Andreas Mohr
  Cc: Alan Stern, Ingo Molnar, Alexey Dobriyan, Andrew Morton,
	David Woodhouse, Eric W. Biederman, Linus Torvalds,
	Rafael J. Wysocki, Pavel Machek, kernel list, netdev,
	Pavel Emelyanov, Denis V. Lunev, USB list
In-Reply-To: <20080102061308.GB30929-p/qQFhXj4MHA4IYVXhSI5GHfThorsUsI@public.gmane.org>

On Wed, Jan 02, 2008 at 07:13:08AM +0100, Andreas Mohr wrote:
> Hi,
> 
> On Tue, Jan 01, 2008 at 10:00:06PM -0800, Greg KH wrote:
> > Ok, no, I didn't write that patch, I'm getting very confused here.
> > 
> > In 2.6.24-rc6 there is no usage of debugfs in the ohci driver.
> > 
> > In the -mm tree there is a patch, from Tony Jones, that moves some debug
> > code out of sysfs and into debugfs where it belongs.  It does it for
> > both the ehci and ohci USB host controller drivers, and this is the code
> > that is incorrect if CONFIG_DEBUGFS is not enabled.
> > 
> > So, for the 2.6.24 release, nothing needs to be changed, all is good,
> > and there is no regression.
> > 
> > Right?  Or am I still confused about this whole thing?
> 
> Probably, since I also wasn't sure about this getting added to the
> post-2.6.23 regressions. I'd expect this problem to be -mm only myself,
> but then I didn't actively verify it in code (and I haven't tried -rc6
> proper on that machine yet either, build takes ages ;).
> OK, since I cannot really offer anything other than positive feelings about
> this being non-rc6 breakage, should I try -rc6 proper, too?

Please do, that would be very helpful.

As the code being discussed isn't even in Linus's tree, it's hard to see
how this could be a proposed fix for the regression :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [IPSEC]: Return EOVERFLOW when output sequence number overflows
From: Herbert Xu @ 2008-01-02  7:16 UTC (permalink / raw)
  To: David S. Miller, netdev

Hi Dave:

[IPSEC]: Return EOVERFLOW when output sequence number overflows

Previously we made it an error on the output path if the sequence number
overflowed.  However we did not set the err variable accordingly.  This
patch sets err to -EOVERFLOW in that case.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 81ad8eb..f4a1047 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -66,6 +66,7 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
 			if (unlikely(x->replay.oseq == 0)) {
 				x->replay.oseq--;
 				xfrm_audit_state_replay_overflow(x, skb);
+				err = -EOVERFLOW;
 				goto error;
 			}
 			if (xfrm_aevent_is_on())

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply related

* Re: [IPSEC]: Return EOVERFLOW when output sequence number overflows
From: David Miller @ 2008-01-02  7:53 UTC (permalink / raw)
  To: herbert; +Cc: netdev
In-Reply-To: <20080102071619.GA23687@gondor.apana.org.au>

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 2 Jan 2008 18:16:20 +1100

> [IPSEC]: Return EOVERFLOW when output sequence number overflows
> 
> Previously we made it an error on the output path if the sequence number
> overflowed.  However we did not set the err variable accordingly.  This
> patch sets err to -EOVERFLOW in that case.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied.

It seems this was a regression added by Paul's patch in net-2.6.25 and
not something that needs fixing in 2.6.24 and stable?

^ permalink raw reply

* Re: TCP event tracking via netlink...
From: David Miller @ 2008-01-02  8:22 UTC (permalink / raw)
  To: shemminger; +Cc: ilpo.jarvinen, netdev
In-Reply-To: <20071206092312.79a83208@freepuppy.rosehill>

From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Thu, 6 Dec 2007 09:23:12 -0800

> Tools and scripts for testing that generate graphs are at:
> 	git://git.kernel.org/pub/scm/tcptest/tcptest

Did you move it somewhere else?

davem@sunset:~/src/GIT$ git clone git://git.kernel.org/pub/scm/tcptest/tcptest
Initialized empty Git repository in /home/davem/src/GIT/tcptest/.git/
fatal: The remote end hung up unexpectedly
fetch-pack from 'git://git.kernel.org/pub/scm/tcptest/tcptest' failed.

^ permalink raw reply

* Re: [IPSEC]: Return EOVERFLOW when output sequence number overflows
From: Herbert Xu @ 2008-01-02  8:25 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20080101.235342.183794044.davem@davemloft.net>

On Tue, Jan 01, 2008 at 11:53:42PM -0800, David Miller wrote:
>
> It seems this was a regression added by Paul's patch in net-2.6.25 and
> not something that needs fixing in 2.6.24 and stable?

Yes this is brand new so we don't need it for 2.6.24.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: [patch] add tcp congestion control relevant parts
From: Michael Kerrisk @ 2008-01-02  9:55 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Michael Kerrisk, netdev, linux-net, Thomas Egerer, linux-man
In-Reply-To: <20071214081540.4596bf21@deepthought>



Stephen Hemminger wrote:
> On Fri, 14 Dec 2007 09:48:32 +0100
> Michael Kerrisk <mtk.manpages@googlemail.com> wrote:
> 
>> Hello Linux networking folk,
>>
>> I received the patch below for the tcp.7 man page.  Would anybody here be
>> prepared to review the new material / double check the details?
>>
>> Cheers,
>>
>> Michael
>>
>> -------- Original Message --------
>> Subject: [patch] add tcp congestion control relevant parts
>> Date: Wed, 12 Dec 2007 16:40:23 +0100
>> From: Thomas Egerer <thomas.Egerer@secunet.com>
>> To: mtk.manpages@gmail.com
>> CC: linux-man@vger.kernel.org
>>
>> Hello *,
>>
>> man-pages version : 2.70 from http://www.kernel.org/pub/linux/docs/man-pages/
>> All required information were obtained by reading the kernel
>> code/documentation.
>> I'm not sure, whether it is completely bullet proof on when the sysctl
>> variables/socket option first appeared in the kernel, so you might as well
>> drop this information, but I'm pretty sure about how it works.
>> Here we go with my patch:
>>
>> diff -ru man-pages-2.70/man7/tcp.7 man-pages-2.70.new/man7/tcp.7
>> --- man-pages-2.70/man7/tcp.7   2007-11-24 14:33:34.000000000 +0100
>> +++ man-pages-2.70.new/man7/tcp.7       2007-12-12 16:34:52.000000000 +0100
>> @@ -177,8 +177,6 @@
>>  .\" FIXME As at Sept 2006, kernel 2.6.18-rc5, the following are
>>  .\"    not yet documented (shown with default values):
>>  .\"
>> -.\"     /proc/sys/net/ipv4/tcp_congestion_control (since 2.6.13)
>> -.\"     bic
>>  .\"     /proc/sys/net/ipv4/tcp_moderate_rcvbuf
>>  .\"     1
>>  .\"     /proc/sys/net/ipv4/tcp_no_metrics_save
>> @@ -224,6 +222,20 @@
>>  are reserved for the application buffer.
>>  A value of 0
>>  implies that no amount is reserved.
>> +.TP
>> +.BR tcp_allowed_congestion_control \
>> +" (String; default: cubic reno) (since 2.6.13) "
>> +Show/set the congestion control choices available to non-privileged
>> +processes. The list is a subset of those listed in
>> +.IR tcp_available_congestion_control "."
>> +Default is "cubic reno" and the default setting
>> +.RI ( tcp_congestion_control ).
>> +.TP
>> +.BR tcp_available_congestion_control \
>> +" (String; default: cubic reno) (since 2.6.13) "
>> +Lists the TCP congestion control algorithms available on the system. This
>> value
>> +can only be changed by loading/unloading modules responsible for congestion
>> +control.
>>  .\"
>>  .\" The following is from 2.6.12: Documentation/networking/ip-sysctl.txt
>>  .TP
>> @@ -257,6 +269,17 @@
>>  Allows two flows sharing the same connection to converge
>>  more rapidly.
>>  .TP
>> +.BR tcp_congestion_control " (String; default: cubic reno) (since 2.6.13) "
>> +Determines the congestion control algorithm used for newly created TCP
>> +sockets. By default Linux uses cubic with reno as fallback. If you want
>> +to have more control over the algorithm used, you must enable the symbol
>> +CONFIG_TCP_CONG_ADVANCED in your kernel config.
> 
> You can choose the default congestion control as well as part of the kernel
> configuration.

Hi Stephen,

Other than this, did the doc patch look okay?  (I'm not sure whether there
was an implied ACK in your message for the rest of the patch.)

Cheers,

Michael

-- 
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug?  Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html



^ permalink raw reply

* Re: iproute2 syntax change in tc police?
From: Andreas Henriksson @ 2008-01-02 10:14 UTC (permalink / raw)
  To: shemminger; +Cc: netdev, Patrick McHardy
In-Reply-To: <1199230752.16358.22.camel@localhost.localdomain>


On ons, 2008-01-02 at 00:39 +0100, Andreas Henriksson wrote:
[...]
> Commands like "tc filter add dev ppp0 parent ffff: protocol ip prio 50
> u32 match ip src 0.0.0.0/0 police rate 4mbit burst 10k drop flowid :1"
> apparently no longer works. The flowid is not accepted anymore.
> Reverting commit 720a2e8d99... which you authored seems to "fix" this.
[...]


After further investigation it seems clear to me that reverting the
commit 720a2e8d990707749b2... is the correct thing to do, since the real
fix for the problem this commit was supposed to fix was instead fixed in
commit c29391c7c68f031e246c...

Whatever you specify after a u32 police you will now get a syntax error,
and according to "tc filter add u32 help" there are several things that
you are supposed to be able to specify after a police.

So, Steven, please revert 720a2e8d990707749b2...


-- 
Regards,
Andreas Henriksson


^ permalink raw reply

* Re: [PATCH] Force UNIX domain sockets to be built in
From: Herbert Xu @ 2008-01-02 10:25 UTC (permalink / raw)
  To: Theodore Tso
  Cc: 7eggert, viro, davem, jengelh, devzero, linux-kernel, bunk,
	netdev
In-Reply-To: <20080101050154.GG11776@mit.edu>

Theodore Tso <tytso@mit.edu> wrote:
>
> The question is whether the size of the Unix domain sockets support is
> worth the complexity of yet another config option that we expose to
> the user.  For the embedded world, OK, maybe they want to save 14k of
> non-swappable memory.  But for the non-embedded world, given the 117k
> mandatory memory usage of sysfs, or the 124k memory usage of the core
> networking stack, never mind the 3 megabytes of memory used by objects
> in the kernel subdirectory, it's not clear that it's worth worrying
> over 14k of memory, especially when many Unix programs assume
> that Unix Domain Sockets are present.

That would make sense if we were proposing to get rid of the CONFIG_UNIX
question altogether for !CONFIG_EMBEDDED.  However, the proposal here is
merely to eliminate the modular option but the CONFIG_UNIX prompt itself
will remain even without CONFIG_EMBEDDED.

This I think is quite pointless.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: TCP event tracking via netlink...
From: Ilpo Järvinen @ 2008-01-02 11:05 UTC (permalink / raw)
  To: David Miller; +Cc: Stephen Hemminger, Netdev
In-Reply-To: <20080102.002227.67777942.davem@davemloft.net>

On Wed, 2 Jan 2008, David Miller wrote:

> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Thu, 6 Dec 2007 09:23:12 -0800
> 
> > Tools and scripts for testing that generate graphs are at:
> > 	git://git.kernel.org/pub/scm/tcptest/tcptest
> 
> Did you move it somewhere else?
> 
> davem@sunset:~/src/GIT$ git clone git://git.kernel.org/pub/scm/tcptest/tcptest
> Initialized empty Git repository in /home/davem/src/GIT/tcptest/.git/
> fatal: The remote end hung up unexpectedly
> fetch-pack from 'git://git.kernel.org/pub/scm/tcptest/tcptest' failed.

.../network/ was missing from the path :-).

$ git-remote show origin
* remote origin
  URL: git://git.kernel.org/pub/scm/network/tcptest/tcptest.git
  Remote branch(es) merged with 'git pull' while on branch master
    master
  Tracked remote branches
    master


-- 
 i.

^ permalink raw reply

* Re: iproute2 syntax change in tc police?
From: Denys Fedoryshchenko @ 2008-01-02  0:43 UTC (permalink / raw)
  To: Andreas Henriksson, Patrick McHardy; +Cc: netdev
In-Reply-To: <1199230752.16358.22.camel@localhost.localdomain>

Maybe something like 
-tc filter add dev ppp0 parent ffff: protocol ip prio 50 u32 match ip src 
0.0.0.0/0 police rate 4mbit burst 10k drop flowid :1
+tc filter add dev ppp0 parent ffff: protocol ip prio 50 u32 match ip src 
0.0.0.0/0 flowid :1 police rate 4mbit burst 10k drop 

I can't test it now, but in my case moving flowid BEFORE police (or somewhere 
else "before", i dont remeber well) - helped.

On Wed, 02 Jan 2008 00:39:11 +0100, Andreas Henriksson wrote
> Hello Patrick McHardy!
> 
> We have recently updated iproute in debian and have reports about the
> new version breaking shorewall generated scripts.
> 
> The original bug-report can be found at:
> http://bugs.debian.org/458539
> 
> Commands like "tc filter add dev ppp0 parent ffff: protocol ip prio 
> 50 u32 match ip src 0.0.0.0/0 police rate 4mbit burst 10k drop 
> flowid :1" apparently no longer works. The flowid is not accepted anymore.
> Reverting commit 720a2e8d99... which you authored seems to "fix" this.
> 
> http://git.kernel.org/?p=linux/kernel/git/shemminger/
iproute2.git;a=commitdiff;h=720a2e8d990707749b2cafa77ab3cd2b8241ec47
> 
> I guess the flowid is invalid syntax, but that it just got ignored
> instead of caught before... 
> Could you please have a look and tell me what you think about this?
> 
> -- 
> Regards,
> Andreas Henriksson
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.


^ permalink raw reply

* Re: [PATCH] Force UNIX domain sockets to be built in
From: Bodo Eggert @ 2008-01-02 12:26 UTC (permalink / raw)
  To: Herbert Xu
  Cc: Theodore Tso, 7eggert, viro, davem, jengelh, devzero,
	linux-kernel, bunk, netdev
In-Reply-To: <E1JA0mT-0008U2-00@gondolin.me.apana.org.au>

On Wed, 2 Jan 2008, Herbert Xu wrote:
> Theodore Tso <tytso@mit.edu> wrote:

> > The question is whether the size of the Unix domain sockets support is
> > worth the complexity of yet another config option that we expose to
> > the user.  For the embedded world, OK, maybe they want to save 14k of
> > non-swappable memory.  But for the non-embedded world, given the 117k
> > mandatory memory usage of sysfs, or the 124k memory usage of the core
> > networking stack, never mind the 3 megabytes of memory used by objects
> > in the kernel subdirectory, it's not clear that it's worth worrying
> > over 14k of memory, especially when many Unix programs assume
> > that Unix Domain Sockets are present.
> 
> That would make sense if we were proposing to get rid of the CONFIG_UNIX
> question altogether for !CONFIG_EMBEDDED.

Exactly this is what my patch does: The question is not to be displayed 
unless EMBEDDED, and the default is changed to y.

>  However, the proposal here is
> merely to eliminate the modular option but the CONFIG_UNIX prompt itself
> will remain even without CONFIG_EMBEDDED.
> 
> This I think is quite pointless.

That's what another patch would do. I decided that s/tristate/bool/ is 
something completely different from adding the default and hiding the 
option, and that I'd avoid this discussion by not eliminating UNIX=m.

-- 
Top 100 things you don't want the sysadmin to say:
96. That's SOOOOO bizarre.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox