[PATCH] genetlink: don't touch module ref count
Increasing the module ref count at registration will block the module from
ever being unloaded. In fact, genetlink should not care about the owner at
all. This patch removes the owner field from the struct registered with
genetlink.
Signed-off-by: Per Liden [EMAIL PROTECTED]
---
include/net/genetlink.h |1 -
net/netlink/genetlink.c |7 ---
net/tipc/netlink.c |1 -
3 files changed, 0 insertions(+), 9 deletions(-)
4647eec00ae3dc1be979f5387d766529cb64e29c
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index c5b96b2..805de50 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -22,7 +22,6 @@ struct genl_family
charname[GENL_NAMSIZ];
unsigned intversion;
unsigned intmaxattr;
- struct module * owner;
struct nlattr **attrbuf;/* private */
struct list_headops_list; /* private */
struct list_headfamily_list;/* private */
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 3b13784..4ae1538 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -222,11 +222,6 @@ int genl_register_family(struct genl_fam
goto errout_locked;
}
- if (!try_module_get(family-owner)) {
- err = -EBUSY;
- goto errout_locked;
- }
-
if (family-id == GENL_ID_GENERATE) {
u16 newid = genl_generate_id();
@@ -283,7 +278,6 @@ int genl_unregister_family(struct genl_f
INIT_LIST_HEAD(family-ops_list);
genl_unlock();
- module_put(family-owner);
kfree(family-attrbuf);
genl_ctrl_event(CTRL_CMD_DELFAMILY, family);
return 0;
@@ -535,7 +529,6 @@ static struct genl_family genl_ctrl = {
.name = nlctrl,
.version = 0x1,
.maxattr = CTRL_ATTR_MAX,
- .owner = THIS_MODULE,
};
static int __init genl_init(void)
diff --git a/net/tipc/netlink.c b/net/tipc/netlink.c
index 6fe95ac..19b3f40 100644
--- a/net/tipc/netlink.c
+++ b/net/tipc/netlink.c
@@ -72,7 +72,6 @@ static struct genl_family family = {
.version = TIPC_GENL_VERSION,
.hdrsize = TIPC_GENL_HDRLEN,
.maxattr = 0,
- .owner = THIS_MODULE,
};
static struct genl_ops ops = {
--
1.0.GIT
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
Michael Buesch wrote: We also have a function to burn (and read) the SPROM though a private handler, atm. I consider this a very device specific task, which does not really need a standard API. Noone will ever reflash the SPROM, if he has no good good good reasons. ;) The idea of an (WE independent) standard API for flashing is not that bad, there are quite a few devices that support it. That is not implemented. a magic dest string all could be used instead of the specific interface. Wouldn't it mean all interfaces on all wireless cards? Yes. Need to think about it... It's too late now :P And what in the case you have some interface named all? Simply disallow this special case. :P The all doesn't IMHO server the purpose. You will virtualy never want to set something on all devices. You will want to set it on the minimal subset that shares the resource instead, and want (to be able) to know the subset Feyd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
John W. Linville wrote: What is WCONF_CMD_NICK for? Just for users convenience, like the nick in WE. Is it really useful? No :) Is the point here to support all current WEXT functionality? It probably should be. For compatibility, we will likely need code to translate the WEXT ioctls to the netlink stuff. The ioctl to change the nickname will need someplace to go. So, useless or not, I think the WCONF_CMD_NICK is appropriate. I have never used this myself and don't know anyone who did.. The compat ioctl can simply return unimplemented. Feyd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ip_finish_output2: No header cache and no neighbour! in 2.6.15-git7
Andi Kleen [EMAIL PROTECTED] wrote:
Badness in ip_finish_output2 at
/home/lsrc/quilt/linux/net/ipv4/ip_output.c:203
Call Trace: 8034284f{ip_finish_output2+419}
80343dfa{ip_fragment+1512}
803426ac{ip_finish_output2+0}
80344ff9{ip_mc_output+521}
8034423d{ip_push_pending_frames+877}
8035b307{udp_push_pending_frames+558}
8035bc6b{udp_sendmsg+1357}
8031f8dd{sock_sendmsg+209}
8013a140{autoremove_wake_function+0}
80145683{find_get_page+12}
8031edbe{move_addr_to_user+56}
8031f978{sockfd_lookup+12}
8031ed76{move_addr_to_kernel+34}
80320204{sys_sendto+235} 80321b9d{sk_free+184}
80338b3e{netlink_release+542}
8013a23a{wake_up_bit+14}
8010e4ee{system_call+126}
ip_finish_output2: No header cache and no neighbour!
My current guess is that this is caused by an SNAT rule that turns
a local outgoing multicast packet into something that has a foreign
source address.
However, this is yet to be confirmed.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ip_finish_output2: No header cache and no neighbour! in 2.6.15-git7
Herbert Xu wrote:
Andi Kleen [EMAIL PROTECTED] wrote:
Badness in ip_finish_output2 at /home/lsrc/quilt/linux/net/ipv4/ip_output.c:203
Call Trace: 8034284f{ip_finish_output2+419}
80343dfa{ip_fragment+1512}
803426ac{ip_finish_output2+0}
80344ff9{ip_mc_output+521}
8034423d{ip_push_pending_frames+877}
8035b307{udp_push_pending_frames+558}
8035bc6b{udp_sendmsg+1357}
8031f8dd{sock_sendmsg+209}
8013a140{autoremove_wake_function+0}
80145683{find_get_page+12}
8031edbe{move_addr_to_user+56}
8031f978{sockfd_lookup+12}
8031ed76{move_addr_to_kernel+34}
80320204{sys_sendto+235} 80321b9d{sk_free+184}
80338b3e{netlink_release+542} 8013a23a{wake_up_bit+14}
8010e4ee{system_call+126}
ip_finish_output2: No header cache and no neighbour!
My current guess is that this is caused by an SNAT rule that turns
a local outgoing multicast packet into something that has a foreign
source address.
However, this is yet to be confirmed.
I'm going to look into this. Andi, do you have any SNAT rules?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Acx100-devel] Tx packet fragmentation?
On Thursday 12 January 2006 18:58, Andreas Mohr wrote:
Hi,
I'd like to ask some things about packet fragmentation (you remember I wanted
to work on this due to my very bad link quality?). I'm asking now since I
will probably have some time during the weekend to work on it.
Problem is that fragmenting packets requires allocating several tx descriptors
in a row, then preparing and sending the data packet piecemeal via those
various descriptors in acx_l_tx_data().
Do you have any recommendations on how to do it?
(the split between acx_l_alloc_tx() and acx_l_tx_data() is a bit problematic)
Basically you want to modify this part of acx_i_start_xmit():
tx = acx_l_alloc_tx(priv);
if (unlikely(!tx)) {
printk_ratelimited(%s: start_xmit: txdesc ring is full,
dropping tx\n, dev-name);
txresult = NOT_OK;
goto end;
}
txbuf = acx_l_get_txbuf(priv, tx);
if (unlikely(!txbuf)) {
/* Card was removed */
txresult = NOT_OK;
acx_l_dealloc_tx(priv, tx);
goto end;
}
len = acx_ether_to_txbuf(priv, txbuf, skb);
if (unlikely(len 0)) {
/* Error in packet conversion */
txresult = NOT_OK;
acx_l_dealloc_tx(priv, tx);
goto end;
}
acx_l_tx_data(priv, tx, len);
As seen here, current code produces and tx'es just one wlan packet.
Possible adaptation:
struct frag_vec {
int len;
void *tx;
void *txbuf;
};
/* allocates and fills from 1 to N wlan fragments */
int acx_ether_to_frags(wlandevice_t *priv, const struct sk_buff *skb, struct
frag_vec *frag, int len);
acx_i_start_xmit():
struct frag_vec frag[N];
...
n = acx_ether_to_frags(priv, skb, frag, N);
if (n = 0) {
/* Error in packet conversion */
txresult = NOT_OK;
goto end;
}
for(1..n)
acx_l_tx_data(priv, frag[i].tx, frag[i].len);
Or should this be the job of the OS to care about fragmenting the packets
to be sent? (then it would just call our data tx stuff multiple times itself
anyway).
Yes, it must be done by softmac layer.
And what about the multiple host txhostdescs that we (need to?) initialize
in order to work around bugs?
It should not matter here, you won't even need to touch pci.c
except for maybe setting some FIRSTFRAG and/or MORE_FRAG bits
as appropriate.
Are we sure that this is a bug of specific(???) cards or not simply a bug of
certain firmware versions or even a bug in our driver? (maybe due to doing
some things in weird ways that the firmware totally doesn't expect?).
I think firmware was debugged only to meet needs of Windows driver.
--
vda
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][IPsec] AES-XCBC-MAC
Hello David and Herbert,
This patch introduces AES-XCBC-MAC.
I will send a glue for IPsec in another mail.
BTW, I could not fix the issue of single space line
so that I attach the patch. My thunderbird erases the line :-
Anyway this is for 2.6.15. please review and apply it.
Signed-off-by: Kazunori MIYAZAWA [EMAIL PROTECTED]
Thank you,
--
Kazunori Miyazawa
diff --git a/crypto/Kconfig b/crypto/Kconfig
index c442f2e..8dc28e9 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -16,6 +16,15 @@ config CRYPTO_HMAC
HMAC: Keyed-Hashing for Message Authentication (RFC2104).
This is required for IPSec.
+config CRYPTO_XCBC
+ bool XCBC support
+ depends on CRYPTO EXPERIMENTAL
+ help
+ XCBC: Keyed-Hashing with encryption algorithm
+ http://www.ietf.org/rfc/rfc3566.txt
+ http://csrc.nist.gov/encryption/modes/proposedmodes/
+ xcbc-mac/xcbc-mac-spec.pdf
+
config CRYPTO_NULL
tristate Null algorithms
depends on CRYPTO
diff --git a/crypto/Makefile b/crypto/Makefile
index d287b9e..781712d 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CRYPTO) += api.o scatterwal
$(proc-crypto-y)
obj-$(CONFIG_CRYPTO_HMAC) += hmac.o
+obj-$(CONFIG_CRYPTO_XCBC) += xcbc.o
obj-$(CONFIG_CRYPTO_NULL) += crypto_null.o
obj-$(CONFIG_CRYPTO_MD4) += md4.o
obj-$(CONFIG_CRYPTO_MD5) += md5.o
diff --git a/crypto/cipher.c b/crypto/cipher.c
index 65bcea0..19ac5fa 100644
--- a/crypto/cipher.c
+++ b/crypto/cipher.c
@@ -453,6 +453,9 @@ int crypto_init_cipher_ops(struct crypto
addr = ALIGN(addr, align);
addr += ALIGN(tfm-__crt_alg-cra_ctxsize, align);
ops-cit_iv = (void *)addr;
+#ifdef CONFIG_CRYPTO_XCBC
+ ret = crypto_alloc_xcbc_block(tfm);
+#endif
}
out:
@@ -461,4 +464,10 @@ out:
void crypto_exit_cipher_ops(struct crypto_tfm *tfm)
{
+#ifdef CONFIG_CRYPTO_XCBC
+ struct cipher_tfm *ops = tfm-crt_cipher;
+ if (ops-cit_mode == CRYPTO_TFM_MODE_CBC) {
+ crypto_free_xcbc_block(tfm);
+ }
+#endif
}
diff --git a/crypto/internal.h b/crypto/internal.h
index 959e602..adf0f20 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -62,6 +62,19 @@ static inline void crypto_free_hmac_bloc
{ }
#endif
+#ifdef CONFIG_CRYPTO_XCBC
+int crypto_alloc_xcbc_block(struct crypto_tfm *tfm);
+void crypto_free_xcbc_block(struct crypto_tfm *tfm);
+#else
+static inline int crypto_alloc_xcbc_block(struct crypto_tfm *tfm)
+{
+ return 0;
+}
+
+static inline void crypto_free_xcbc_block(struct crypto_tfm *tfm)
+{ }
+#endif
+
#ifdef CONFIG_PROC_FS
void __init crypto_init_proc(void);
#else
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 49e344f..6ae6fca 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -253,6 +253,97 @@ out:
#endif /* CONFIG_CRYPTO_HMAC */
+#ifdef CONFIG_CRYPTO_XCBC
+
+static void
+test_xcbc(char *algo, struct xcbc_testvec * template, unsigned int tcount)
+{
+ char *p;
+ unsigned int i, j, k, temp;
+ struct scatterlist sg[8];
+ char result[64];
+ struct crypto_tfm *tfm;
+ struct xcbc_testvec *xcbc_tv;
+ unsigned int tsize, klen;
+
+ tfm = crypto_alloc_tfm(algo, CRYPTO_TFM_MODE_CBC);
+ if (tfm == NULL) {
+ printk(failed to load transform for %s\n, algo);
+ return;
+ }
+
+ printk(\ntesting xcbc_%s\n, algo);
+
+ tsize = sizeof (struct xcbc_testvec);
+ tsize *= tcount;
+ if (tsize TVMEMSIZE) {
+ printk(template (%u) too big for tvmem (%u)\n, tsize,
+ TVMEMSIZE);
+ goto out;
+ }
+
+ memcpy(tvmem, template, tsize);
+ xcbc_tv = (void *) tvmem;
+
+ for (i = 0; i tcount; i++) {
+ printk(test %u:\n, i + 1);
+ memset(result, 0, sizeof (result));
+
+ p = xcbc_tv[i].plaintext;
+ klen = xcbc_tv[i].ksize;
+ sg[0].page = virt_to_page(p);
+ sg[0].offset = offset_in_page(p);
+ sg[0].length = xcbc_tv[i].psize;
+
+ crypto_xcbc(tfm, xcbc_tv[i].key, klen, sg, 1, result);
+
+ hexdump(result, crypto_tfm_alg_blocksize(tfm));
+ printk(%s\n,
+ memcmp(result, xcbc_tv[i].digest,
+ crypto_tfm_alg_blocksize(tfm)) ? fail :
+ pass);
+ }
+
+ printk(\ntesting xcbc_%s across pages\n, algo);
+
+ memset(xbuf, 0, XBUFSIZE);
+
+ j = 0;
+ for (i = 0; i tcount; i++) {
+ if (xcbc_tv[i].np) {
+ j++;
+ printk (test %u:\n,j);
+ memset (result, 0, 64);
+
+ temp = 0;
+ klen = xcbc_tv[i].ksize;
+ for (k = 0; k xcbc_tv[i].np; k++)
Re: [PATCH 2/4 - 2.6.15]net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
On Friday 13 January 2006 03:14, Shaun Pereira wrote: Thank you for reviewing that bit of code. I had a look at compat_sys_gettimeofday and sys32_gettimeofday codes. They seem to work in a similar way, casting a pointer to the structure from user space to a compat_timeval type. The part with the case is ok, except that you don't have to write struct compat_timeval __user *ctv; ctv = (struct compat_timeval __user*) userstamp; Instead, struct compat_timeval __user *ctv = userstamp; is the more common way to write it. The result is the same, since userstamp is a 'void __user *'. But to make sure I have tested the routine by forcing the sk- sk_stamp.tv_sec value to 0 in the x25_module ( for testing purposes only, as it is initialised to -1). Now when I make a 32 bit userspace SIOCGSTAMP ioctl to the 64 bit kernel I should get the current time back in user space. This seems to work, the ioctl returns the system time (just after TEST6:) So I have left the patch as is for now. However if necessary to use the element-by-element __put_user routine as in put_tv32, then I can make the change, just let me know. You need to to exactly that, yes. I'm not sure what exactly you have tested, but the expected result of your code would be that you see the sk_stamp.tv_sec value in the output, but not the tv_usec value. On little-endian system like x86_64, that is not much of a difference (less than a second) that you might miss in a test case, but on big-endian, it would be fatal. The layout of the structures on most systems is 64 bit LE 64 bit BE 32 bit bytes 0-3 tv_sec low tv_sec high tv_sec low bytes 4-7 tv_sec high tv_sec low tv_usec low bytes 8-11 tv_usec low tv_usec high bytes 12-15 tv_usec hightv_usec low You code copies the first eight bytes of the 64 bit data structure into the 32 bit data structure. Arnd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPsec] AES-XCBC-MAC
On Fri, Jan 13, 2006 at 08:17:49PM +0900, Kazunori Miyazawa wrote:
Anyway this is for 2.6.15. please review and apply it.
Signed-off-by: Kazunori MIYAZAWA [EMAIL PROTECTED]
Thanks for the patch Miyazawa-san!
Just a quick thought: HMAC is a bit of a misfit in the crypto directory.
It's neither core code (cipher/digest/compress) nor your average crypto
algorithm.
The new XCBC seems to make pretty good company for HMAC :)
Actually, they're both really digest algorithms that take a parameter.
The parameter for HMAC happens to be another digest algorithm while
the parameter for XCBC is an encryption algorithm.
So longer term I'd like to see both written as proper digest algorithms.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Fri, 2006-01-13 at 10:25 +0100, Feyd wrote: The all doesn't IMHO server the purpose. You will virtualy never want to set something on all devices. You will want to set it on the minimal subset that shares the resource instead, and want (to be able) to know the subset Ack. This needs to be handled in the API. (i.e. you need to be able to get a list of virtual devices sharing the channel etc.) Or, come to think of it, how about specifying this in some sort of tree? A virtual device would say have a list of properties that can be manipulated on it, for example a STA device: * essid * bssid * ... and for the others, it'd have a parent pointer which you somehow follow (needs API too to get all childs of a parent) johannes signature.asc Description: This is a digitally signed message part
Re: ip_finish_output2: No header cache and no neighbour! in 2.6.15-git7
On Friday 13 January 2006 11:41, Herbert Xu wrote: However, this is yet to be confirmed. I tried to test yesterday. It ran for some short time, but then eventually all hung (I think in IDE) because I didn't apply all workarounds for the countless bugs in current -git [Didn't have such an instable mainline kernel for a long time ...]. I applied the IDE workaround now and disabled SNAT and will try again. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
* Michael Buesch [EMAIL PROTECTED] 2006-01-12 18:24 This is an attempt to rewrite the Wireless Extensions userspace API, using netlink sockets. There should also be a notification API, to inform userspace for changes (config changes, state changes, etc). It is not implemented, yet. I'll only comment on the netlink bits and leave the rest to others. I'd highly recommend the use of attributes instead of fixed message structures to allow the interface to be flexible to extensions while staying binary compatible. Another idea might be to use the new generic netlink family to make things a bit easier to use. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: cls_u32.c
I know it has already been fixed. My point was just to document it somewhere so somebody else would avoid going through the same hassle. It should be documented as a known problem. Not everybody can update their kernel easily, especially in real-time embedded systems. -Original Message- From: David S. Miller [mailto:[EMAIL PROTECTED] Sent: Thursday, January 12, 2006 10:50 PM To: [EMAIL PROTECTED] Cc: netdev@vger.kernel.org Subject: Re: cls_u32.c From: April, Eric (Satnet) [EMAIL PROTECTED] Date: Thu, 12 Jan 2006 17:36:36 -0500 Problem found with cls_u32.c ... Bert has asked me to forward this to this address so it can be taken care of. That bogus ifdef hasn't been there for years, please use a newer kernel. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] schedule SHAPER for removal
On Wed, Jan 11, 2006 at 01:58:58AM +, Alan Cox wrote: On Mer, 2006-01-11 at 01:53 +0100, Andi Kleen wrote: shaper is completely obsolete and it's probably best to just remove all references to it and the kernel driver too. I would agree with that but it nees to go through a proper obsolesence and obliteration cycle not just vanish. Patch below. cu Adrian -- snip -- Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old 2006-01-13 15:02:15.0 +0100 +++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt 2006-01-13 15:06:19.0 +0100 @@ -164,0 +165,6 @@ +--- + +What: Traffic Shaper (CONFIG_SHAPER) +When: July 2006 +Why:obsoleted by the code in net/sched/ +Who:Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.15-mm3-full/drivers/net/Kconfig.old 2006-01-13 15:06:34.0 +0100 +++ linux-2.6.15-mm3-full/drivers/net/Kconfig 2006-01-13 15:06:49.0 +0100 @@ -2663,7 +2663,7 @@ SCSI generic support. config SHAPER - tristate Traffic Shaper (EXPERIMENTAL) + tristate Traffic Shaper (OBSOLETE) depends on EXPERIMENTAL ---help--- The traffic shaper is a virtual network device that allows you to - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genetlink: don't touch module ref count
On Fri, 2006-13-01 at 09:27 +0100, Per Liden wrote: Increasing the module ref count at registration will block the module from ever being unloaded. In fact, genetlink should not care about the owner at all. This patch removes the owner field from the struct registered with genetlink. Signed-off-by: Per Liden [EMAIL PROTECTED] Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED] BTW, thinking in the background we may in the future need the owner field for users of those modules (not for gennetlink to increment) but lets worry about that in the future. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPsec] AES-XCBC-MAC
On Fri, 13 Jan 2006, Kazunori Miyazawa wrote:
[it's better to send patches inline, so they can be reviewed inline with
proper quoting etc.]
+#ifdef CONFIG_CRYPTO_XCBC
+ ret = crypto_alloc_xcbc_block(tfm);
+#endif
}
...
+#ifdef CONFIG_CRYPTO_XCBC
+int crypto_alloc_xcbc_block(struct crypto_tfm *tfm);
+void crypto_free_xcbc_block(struct crypto_tfm *tfm);
+#else
+static inline int crypto_alloc_xcbc_block(struct crypto_tfm *tfm)
+{
+ return 0;
+}
+
+static inline void crypto_free_xcbc_block(struct crypto_tfm *tfm)
+{ }
+#endif
You shouldn't need the first #ifdef.
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPsec] AES-XCBC-MAC
+
+ ops = (struct xcbc_ops*)kmalloc(sizeof(*ops) +
+ + crypto_tfm_alg_blocksize(tfm), GFP_KERNEL);
+
Don't cast the return of kmalloc().
+void crypto_free_xcbc_block(struct crypto_tfm *tfm)
+{
+ if (tfm-crt_cipher.cit_xcbc_block)
+ kfree(tfm-crt_cipher.cit_xcbc_block)
Don't test for non-NULL before kfree().
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPsec] AES-XCBC-MAC
Why do you have this magic number for the blocksize, and limit the code to
this value?
int crypto_alloc_xcbc_block(struct crypto_tfm *tfm)
+{
+ struct xcbc_ops *ops;
+
+ BUG_ON(!crypto_tfm_alg_blocksize(tfm));
+ if (crypto_tfm_alg_blocksize(tfm) != 16)
+ return 0;
And then also use dynamic stack arrays based on the blocksize?
int crypto_xcbc_final(struct crypto_tfm *tfm, u8 *key, unsigned int keylen, u8
*out)
+{
+ struct xcbc_ops *ops = (struct xcbc_ops*)tfm-crt_cipher.cit_xcbc_block;
+ const unsigned int bsize = crypto_tfm_alg_blocksize(tfm);
+ int ret = 0;
+
+ if (!(tfm-crt_cipher.cit_mode CRYPTO_TFM_MODE_CBC))
+ return -EINVAL;
+
+ if (keylen != bsize)
+ return -EINVAL;
+
+ if (ops-len == bsize) {
+ u8 key2[bsize];
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][IPsec] IPsec gule of AES-XCBC-MAC
On Fri, 13 Jan 2006, Kazunori Miyazawa wrote: +#ifdef CONFIG_CRYPTO_XCBC + mode = aalg_desc-desc.sadb_alg_id == SADB_X_AALG_AES_XCBC_MAC ? + CRYPTO_TFM_MODE_CBC : 0; +#endif + ahp-key = x-aalg-alg_key; ahp-key_len = (x-aalg-alg_key_len+7)/8; - ahp-tfm = crypto_alloc_tfm(x-aalg-alg_name, 0); + ahp-tfm = crypto_alloc_tfm(x-aalg-alg_name, mode); if (!ahp-tfm) goto error; +#ifdef CONFIG_CRYPTO_XCBC + ahp-icv = !mode ? ah_hmac_digest : ah_xcbc_digest; +#else ahp-icv = ah_hmac_digest; - +#endif Please keep these kinds of #ifdefs out of the core code. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] 3c59x: improve usage of netif_carrier_{on,off}
...
I still have a patch in queue to improve usage of netif_carrier_{on,off}
but I had no possibility to test yet, so I did not send.
I'd be happy to test it out if you'd like.
Dan
Hi Dan,
here is the patch for testing.
The patch _should_ do the following:
1. Set the polling intervall for media changes to 5 seconds if link is down
and 60 seconds if link is up.
2. Handle netif_carrier_{on,of} and check for media changes in
proper way by using mii_check_media() in the mii case.
3. Handle netif_carrier_{on,of} also if media is forced to 10baseT/100baseTx.
4. Use ethtool_op_get_link instead of vortex_get_link.
So it is possible to test with ethtool.
The patch compiles, but as I told it is fairly untested.
Please let me know the results of your tests.
Thanks in advance,
Steffen
Signed-off-by: Steffen Klassert [EMAIL PROTECTED]
--- vanilla-2.6.15/drivers/net/3c59x.c 2006-01-03 04:21:10.0 +0100
+++ linux-2.6.15-sk2/drivers/net/3c59x.c2006-01-13 16:15:28.0
+0100
@@ -789,7 +789,7 @@
int options;/*
User-settable misc. driver options. */
unsigned int media_override:4, /* Passed-in media type. */
default_media:4,/* Read from
the EEPROM/Wn3_Config. */
- full_duplex:1, force_fd:1, autoselect:1,
+ full_duplex:1, autoselect:1,
bus_master:1, /* Vortex can
only do a fragment bus-m. */
full_bus_master_tx:1, full_bus_master_rx:2, /* Boomerang */
flow_ctrl:1,/* Use 802.3x
flow control (PAUSE only) */
@@ -1326,7 +1326,7 @@
vp-enable_wol = 1;
}
- vp-force_fd = vp-full_duplex;
+ vp-mii.force_media = vp-full_duplex;
vp-options = option;
/* Read the station address from the EEPROM. */
EL3WINDOW(0);
@@ -1616,6 +1616,48 @@
}
static void
+vortex_set_duplex(struct net_device *dev)
+{
+ int mii_reg1, mii_reg5;
+ struct vortex_private *vp = netdev_priv(dev);
+ long *ioaddr = vp-ioaddr;
+
+ EL3WINDOW(4);
+ mii_reg1 = mdio_read(dev, vp-phys[0], 1);
+ mii_reg5 = mdio_read(dev, vp-phys[0], 5);
+ vp-partner_flow_ctrl = ((mii_reg5 0x0400) != 0);
+ EL3WINDOW(3);
+ if (vortex_debug 1)
+ printk(KERN_INFO %s: MII #%d status %4.4x, link partner
capability %4.4x,
+ info1 %04x, setting %s-duplex.\n,
+ dev-name, vp-phys[0],
+ mii_reg1, mii_reg5,
+ vp-info1, ((vp-info1 0x8000) ||
vp-full_duplex) ? full : half);
+ /* Set the full-duplex bit. */
+ iowrite16( ((vp-info1 0x8000) || vp-full_duplex ? 0x20 : 0) |
+ (vp-large_frames ? 0x40 : 0) |
+ ((vp-full_duplex vp-flow_ctrl
vp-partner_flow_ctrl) ? 0x100 : 0),
+ ioaddr + Wn3_MAC_Ctrl);
+ /* AKPM: bug: should reset Tx and Rx after setting Duplex. Page 180 */
+}
+
+static void
+vortex_check_media(struct net_device *dev, unsigned int init)
+{
+ struct vortex_private *vp = netdev_priv(dev);
+ unsigned int ok_to_print = 0;
+
+ if (vortex_debug 3)
+ ok_to_print = 1;
+
+ if (mii_check_media(vp-mii, ok_to_print, init)) {
+ vp-full_duplex = vp-mii.full_duplex;
+ vortex_set_duplex(dev);
+ } else if (init)
+ vortex_set_duplex(dev);
+}
+
+static void
vortex_up(struct net_device *dev)
{
struct vortex_private *vp = netdev_priv(dev);
@@ -1675,55 +1717,15 @@
printk(KERN_DEBUG %s: Initial media type %s.\n,
dev-name, media_tbl[dev-if_port].name);
- vp-full_duplex = vp-force_fd;
+ vp-full_duplex = vp-mii.force_media;
config = BFINS(config, dev-if_port, 20, 4);
if (vortex_debug 6)
printk(KERN_DEBUG vortex_up(): writing 0x%x to
InternalConfig\n, config);
iowrite32(config, ioaddr + Wn3_Config);
- if (dev-if_port == XCVR_MII || dev-if_port == XCVR_NWAY) {
- int mii_reg1, mii_reg5;
- EL3WINDOW(4);
- /* Read BMSR (reg1) only to clear old status. */
- mii_reg1 = mdio_read(dev, vp-phys[0], MII_BMSR);
- mii_reg5 = mdio_read(dev, vp-phys[0], MII_LPA);
- if (mii_reg5 == 0x || mii_reg5 == 0x) {
- netif_carrier_off(dev); /* No MII device or no link
partner report */
- } else {
- mii_reg5 = vp-advertising;
- if ((mii_reg5 0x0100) != 0/* 100baseTx-FD */
-|| (mii_reg5 0x00C0) == 0x0040) /* 10T-FD,
but not 100-HD */
- vp-full_duplex
Re: [PATCH] net: fix PRIO qdisc bands init
* Patrick McHardy [EMAIL PROTECTED] 2006-01-12 06:25 David S. Miller wrote: From: jamal [EMAIL PROTECTED] Date: Tue, 10 Jan 2006 23:02:45 -0500 So it is an optimization - not a bug then, correct? It is only an optimization in as much as it avoids duplicate work during initialization. Like you I don't see how this patch fixes anything. No matter what you set skb-priority to, that gets translated by prio2band[] which should only point to actually initialized queues. In the last case in prio_classify (band q-bands) the band is returned directly. This could come from attached filters or from skb-priority. Its still not a fix since all bands have at least noop-qdiscs attached to them, just a semantic change which IMO makes sense. I agree with Patrick, this patch makes perfect sense to although the description is a bit misleading. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genetlink: don't touch module ref count
* Per Liden [EMAIL PROTECTED] 2006-01-13 09:27 Increasing the module ref count at registration will block the module from ever being unloaded. In fact, genetlink should not care about the owner at all. This patch removes the owner field from the struct registered with genetlink. Why shouldn't it care? When registering you hand over control of your family and callback structures which may not be accessed after the module has been unloaded. If you want to have your module unloaded, unregister your family first. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
radvd 0.9.1 released
Hi, A new version of radvd has been released. There hasn't been any major changes, just regular maintenance and a one new feature (jumboframe support). Get it at: http://www.litech.org/radvd/ There have been the following changes since 0.8: * Clean up signed/unsigned values, add more warnings to CFLAGS * Fix a couple of IPv6 Ready Logo Phase-2 IPv6 Core Protocols Self Test issues * Create a short FAQ in README file, other minor documentation updates * Get interface MTU automatically, so that you can use jumboframes and advertise MTU 1500 -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH netdev-2.6 32/39] Added disable packet split capability
On 1/12/06, Andi Kleen [EMAIL PROTECTED] wrote: On Friday 13 January 2006 01:51, Jeff Kirsher wrote: Adds the ability to disability packet split at compile time and use the legacy receive path on PCI express hardware. Does this patch really do what you described? -#ifdef CONFIG_E1000_PACKET_SPLIT +#ifndef DISABLE_PACKET_SPLIT uint32_t pages = 0; #endif Thanks for the comments, yes, the hardware supports a legacy receive mode, so compiling our driver (in the kernel) with make SUBDIRS=drivers/net/e1000 CFLAGS+=-DDISABLE_PACKET_SPLIT modules (or something like that, I didn't check it for correctness) will result in a driver that doesn't use packet split. The hardware has been tested extensively in both modes. Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] 2.6.x net driver updates
Hi, On Thu, 12 Jan 2006, Linus Torvalds wrote: Yes, I think that's much more Aunt-Nellie-friendly, but Roman considers it abuse of the Kconfig system in ways which I never completely understood? Hmm. If Roman dislikes it, he must dislike the fact that we already do exactly this for a ton of different things. There's something like 2000+ select statements in the kernel Kconfig tree, and just grepping for select.*CRYPTO gets 52 hits.. The basic problem is that it overrides any other dependencies and it makes easy to screw them up. The basic rule should be to use select only to include library functionality, which is mostly independent and has no other dependencies. Selecting larger subsystem, which may require more configuration itself, should be avoided. bye, Roman - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Thu, 12 Jan 2006 18:24:02 +0100 Michael Buesch [EMAIL PROTECTED] wrote: This is an attempt to rewrite the Wireless Extensions userspace API, using netlink sockets. There should also be a notification API, to inform userspace for changes (config changes, state changes, etc). It is not implemented, yet. This is against the devicescape stack. This patch is not to be used, but only to be commented on. ;) Basically I would like comments on the API definition in wconf.h 1. You will need more documentation, eventually in Documentation directory. 2. Is there 1:1 relationship between ieee80211_device and net_device or N net_devices per ieee80211_device? 3. Don't put a version number on the protocol messages. The way to us netlink is to us Type Length Variable structures. And write the code to ignore unknown types. Once you decide on a particular Type then it has to be frozen for ABI compatibility. The version numbering in the WE API is part of the problem 4. What about non-ieee80211 devices? With the growth of (mostly proprietary) cell phone carrier wireless, you don't want to shut out that. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genetlink: don't touch module ref count
Hi Thomas, On Fri, 13 Jan 2006, Thomas Graf wrote: * Per Liden [EMAIL PROTECTED] 2006-01-13 09:27 Increasing the module ref count at registration will block the module from ever being unloaded. In fact, genetlink should not care about the owner at all. This patch removes the owner field from the struct registered with genetlink. Why shouldn't it care? When registering you hand over control of your family and callback structures which may not be accessed after the module has been unloaded. Right, but to make sure the structure isn't accessed after the module is unloaded all the module has to do is to unregister it when its exit function is called. If the module doesn't do that, then that's a bug in the module which should be fixed. The genl_sem semaphore makes sure the module can't unregister its structure when it's actually in use (i.e. when a genetlink command for that family is in progress). If you want to have your module unloaded, unregister your family first. No, think about it. This is exactly where the deadlock happens. To unregister your family you need to get a call on your module's exit function. However, that exit function will _never_ be called by the kernel since it will simply not allow that when the modules ref count is 0. Hence, you will never be able to unload that module ever again. /Per - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: State of the Union: Wireless
Jiri Benc [EMAIL PROTECTED] writes: I think this is manageable. We need real 802.11 devices - all of frames, including management ones, end up in one queue (in one net_device). And we are not able to do Ethernet-802.11 conversion then, because we don't know how (and storing pointer to originating net_device or so in cb is not a solution, as the device can go away while the frame is queued). Also management frames with Ethernet headers are a bit hard to imagine. Exactly. Testing DECNET etc. (anyone using it at all?) should not be a problem - we don't carry DECNET over most link types anyway and if someone wants it it could be easily added. And we're going to support bridging with Ethernet, right? -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] cs89x0: credit Dmitry Pervushin
Credit Dmitry Pervushin for the PNX010X platform support. Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] diff -urN linux-2.6.15-git8.orig/drivers/net/cs89x0.c linux-2.6.15-git8/drivers/net/cs89x0.c --- linux-2.6.15-git8.orig/drivers/net/cs89x0.c 2006-01-13 02:16:01.0 +0100 +++ linux-2.6.15-git8/drivers/net/cs89x0.c 2006-01-13 02:29:24.0 +0100 @@ -87,6 +87,9 @@ Deepak Saxena : [EMAIL PROTECTED] : Intel IXDP2x01 (XScale ixp2x00 NPU) platform support + Dmitry Pervushin : [EMAIL PROTECTED] +: PNX010X platform support + */ /* Always include 'config.h' first in case the user wants to turn on - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] cs89x0: use u16 for device register data
cs89x0 inconsistently used 'int' and 'u32' for device register data.
As the cs89x0 is a 16-bit chip, change the I/O accessors over to 'u16'.
(Spotted by Deepak Saxena.)
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
diff -urN linux-2.6.15-git8.commit/drivers/net/cs89x0.c
linux-2.6.15-git8/drivers/net/cs89x0.c
--- linux-2.6.15-git8.commit/drivers/net/cs89x0.c 2006-01-13
02:53:50.0 +0100
+++ linux-2.6.15-git8/drivers/net/cs89x0.c 2006-01-13 02:53:59.0
+0100
@@ -342,38 +342,38 @@
#endif
#if defined(CONFIG_ARCH_IXDP2X01)
-static int
+static u16
readword(unsigned long base_addr, int portno)
{
- return (u16)__raw_readl(base_addr + (portno 1));
+ return __raw_readl(base_addr + (portno 1));
}
static void
-writeword(unsigned long base_addr, int portno, int value)
+writeword(unsigned long base_addr, int portno, u16 value)
{
- __raw_writel((u16)value, base_addr + (portno 1));
+ __raw_writel(value, base_addr + (portno 1));
}
#elif defined(CONFIG_ARCH_PNX010X)
-static int
+static u16
readword(unsigned long base_addr, int portno)
{
return inw(base_addr + (portno 1));
}
static void
-writeword(unsigned long base_addr, int portno, int value)
+writeword(unsigned long base_addr, int portno, u16 value)
{
outw(value, base_addr + (portno 1));
}
#else
-static int
+static u16
readword(unsigned long base_addr, int portno)
{
return inw(base_addr + portno);
}
static void
-writeword(unsigned long base_addr, int portno, int value)
+writeword(unsigned long base_addr, int portno, u16 value)
{
outw(value, base_addr + portno);
}
@@ -385,11 +385,11 @@
u8 *buf8 = (u8 *)buf;
do {
- u32 tmp32;
+ u16 tmp16;
- tmp32 = readword(base_addr, portno);
- *buf8++ = (u8)tmp32;
- *buf8++ = (u8)(tmp32 8);
+ tmp16 = readword(base_addr, portno);
+ *buf8++ = (u8)tmp16;
+ *buf8++ = (u8)(tmp16 8);
} while (--length);
}
@@ -399,23 +399,23 @@
u8 *buf8 = (u8 *)buf;
do {
- u32 tmp32;
+ u16 tmp16;
- tmp32 = *buf8++;
- tmp32 |= (*buf8++) 8;
- writeword(base_addr, portno, tmp32);
+ tmp16 = *buf8++;
+ tmp16 |= (*buf8++) 8;
+ writeword(base_addr, portno, tmp16);
} while (--length);
}
-static int
-readreg(struct net_device *dev, int regno)
+static u16
+readreg(struct net_device *dev, u16 regno)
{
writeword(dev-base_addr, ADD_PORT, regno);
return readword(dev-base_addr, DATA_PORT);
}
static void
-writereg(struct net_device *dev, int regno, int value)
+writereg(struct net_device *dev, u16 regno, u16 value)
{
writeword(dev-base_addr, ADD_PORT, regno);
writeword(dev-base_addr, DATA_PORT, value);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] cs89x0: use #elif instead of #else/#if/#endif
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
diff -urN linux-2.6.15-git8.orig/drivers/net/cs89x0.c
linux-2.6.15-git8/drivers/net/cs89x0.c
--- linux-2.6.15-git8.orig/drivers/net/cs89x0.c 2006-01-13 02:53:21.0
+0100
+++ linux-2.6.15-git8/drivers/net/cs89x0.c 2006-01-13 02:53:25.0
+0100
@@ -353,8 +353,7 @@
{
__raw_writel((u16)value, base_addr + (portno 1));
}
-#else
-#if defined(CONFIG_ARCH_PNX010X)
+#elif defined(CONFIG_ARCH_PNX010X)
static int
readword(unsigned long base_addr, int portno)
{
@@ -379,7 +378,6 @@
outw(value, base_addr + portno);
}
#endif
-#endif
static void
readwords(unsigned long base_addr, int portno, void *buf, int length)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] 2.6.x net driver updates
On Thu, Jan 12 2006, Andrew Morton wrote: Linus Torvalds [EMAIL PROTECTED] wrote: On Thu, 12 Jan 2006, Jeff Garzik wrote: dann frazier: CONFIG_AIRO needs CONFIG_CRYPTO I think this is done wrong. It should select CRYPTO rather than depends on CRYPTO. Otherwise people won't see it just because they don't have crypto enabled, which is not very user-friendly. Yes, I think that's much more Aunt-Nellie-friendly, but Roman considers it abuse of the Kconfig system in ways which I never completely understood? 'select' is really cool as a concept, but when you can't figure out why you cannot disable CONFIG_FOO because CONFIG_BAR selects it it's really annoying. Would be nice to actually be able to see if another option has selected this option. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] 2.6.x net driver updates
On Fri, Jan 13 2006, Sam Ravnborg wrote: On Fri, Jan 13, 2006 at 08:23:16PM +0100, Jens Axboe wrote: 'select' is really cool as a concept, but when you can't figure out why you cannot disable CONFIG_FOO because CONFIG_BAR selects it it's really annoying. Would be nice to actually be able to see if another option has selected this option. In menuconfig: Typing '?' on CONFIG_HOTPLUG revealed: Selected by: PCCARD || HOTPLUG_PCI PCI EXPERIMENTAL || FW_LOADER Then use '/' to search for the CONFIG_ symbols to see where they are defined. Live and learn, thanks, didn't know you could do that! -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genetlink: don't touch module ref count
From: Jamal Hadi Salim [EMAIL PROTECTED] Date: Fri, 13 Jan 2006 09:30:27 -0500 On Fri, 2006-13-01 at 09:27 +0100, Per Liden wrote: Increasing the module ref count at registration will block the module from ever being unloaded. In fact, genetlink should not care about the owner at all. This patch removes the owner field from the struct registered with genetlink. Signed-off-by: Per Liden [EMAIL PROTECTED] Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED] BTW, thinking in the background we may in the future need the owner field for users of those modules (not for gennetlink to increment) but lets worry about that in the future. I don't have a copy of this patch in my inbox, can someone resend it to me? Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RP filter support for IPv6, kernel 2.6.15 (fwd)
@@ -151,6 +152,7 @@
/* index values for the variables in ipv6_devconf */
enum {
DEVCONF_FORWARDING = 0,
+ DEVCONF_RPFILTER = 0,
DEVCONF_HOPLIMIT,
DEVCONF_MTU6,
DEVCONF_ACCEPT_RA,
That doesn't look quite right :)
- z
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genetlink: don't touch module ref count
On Fri, 13 Jan 2006, David S. Miller wrote:
From: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Fri, 13 Jan 2006 09:30:27 -0500
On Fri, 2006-13-01 at 09:27 +0100, Per Liden wrote:
Increasing the module ref count at registration will block the module from
ever being unloaded. In fact, genetlink should not care about the owner at
all. This patch removes the owner field from the struct registered with
genetlink.
Signed-off-by: Per Liden [EMAIL PROTECTED]
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
BTW, thinking in the background we may in the future need the owner
field for users of those modules (not for gennetlink to increment) but
lets worry about that in the future.
I don't have a copy of this patch in my inbox, can someone
resend it to me? Thanks.
Resending.
/Per
[PATCH] genetlink: don't touch module ref count
Increasing the module ref count at registration will block the module from
ever being unloaded. In fact, genetlink should not care about the owner at
all. This patch removes the owner field from the struct registered with
genetlink.
Signed-off-by: Per Liden [EMAIL PROTECTED]
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
---
include/net/genetlink.h |1 -
net/netlink/genetlink.c |7 ---
net/tipc/netlink.c |1 -
3 files changed, 0 insertions(+), 9 deletions(-)
4647eec00ae3dc1be979f5387d766529cb64e29c
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index c5b96b2..805de50 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -22,7 +22,6 @@ struct genl_family
charname[GENL_NAMSIZ];
unsigned intversion;
unsigned intmaxattr;
- struct module * owner;
struct nlattr **attrbuf;/* private */
struct list_headops_list; /* private */
struct list_headfamily_list;/* private */
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 3b13784..4ae1538 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -222,11 +222,6 @@ int genl_register_family(struct genl_fam
goto errout_locked;
}
- if (!try_module_get(family-owner)) {
- err = -EBUSY;
- goto errout_locked;
- }
-
if (family-id == GENL_ID_GENERATE) {
u16 newid = genl_generate_id();
@@ -283,7 +278,6 @@ int genl_unregister_family(struct genl_f
INIT_LIST_HEAD(family-ops_list);
genl_unlock();
- module_put(family-owner);
kfree(family-attrbuf);
genl_ctrl_event(CTRL_CMD_DELFAMILY, family);
return 0;
@@ -535,7 +529,6 @@ static struct genl_family genl_ctrl = {
.name = nlctrl,
.version = 0x1,
.maxattr = CTRL_ATTR_MAX,
- .owner = THIS_MODULE,
};
static int __init genl_init(void)
diff --git a/net/tipc/netlink.c b/net/tipc/netlink.c
index 6fe95ac..19b3f40 100644
--- a/net/tipc/netlink.c
+++ b/net/tipc/netlink.c
@@ -72,7 +72,6 @@ static struct genl_family family = {
.version = TIPC_GENL_VERSION,
.hdrsize = TIPC_GENL_HDRLEN,
.maxattr = 0,
- .owner = THIS_MODULE,
};
static struct genl_ops ops = {
--
1.0.GIT
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genetlink: don't touch module ref count
From: Per Liden [EMAIL PROTECTED] Date: Fri, 13 Jan 2006 21:56:53 +0100 (CET) On Fri, 13 Jan 2006, David S. Miller wrote: From: Jamal Hadi Salim [EMAIL PROTECTED] Date: Fri, 13 Jan 2006 09:30:27 -0500 On Fri, 2006-13-01 at 09:27 +0100, Per Liden wrote: Increasing the module ref count at registration will block the module from ever being unloaded. In fact, genetlink should not care about the owner at all. This patch removes the owner field from the struct registered with genetlink. Signed-off-by: Per Liden [EMAIL PROTECTED] Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED] BTW, thinking in the background we may in the future need the owner field for users of those modules (not for gennetlink to increment) but lets worry about that in the future. I don't have a copy of this patch in my inbox, can someone resend it to me? Thanks. Resending. Thank you. I'll apply this. There might be a better way to handle this, but for now this is fine. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genetlink: don't touch module ref count
From: Per Liden [EMAIL PROTECTED] Date: Fri, 13 Jan 2006 21:56:53 +0100 (CET) Signed-off-by: Per Liden [EMAIL PROTECTED] BTW, don't do this, it should be a perfectly functioning email address so that people can contact you. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genetlink: don't touch module ref count
On Fri, 13 Jan 2006, David S. Miller wrote: From: Per Liden [EMAIL PROTECTED] Date: Fri, 13 Jan 2006 21:56:53 +0100 (CET) Signed-off-by: Per Liden [EMAIL PROTECTED] BTW, don't do this, it should be a perfectly functioning email address so that people can contact you. Ok, sorry, I'll avoid that in the future. /Per - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: mv643xx_eth_start_xmit: calls skb_linearize with interrupts off
On Mon, Jan 09, 2006 at 04:43:08AM +, Paul Janzen wrote:
Paul Janzen [EMAIL PROTECTED] writes:
In mv643xx_eth_start_xmit:
[...]
spin_lock_irqsave(mp-lock, flags);
[...]
/* Since hardware can't handle unaligned fragments smaller
* than 9 bytes, if we find any, we linearize the skb
* and start again. */
[...]
skb_linearize(skb, GFP_ATOMIC);
[...]
which ends up calling kunmap_skb_frag(vaddr), which, when
CONFIG_HIGHMEM=y, calls local_bh_enable with interrupts off.
A patch for this problem is enclosed. I believe it also solves a
potential deadlock if skb_linearize() returns -ENOMEM.
Signed-off-by: Paul Janzen [EMAIL PROTECTED]
Thank you Paul. Good find and fix. I have one question below.
--- a/drivers/net/mv643xx_eth.c 2005-12-24 15:47:48.0 -0800
+++ b/drivers/net/mv643xx_eth.c 2006-01-08 20:30:25.0 -0800
@@ -1093,6 +1093,27 @@ static int mv643xx_poll(struct net_devic
}
#endif
+/* Hardware can't handle unaligned fragments smaller than 9 bytes.
+ * This helper function detects that case. When I've seen it, it's
+ * always been the first frag (probably near the end of the page), but
+ * we check all frags to be safe.
+ */
By the way, the above comment is mine, but since then, I have seen small,
unaligned fragments beyond the first frag, so I'll remove the last
sentence.
+static inline unsigned int has_tiny_unaligned_frags(struct sk_buff *skb)
+{
+unsigned int frag;
+skb_frag_t *fragp;
+
+for (frag = 0; frag skb_shinfo(skb)-nr_frags; frag++) {
+fragp = skb_shinfo(skb)-frags[frag];
+if (fragp-size = 8 fragp-page_offset 0x7)
+return 1;
+
+}
+return 0;
+}
+
+
/*
* mv643xx_eth_start_xmit
*
@@ -1136,12 +1157,22 @@ static int mv643xx_eth_start_xmit(struct
return 1;
}
+if (has_tiny_unaligned_frags(skb)) {
+if ((skb_linearize(skb, GFP_ATOMIC) != 0)
+|| has_tiny_unaligned_frags(skb)) {
There is no way that skb_linearize can return without removing all frags
from the skb. So the extra call to has_tiny_unaligned_frags() is
unnecessary, right?
-Dale
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
wireless: recap of current issues (intro)
My original post got eaten by the lists -- probably too big... I'm reposting in sections. After this intro follow sections on Configuration, Compatibility, Stack, Other Issues, and Actions. Enjoy! :-) --- WiFi-ers... Here I am, still feeling up to the challenge... I have stopped hyper-ventilating and the nervous vomiting is all over... :-) Having accepted the wireless role, I wanted to review the discussions prompted by Jeff's State of the Union message from a little over a week ago. There is lots of good talent involved in these discussions, and I believe a surprisingly high level of agreement (some of it nearly violent!) amongst the players. Below I have recapped what I saw as most of the important issues. I have endorsed some of the ideas, mostly those which seem to have broad agreement. I have also thrown-out a few ideas of my own. Please do comment on all of them, as neither my summaries nor my original ideas are likely to be without fault. :-) I have primarily grouped the issues into configuration, compatibility, and stack concerns. I also included an other group for a few other concerns that I though were worth mentioning. Finally, I have included an actions section to reveal some of my near-term plans and some of what I am thinking about beyond that. I would love to hear any comments you might have on these items as well. Thanks for taking the time to look this over. Creating this recap has reinforced one thing: this is far too big for just a single person (or even a small group) to tackle alone! Thanks, John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: mv643xx_eth_start_xmit: calls skb_linearize with interrupts off
Dale Farnsworth [EMAIL PROTECTED] writes:
+if (has_tiny_unaligned_frags(skb)) {
+if ((skb_linearize(skb, GFP_ATOMIC) != 0)
+|| has_tiny_unaligned_frags(skb)) {
There is no way that skb_linearize can return without removing all frags
from the skb. So the extra call to has_tiny_unaligned_frags() is
unnecessary, right?
It is just paranoia...skb_linearize can return nonzero, but the skb
should indeed be frag-less if it does return zero.
The patch was written that way to maintain the original semantics as
closely as possible. In the original, if the skb
has_tiny_unaligned_frags the first time through, it does check the skb
again after calling linearize.
In retrospect that should probably be printk(KERN_DEBUG ...) and not
KERN_ERR as well.
-- Paul
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Use NIP6_FMT in kernel.h
There are errors and inconsistency in the display of NIP6 strings.
ie: net/ipv6/ip6_flowlabel.c
There are errors and inconsistency in the display of NIPQUAD strings too.
ie: net/netfilter/nf_conntrack_ftp.c
This patch:
adds NIP6_FMT to kernel.h
changes all code to use NIP6_FMT
fixes net/ipv6/ip6_flowlabel.c
adds NIPQUAD_FMT to kernel.h
fixes net/netfilter/nf_conntrack_ftp.c
changes a few uses of %u.%u.%u.%u to NIPQUAD_FMT for symmetry to
NIP6_FMT
signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index e6ee2d9..323924e 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -216,6 +216,7 @@ extern void dump_stack(void);
((unsigned char *)addr)[1], \
((unsigned char *)addr)[2], \
((unsigned char *)addr)[3]
+#define NIPQUAD_FMT %u.%u.%u.%u
#define NIP6(addr) \
ntohs((addr).s6_addr16[0]), \
@@ -226,6 +227,7 @@ extern void dump_stack(void);
ntohs((addr).s6_addr16[5]), \
ntohs((addr).s6_addr16[6]), \
ntohs((addr).s6_addr16[7])
+#define NIP6_FMT %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x
#if defined(__LITTLE_ENDIAN)
#define HIPQUAD(addr) \
diff --git a/include/net/netfilter/nf_conntrack_tuple.h
b/include/net/netfilter/nf_conntrack_tuple.h
index 14ce790..530ef1f 100644
--- a/include/net/netfilter/nf_conntrack_tuple.h
+++ b/include/net/netfilter/nf_conntrack_tuple.h
@@ -111,7 +111,7 @@ struct nf_conntrack_tuple
#ifdef __KERNEL__
#define NF_CT_DUMP_TUPLE(tp) \
-DEBUGP(tuple %p: %u %u %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x %hu -
%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x %hu\n,
\
+DEBUGP(tuple %p: %u %u NIP6_FMT %hu - NIP6_FMT %hu\n, \
(tp), (tp)-src.l3num, (tp)-dst.protonum, \
NIP6(*(struct in6_addr *)(tp)-src.u3.all), ntohs((tp)-src.u.all), \
NIP6(*(struct in6_addr *)(tp)-dst.u3.all), ntohs((tp)-dst.u.all))
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 8f24121..a553f39 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -225,13 +225,13 @@ extern int sctp_debug_flag;
if (sctp_debug_flag) { \
if (saddr-sa.sa_family == AF_INET6) { \
printk(KERN_DEBUG \
- lead %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x
trail, \
+ lead NIP6_FMT trail, \
leadparm, \
NIP6(saddr-v6.sin6_addr), \
otherparms); \
} else { \
printk(KERN_DEBUG \
- lead %u.%u.%u.%u trail, \
+ lead NIPQUAD_FMT trail, \
leadparm, \
NIPQUAD(saddr-v4.sin_addr.s_addr), \
otherparms); \
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 7129d42..dfb4f14 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2644,7 +2644,7 @@ static int if6_seq_show(struct seq_file
{
struct inet6_ifaddr *ifp = (struct inet6_ifaddr *)v;
seq_printf(seq,
- %04x%04x%04x%04x%04x%04x%04x%04x %02x %02x %02x %02x %8s\n,
+ NIP6_FMT %02x %02x %02x %02x %8s\n,
NIP6(ifp-addr),
ifp-idev-dev-ifindex,
ifp-prefix_len,
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index 13cc7f8..c7932cb 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -332,8 +332,7 @@ static void ah6_err(struct sk_buff *skb,
if (!x)
return;
- NETDEBUG(KERN_DEBUG pmtu discovery on SA AH/%08x/
-%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x\n,
+ NETDEBUG(KERN_DEBUG pmtu discovery on SA AH/%08x/ NIP6_FMT \n,
ntohl(ah-spi), NIP6(iph-daddr));
xfrm_state_put(x);
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 65e73ac..72bd08a 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -532,9 +532,7 @@ static int ac6_seq_show(struct seq_file
struct ac6_iter_state *state = ac6_seq_private(seq);
seq_printf(seq,
- %-4d %-15s
- %04x%04x%04x%04x%04x%04x%04x%04x
- %5d\n,
+ %-4d %-15s NIP6_FMT %5d\n,
state-dev-ifindex, state-dev-name,
NIP6(im-aca_addr),
im-aca_users);
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 6de8ee1..7b5b94f 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -266,8 +266,7 @@ static void esp6_err(struct sk_buff *skb
x = xfrm_state_lookup((xfrm_address_t *)iph-daddr, esph-spi,
IPPROTO_ESP, AF_INET6);
if (!x)
return;
- printk(KERN_DEBUG pmtu discovery on SA
wireless: recap of current issues (configuration)
Configuration = Configuration seems to be coalescing around netlink. Among other things, this technology provides for muliticast requests and asynchronous event notification. The kernel should provide generic handlers for netlink configuraion messages, and there should be a per-device 80211_ops (wireless_ops? akin to ethtool_ops) structure for drivers to populate appropriately. At init, physical devices should be represented by a WiPHY device, not directly by a net_device. The list of physical devices should be discoverable through netlink and/or sysfs. (A WiPHY device is an abstraction representing the radio interface itself.) Virtual wlan devices should be associated to a WiPHY device many-to-one (one-to-one for some devices). Virtual devices correspond to a net_device. Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon, raw?, other modes?) which defines its on the air behaviour. Should this mode be fixed when the wlan device is created? Or something that can be changed when the net_device is down? It may be necessary to remove, suspend, and/or disable wlan devices in order to add, resume, and/or enable other types of wlan devices on the same WiPHY device (especialy true for rfmon). A mechanism is needed for drivers to be able to influence or disallow combinations of wlan devices in accordance with capabilities of the hardware. Do global config requests go to any associated wlan device? Or must they be directed to the WiPHY device? Does it matter? I think we should require global configuration to target the WiPHY device, while local configuration remains with the wlan device. (I'm not sure how important this point is?) Either way, the WiPHY device will need some way to be able to reject configuration requests that are incompatible among its associated wlan devices. Since the wlan interface implementations should not be device specific, perhaps the 802.11 stack can be smart enough to filter-out most conflicting config requests before they get to the WiPHY device? -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
wireless: recap of current issues (other issues)
Other Issues Radiotap headers make sense for an rfmon virtual device. I don't think it makes sense for normal usage. Should there be an option for radiotap headers on non-rfmon links? Rfmon interferes w/ other interfaces, but may be handy to enter/leave w/ little effort. Perhaps a config option for physical device to suspend/resume all (non-rfmon) virtual devices before/after enabling rfmon virtual device? (Would multiple rfmon devices even make sense? If not, is it worth restricting that?) What about old hardware w/ inactive maintenance? Deprecate/remove? Grandfather them w/ treatment as ethernet devices? Probably don't need a pronouncement on this at this time... -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
wireless: recap of current issues (actions)
Actions === I need to establish a public git tree for wireless. I would like for this to be on kernel.org, but I haven't got an account established there yet. I've been dragging my feet a little, hoping that the kernel.org account would materialize. I intend to get the sipsolutions softmac code into the wireless development kernels ASAP. I hope this will spur driver writers that need this functionality to start consolidating on the in-kernel stack. Obviously, what to do with the DeviceScape stack is a pressing issue. I am open to taking patches to introduce the DeviceScape stack on a branch under the (still coming) wireless tree. Obviously, patches that bring features from the DeviceScape stack to the ieee80211 stack would be generally welcome. Since we are toying with the issue of multiple stacks (at least in the wireless development kernels), some thought needs to be done w.r.t. how to make a final decision between the two stacks. An objective lists of functional feature requirements seems like a good place to start. IOW, I would like to have a list of features that would trigger the removal of one stack shortly after the other stack achieves support for the list. Is this feasible? -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Clean up comments for sk_chk_filter()
From: Kris Katterjohn [EMAIL PROTECTED] Date: Thu, 12 Jan 2006 13:05:54 -0800 This removes redundant comments, and moves one comment to a better location. Signed-off-by: Kris Katterjohn [EMAIL PROTECTED] Applied, thanks Kris. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC]: IPsec tunnel wildcard addresses
From: Patrick McHardy [EMAIL PROTECTED] Date: Thu, 12 Jan 2006 22:51:09 +0100 Great, here is a properly signed off patch without the extra hunks. Yeah, I noticed that bug fix snuck in there last time :-) Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PKT_SCHED]: Change default clock source to gettimeofday
From: Patrick McHardy [EMAIL PROTECTED] Date: Fri, 13 Jan 2006 00:01:34 +0100 It seems to be a common mistake to use jiffies as clocksource, which gives very bad results in most cases. This patch changes the default to gettimeofday. Applied, this is definitely an improvement. I'd like to really flesh this out at some point so that platforms can do whatever makes the most sense for them. SPARC64, for example, has synchronized cycle counter registers, so could use that by default there. It really doesn't belong in the config machinery, since many platforms that might be able to use the cycle counter register do not know if it's safe until runtime. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless: recap of current issues (other issues)
On Fri, 2006-01-13 at 17:24 -0500, John W. Linville wrote: Radiotap headers make sense for an rfmon virtual device. I don't think it makes sense for normal usage. Should there be an option for radiotap headers on non-rfmon links? Yes. For hardware debugging. Rfmon interferes w/ other interfaces, but may be handy to enter/leave w/ little effort. Perhaps a config option for physical device to suspend/resume all (non-rfmon) virtual devices before/after enabling rfmon virtual device? (Would multiple rfmon devices even make sense? If not, is it worth restricting that?) Multiple rfmon devices make sense in hypothetical or future hardware if different channels are supported on one WiPHY at once, but the rfmon device shall be restricted to a single one. Since we probably need a way to deactivate virtual devices anyway, having a config option to suspend/resume all others doesn't make sense -- userspace programs can just as well cycle over them and do it themselves. johannes signature.asc Description: This is a digitally signed message part
Re: wireless: recap of current issues
This is a re-send since the lists ate my reply. I've also trimmed out all but netdev and lkml email addresses. Do global config requests go to any associated wlan device? Or must they be directed to the WiPHY device? Does it matter? I think we should require global configuration to target the WiPHY device, while local configuration remains with the wlan device. (I'm not sure how important this point is?) Either way, the WiPHY device will need some way to be able to reject configuration requests that are incompatible among its associated wlan devices. Since the wlan interface implementations should not be device specific, perhaps the 802.11 stack can be smart enough to filter-out most conflicting config requests before they get to the WiPHY device? I'd create a generic function that handles most things, but allow the driver to over-ride this method if it knows better. Something like is_ok_to_add(new wlan device info); might need an is_ok_to_remove(foo); as well. We need an ethernet-802.11 translational bridging interface for compatibility, and to enable 802.1 bridging with ethernet. This could be a configuration setting for a wlan interface. It might be limited to wlan interfaces in station (or WDS) mode? If we can send a raw ethernet frame at the driver/stack, then it can reject or send as needed. For instance, you should be able to 'bridge' to a regular station interface _IF_ the source MAC matches the station's source MAC. This would also allow the packet-socket code to work with wifi just like it does with wired ethernet (and 802.1Q VLANs, for that matter.) Should a default wlan device be created at WiPHY init? Should it enable translational bridging? I'm inclined against this, but is it worthwhile for compatibility? Could/should this be a configuration option for the stack? I wouldn't...can't see how it helps anything. Stack = Is the in-kernel stack up-to-date w/ SourceForge? No. Why not? Can this development be brought into wireless development kernels? Can the in-kernel stack be saved? With the addition of softmac? Is it possible to extend softmac to support virtual wlan devices? If not, how do we proceed? How do we get more drivers in-kernel? (Multiple stacks probably don't help beyond the short-term timeframe.) One thing multiple in-kernel stacks might give us would be an easier way for developers (especially those not fully versed in wifi) to try out features of both stacks and make merging between the stacks easier (with the goal of having only one stack). It would probably allow more drivers to get in immediately as well, which should get more developers working on the same core logic. Other Issues Radiotap headers make sense for an rfmon virtual device. I don't think it makes sense for normal usage. Should there be an option for radiotap headers on non-rfmon links? Rfmon interferes w/ other interfaces, but may be handy to enter/leave w/ little effort. Perhaps a config option for physical device to suspend/resume all (non-rfmon) virtual devices before/after enabling rfmon virtual device? (Would multiple rfmon devices even make sense? If not, is it worth restricting that?) With regard to conflicting virtual devices: How about treat all 'DOWN' devices as irrelevent to the physical device. That way, you can have rfmon, AP, station, etc devices all configured at once, and just ifdown/ifup the one(s) you want to use at any given point. The virtual interfaces can keep all config info needed to bring themselves back online. What about old hardware w/ inactive maintenance? Deprecate/remove? Grandfather them w/ treatment as ethernet devices? Probably don't need a pronouncement on this at this time... Ignore for now..maybe it will get more active maintenance when the stack solidifies enough to make developing wifi less complex. Since we are toying with the issue of multiple stacks (at least in the wireless development kernels), some thought needs to be done w.r.t. how to make a final decision between the two stacks. An objective lists of functional feature requirements seems like a good place to start. IOW, I would like to have a list of features that would trigger the removal of one stack shortly after the other stack achieves support for the list. Is this feasible? Would it be possible to write a very thin 'shim' stack that could sit over either device-scape or the current stack? This shim could start solidifying the API with user-space somewhat independently of the lower levels. If one stack did not support a particular feature, then it just returns a failure code. If this is not too much work, it might allow the stack merge to happen gradually. Of course, this might be more work than it's worth... Thanks for all the work you're doing! Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line
Re: wireless: recap of current issues (other issues)
On Fri, 2006-01-13 at 23:35 +0100, Johannes Berg wrote: On Fri, 2006-01-13 at 17:24 -0500, John W. Linville wrote: Radiotap headers make sense for an rfmon virtual device. I don't think it makes sense for normal usage. Should there be an option for radiotap headers on non-rfmon links? Yes. For hardware debugging. Actually, scratch that. For hardware debugging you just add a virtual rfmon device and go with that, and just don't do anything except 2 virtual devices on the wiphy. johannes signature.asc Description: This is a digitally signed message part
Re: wireless: recap of current issues (stack)
On Friday 13 January 2006 15:32, John W. Linville wrote: Do we need to have both wireless-stable and wireless-devel kernels? What about the suggestion of having both stacks in the kernel at once? I'm not very excited about two in-kernel stacks. Still, consolidating wireless drivers down to two stacks is probably better than what we have now...? Either way, we would have to have general understanding that at some point (not too far away), one of the stacks would have to disappear. Having not had experience coding for the stacks, I'm not inclined to form an opinion on which is better. I think on a realistic footing, a stack switch should only occur if it doesn't come at great expense (unless that great expense is less than the expense of making the existing stack capable enough to handle all the devices we want to support). But I have to NAK the idea of two stacks. There are implications in the 'here and now', so to speak, but what worries me the most is long term. You know how it's no fun fixing bugs when you could be adding new features? Let's say that on May 2006, you drop the hammer and decide that Stack B is the winner. You've now got to convince / motivate the Stack A users to stop what they're doing and work hard to migrate to Stack B. There might be stragglers, so let's say you set a drop dead date. Now what happens if we reach that date and some drivers still aren't ready. Tough, you say, you've had ample notice and time to port. Now we've got a flamewar on our hands, because no one wants to release a new kernel that drops support for things people are using. By contrast, if we got softmac in, ieee80211 may still be lacking in some areas, but if we do the hard work to port a few drivers and get them in-tree and working well, you start to have happy users. Motivation will build for others to port and get into the tree (partly because no one wants to be the odd man out, and their users will probably be frustrated by it too), and part of the motivation should extend naturally onto improving in-kernel ieee80211 enough to support whatever odd-ball implementations they're dealing with. So I think you end up with a nice snowball effect. As an aside to this whole thing, I know we're talking about *kernel* wireless but it's worthless to most people without good userland support as well. Anyone have any thoughts and feelings on what things look like on the desktop? I think if we work closely with some desktop people, we can shepard in some wonderful new desktop support on top of the new netlink API. Cheers, Chase Venters - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Pá 13-01-06 09:55:33, Stephen Hemminger wrote: On Thu, 12 Jan 2006 18:24:02 +0100 4. What about non-ieee80211 devices? With the growth of (mostly proprietary) cell phone carrier wireless, you don't want to shut out that. Don't mix it here. Mobile phones normally talk using AT interface, modem-like. Pavel -- Thanks, Sharp! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WCONF, netlink based WE replacement.
On Sat, 2006-01-14 at 00:23 +0100, Pavel Machek wrote: On Pá 13-01-06 09:55:33, Stephen Hemminger wrote: On Thu, 12 Jan 2006 18:24:02 +0100 4. What about non-ieee80211 devices? With the growth of (mostly proprietary) cell phone carrier wireless, you don't want to shut out that. Don't mix it here. Mobile phones normally talk using AT interface, modem-like. I think he was referring to possible cell phone hardware when linux is running on the phone, not a full phone connected to linux. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] Use NIP6_FMT in kernel.h
Hello.
Well, basic idea is okay. But...
In article [EMAIL PROTECTED] (at Fri, 13 Jan 2006 14:14:48 -0800), Joe
Perches [EMAIL PROTECTED] says:
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 7129d42..dfb4f14 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2644,7 +2644,7 @@ static int if6_seq_show(struct seq_file
{
struct inet6_ifaddr *ifp = (struct inet6_ifaddr *)v;
seq_printf(seq,
-%04x%04x%04x%04x%04x%04x%04x%04x %02x %02x %02x %02x %8s\n,
+NIP6_FMT %02x %02x %02x %02x %8s\n,
NIP6(ifp-addr),
ifp-idev-dev-ifindex,
ifp-prefix_len,
Don't change this, or break many applications.
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 65e73ac..72bd08a 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -532,9 +532,7 @@ static int ac6_seq_show(struct seq_file
struct ac6_iter_state *state = ac6_seq_private(seq);
seq_printf(seq,
-%-4d %-15s
-%04x%04x%04x%04x%04x%04x%04x%04x
-%5d\n,
+%-4d %-15s NIP6_FMT %5d\n,
state-dev-ifindex, state-dev-name,
NIP6(im-aca_addr),
im-aca_users);
ditto.
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 964ad9d..4183c8d 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -629,9 +629,7 @@ static void ip6fl_fl_seq_show(struct seq
{
while(fl) {
seq_printf(seq,
-%05X %-1d %-6d %-6d %-6ld %-8ld
-%02x%02x%02x%02x%02x%02x%02x%02x
-%-4d\n,
+%05X %-1d %-6d %-6d %-6ld %-8ld NIP6_FMT
%-4d\n,
(unsigned)ntohl(fl-label),
fl-share,
(unsigned)fl-owner,
ditto.
@@ -647,8 +645,8 @@ static void ip6fl_fl_seq_show(struct seq
static int ip6fl_seq_show(struct seq_file *seq, void *v)
{
if (v == SEQ_START_TOKEN)
- seq_puts(seq, Label S Owner Users Linger Expires
- Dst Opt\n);
+ seq_printf(seq, %-5s %-1s %-6s %-6s %-6s %-8s %-39s %s\n,
+Label, S, Owner, Users, Linger, Expires,
Dst, Opt);
else
ip6fl_fl_seq_show(seq, v);
return 0;
Please keep using seq_puts() for constant string.
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index cc3e9f5..0e03eab 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -2373,7 +2373,7 @@ static int igmp6_mc_seq_show(struct seq_
struct igmp6_mc_iter_state *state = igmp6_mc_seq_private(seq);
seq_printf(seq,
-%-4d %-15s %04x%04x%04x%04x%04x%04x%04x%04x %5d %08X
%ld\n,
+%-4d %-15s NIP6_FMT %5d %08X %ld\n,
state-dev-ifindex, state-dev-name,
NIP6(im-mca_addr),
im-mca_users, im-mca_flags,
@@ -2542,15 +2542,12 @@ static int igmp6_mcf_seq_show(struct seq
if (v == SEQ_START_TOKEN) {
seq_printf(seq,
%3s %6s
-%32s %32s %6s %6s\n, Idx,
+%39s %39s %6s %6s\n, Idx,
Device, Multicast Address,
Source Address, INC, EXC);
} else {
seq_printf(seq,
-%3d %6.6s
-%04x%04x%04x%04x%04x%04x%04x%04x
-%04x%04x%04x%04x%04x%04x%04x%04x
-%6lu %6lu\n,
+%3d %6.6s NIP6_FMT NIP6_FMT %6lu %6lu\n,
state-dev-ifindex, state-dev-name,
NIP6(state-im-mca_addr),
NIP6(psf-sf_addr),
Same as addrconf/mcast.
Thanks.
--
YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED]
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless: recap of current issues (configuration)
John W. Linville [EMAIL PROTECTED] writes: Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon, raw?, other modes?) which defines its on the air behaviour. Should this mode be fixed when the wlan device is created? I think so. If needed one can delete and create. Or something that can be changed when the net_device is down? IMHO: unnecessary complicates things. It may be necessary to remove, suspend, and/or disable wlan devices in order to add, resume, and/or enable other types of wlan devices on the same WiPHY device (especialy true for rfmon). A mechanism is needed for drivers to be able to influence or disallow combinations of wlan devices in accordance with capabilities of the hardware. If the control messages go through the main (WiPHY) driver it can decide and/or forward the request further, to the library. Not sure about netlink. OTOH I'm at all not sure netlink should be used for configuration. sysfs, ioctl seem a better options. Netlink is better for state monitoring etc. I don't know it very well though. Do global config requests go to any associated wlan device? Are they any global config settings? sysctl or sysfs maybe? Or must they be directed to the WiPHY device? Does it matter? If you mean settings for a particular physical card then WiPHY. I think we should require global configuration to target the WiPHY device, while local configuration remains with the wlan device. If local means concerning the wlan device then sure, yes. (I'm not sure how important this point is?) Either way, the WiPHY device will need some way to be able to reject configuration requests that are incompatible among its associated wlan devices. Since the wlan interface implementations should not be device specific, perhaps the 802.11 stack can be smart enough to filter-out most conflicting config requests before they get to the WiPHY device? I don't think so. The hardware driver should get the request first, the rest should look like a library. I've played with both approaches for years and I would avoid 802.11 using the hw driver scenario if at all possible. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use NIP6_FMT in kernel.h
In article [EMAIL PROTECTED] (at Fri, 13 Jan 2006 14:29:24 -0800 (PST)),
David S. Miller [EMAIL PROTECTED] says:
changes all code to use NIP6_FMT
fixes net/ipv6/ip6_flowlabel.c
:
This looks good, applied, thanks Joe.
As I have commented in another mail, the original patch breaks
applications such as ifconfig, radvd etc.
Please apply this.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff -u b/include/linux/kernel.h b/include/linux/kernel.h
--- b/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -228,6 +228,7 @@
ntohs((addr).s6_addr16[6]), \
ntohs((addr).s6_addr16[7])
#define NIP6_FMT %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x
+#define NIP6_SEQFMT %04x%04x%04x%04x%04x%04x%04x%04x
#if defined(__LITTLE_ENDIAN)
#define HIPQUAD(addr) \
diff -u b/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
--- b/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2643,7 +2643,7 @@
{
struct inet6_ifaddr *ifp = (struct inet6_ifaddr *)v;
seq_printf(seq,
- NIP6_FMT %02x %02x %02x %02x %8s\n,
+ NIP6_SEQFMT %02x %02x %02x %02x %8s\n,
NIP6(ifp-addr),
ifp-idev-dev-ifindex,
ifp-prefix_len,
diff -u b/net/ipv6/anycast.c b/net/ipv6/anycast.c
--- b/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -531,7 +531,7 @@
struct ac6_iter_state *state = ac6_seq_private(seq);
seq_printf(seq,
- %-4d %-15s NIP6_FMT %5d\n,
+ %-4d %-15s NIP6_SEQFMT %5d\n,
state-dev-ifindex, state-dev-name,
NIP6(im-aca_addr),
im-aca_users);
diff -u b/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
--- b/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -628,7 +628,7 @@
{
while(fl) {
seq_printf(seq,
- %05X %-1d %-6d %-6d %-6ld %-8ld NIP6_FMT
%-4d\n,
+ %05X %-1d %-6d %-6d %-6ld %-8ld NIP6_SEQFMT
%-4d\n,
(unsigned)ntohl(fl-label),
fl-share,
(unsigned)fl-owner,
@@ -644,7 +644,7 @@
static int ip6fl_seq_show(struct seq_file *seq, void *v)
{
if (v == SEQ_START_TOKEN)
- seq_printf(seq, %-5s %-1s %-6s %-6s %-6s %-8s %-39s %s\n,
+ seq_printf(seq, %-5s %-1s %-6s %-6s %-6s %-8s %-32s %s\n,
Label, S, Owner, Users, Linger, Expires,
Dst, Opt);
else
ip6fl_fl_seq_show(seq, v);
diff -u b/net/ipv6/mcast.c b/net/ipv6/mcast.c
--- b/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -2374,7 +2374,7 @@
struct igmp6_mc_iter_state *state = igmp6_mc_seq_private(seq);
seq_printf(seq,
- %-4d %-15s NIP6_FMT %5d %08X %ld\n,
+ %-4d %-15s NIP6_SEQFMT %5d %08X %ld\n,
state-dev-ifindex, state-dev-name,
NIP6(im-mca_addr),
im-mca_users, im-mca_flags,
@@ -2543,12 +2543,12 @@
if (v == SEQ_START_TOKEN) {
seq_printf(seq,
%3s %6s
- %39s %39s %6s %6s\n, Idx,
+ %32s %32s %6s %6s\n, Idx,
Device, Multicast Address,
Source Address, INC, EXC);
} else {
seq_printf(seq,
- %3d %6.6s NIP6_FMT NIP6_FMT %6lu %6lu\n,
+ %3d %6.6s NIP6_SEQFMT NIP6_SEQFMT %6lu
%6lu\n,
state-dev-ifindex, state-dev-name,
NIP6(state-im-mca_addr),
NIP6(psf-sf_addr),
--
YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED]
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use NIP6_FMT in kernel.h
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Sat, 14 Jan 2006 09:12:13 +0900 (JST) In article [EMAIL PROTECTED] (at Fri, 13 Jan 2006 14:29:24 -0800 (PST)), David S. Miller [EMAIL PROTECTED] says: changes all code to use NIP6_FMT fixes net/ipv6/ip6_flowlabel.c : This looks good, applied, thanks Joe. As I have commented in another mail, the original patch breaks applications such as ifconfig, radvd etc. Please apply this. Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] I will, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] e1000 latest drivers (6.1.16, 6.2.15, 6.3.9) incompatible with netpoll in NAPI mode
The latest version of the Intel e1000 driver use an implementation which
is incompatible with netpoll when compiled as NAPI enabled.
The netpoll_poll routines uses the parent netdev structure as the device
that gets polled:
poll_napi:
if (test_bit(__LINK_STATE_RX_SCHED, np-dev-state)
npinfo-poll_owner != smp_processor_id()
spin_trylock(npinfo-poll_lock)) {
npinfo-rx_flags |= NETPOLL_RX_DROP;
atomic_inc(trapped);
np-dev-poll(np-dev, budget);
However, the e1000_intr routine schedules the napi poll based on a
pseudo device created by the driver.
e1000_intr:
static irqreturn_t
e1000_intr(int irq, void *data, struct pt_regs *regs)
{
struct net_device *netdev = data;
struct e1000_adapter *adapter = netdev_priv(netdev);
...
#else /* if !CONFIG_E1000_MQ */
if (likely(netif_rx_schedule_prep(adapter-polling_netdev[0])))
__netif_rx_schedule(adapter-polling_netdev[0]);
else
e1000_irq_enable(adapter);
#endif /* CONFIG_E1000_MQ */
printks inserted confirm that data != adapter-polling_netdev[0] and
the the parent netdev for the e1000 device is not on the poll list and
does not have the LINK_STATE_RX_SCHED bit set.
Hence the necessary LINK_STATE_RX_SCHED flag is not set in the parent
device's state field, and the e1000_clean routine is never called from
netpoll:napi_poll.
I haven't looked closely at the MQ code, but I doubt the situation
improves, as the whole idea with the implementation seems to be to allow
multiple pseudo devices, one for each queue.
This problem does not exist in the normal napi polling sequence, as the
poll list is walked, and whatever devices are on the list are polled,
irrespective of whether they were the actual parent devices or
driver-created pseudo devices.
The bug causes netdump to not work at all over e1000-napi, and probably
leads to stalls in the case of kgdboe or netconsole as well.
Unfortunately, it is not a simple coding error, but rather the case of
two designs being incompatible.
I would like comments on potential solutions, none of which seem
particularly appealing
1) Have netpoll:napi_poll walk the poll list like the normal dev.c code
does. This seems simplest. I am concerned that it lets too much
activity go on for kgdboe and netdump, since all devices get serviced
that are on the poll list at the time of the system freeze for debug/dump.
2) Fix the e1000 (and other drivers that may do similar things) to be
aware that it is scheduling napi-callback based on a net poll, falling
back into single queue operation off of the parent device only - simple
in concept, but possibly a good bit of change to the driver(s).
2.5) provide polled operation directly to the netif_rx path - probably
straightforward, but adds code to the driver and requires a means to
untangle any pending napi polls, which might be interesting in
multi-queue, smp, rt_pre-emptible situations.
3) Figure out a way for np device setup to become aware of the actual
device to be polled - perhaps an additional driver api - this may also
require some work of #2 above, but offers an advantage of keeping the
decisions out of the fast path. This requires work to several different
areas, including the netpoll setup api, the driver api, and every
driver, although the driver work should be relatively trivial except for
multiqueue devices.
4) Some brilliant 3 line change that makes everything work which I've
stupidly overlooked. (my preferred solution)
I'm willing to do the work after receiving some comments from the list.
Unfortunately, I have to fix this fairly soon, so I look forward to
comments in the next few days.
Thanks,
Mark Huth
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] e1000 latest drivers (6.1.16, 6.2.15, 6.3.9) incompatible with netpoll in NAPI mode
On 1/13/06, Mark Huth [EMAIL PROTECTED] wrote: 1) Have netpoll:napi_poll walk the poll list like the normal dev.c code does. This seems simplest. I am concerned that it lets too much activity go on for kgdboe and netdump, since all devices get serviced that are on the poll list at the time of the system freeze for debug/dump. This has been a known issue. You might want to include the maintainer of netpoll in future threads regardins netpoll which is Matt Mackall [EMAIL PROTECTED]. There is also a known issue with netpoll not able to handle packet split, which you might be able to resolve while fixing NAPI. I am interested in option 1 becuase it does seem to be the similpest fix, but I am interested to hear what the concensus is. -- Cheers, Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.16 net features closed
No new networking features for 2.6.16, submit only bug fixes please. Thank you. I may open up a net-2.6.17 tree right before I leave for New Zealand or while I'm there for linux.conf.au (I leave on Jan 20th), but I want to defer that as much as possible to get folks to concentrate on bug fixing. Thanks again. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] drivers/net/arcnet/: possible cleanups
This patch contains the following possible cleanups:
- make needlessly global code static
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null)
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet)
To make Jeff happy, arcnet.c still prints
arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/arcnet/arc-rawmode.c |2 +-
drivers/net/arcnet/arcnet.c | 15 +--
drivers/net/arcnet/rfc1051.c |2 +-
drivers/net/arcnet/rfc1201.c |2 +-
include/linux/arcdevice.h| 10 --
5 files changed, 12 insertions(+), 19 deletions(-)
diff -puN drivers/net/arcnet/arcnet.c~drivers-net-arcnet-possible-cleanups
drivers/net/arcnet/arcnet.c
--- devel/drivers/net/arcnet/arcnet.c~drivers-net-arcnet-possible-cleanups
2005-07-09 01:24:43.0 -0700
+++ devel-akpm/drivers/net/arcnet/arcnet.c 2005-07-09 01:24:43.0
-0700
@@ -61,6 +59,7 @@ static int null_build_header(struct sk_b
static int null_prepare_tx(struct net_device *dev, struct archdr *pkt,
int length, int bufnum);
+static void arcnet_rx(struct net_device *dev, int bufnum);
/*
* one ArcProto per possible proto ID. None of the elements of
@@ -71,7 +70,7 @@ static int null_prepare_tx(struct net_de
struct ArcProto *arc_proto_map[256], *arc_proto_default,
*arc_bcast_proto, *arc_raw_proto;
-struct ArcProto arc_proto_null =
+static struct ArcProto arc_proto_null =
{
.suffix = '?',
.mtu= XMTU,
@@ -90,7 +89,6 @@ EXPORT_SYMBOL(arc_proto_map);
EXPORT_SYMBOL(arc_proto_default);
EXPORT_SYMBOL(arc_bcast_proto);
EXPORT_SYMBOL(arc_raw_proto);
-EXPORT_SYMBOL(arc_proto_null);
EXPORT_SYMBOL(arcnet_unregister_proto);
EXPORT_SYMBOL(arcnet_debug);
EXPORT_SYMBOL(alloc_arcdev);
@@ -118,7 +116,7 @@ static int __init arcnet_init(void)
arcnet_debug = debug;
- printk(VERSION);
+ printk(arcnet loaded.\n);
#ifdef ALPHA_WARNING
BUGLVL(D_EXTRA) {
@@ -178,8 +176,8 @@ EXPORT_SYMBOL(arcnet_dump_skb);
* Dump the contents of an ARCnet buffer
*/
#if (ARCNET_DEBUG_MAX (D_RX | D_TX))
-void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc,
- int take_arcnet_lock)
+static void arcnet_dump_packet(struct net_device *dev, int bufnum,
+ char *desc, int take_arcnet_lock)
{
struct arcnet_local *lp = dev-priv;
int i, length;
@@ -208,7 +206,10 @@ void arcnet_dump_packet(struct net_devic
}
-EXPORT_SYMBOL(arcnet_dump_packet);
+#else
+
+#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) do { } while (0)
+
#endif
@@ -987,7 +988,7 @@ irqreturn_t arcnet_interrupt(int irq, vo
* This is a generic packet receiver that calls arcnet??_rx depending on the
* protocol ID found.
*/
-void arcnet_rx(struct net_device *dev, int bufnum)
+static void arcnet_rx(struct net_device *dev, int bufnum)
{
struct arcnet_local *lp = dev-priv;
struct archdr pkt;
diff -puN drivers/net/arcnet/arc-rawmode.c~drivers-net-arcnet-possible-cleanups
drivers/net/arcnet/arc-rawmode.c
--- devel/drivers/net/arcnet/arc-rawmode.c~drivers-net-arcnet-possible-cleanups
2005-07-09 01:24:43.0 -0700
+++ devel-akpm/drivers/net/arcnet/arc-rawmode.c 2005-07-09 01:24:43.0
-0700
@@ -42,7 +42,7 @@ static int build_header(struct sk_buff *
static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length,
int bufnum);
-struct ArcProto rawmode_proto =
+static struct ArcProto rawmode_proto =
{
.suffix = 'r',
.mtu= XMTU,
diff -puN drivers/net/arcnet/rfc1051.c~drivers-net-arcnet-possible-cleanups
drivers/net/arcnet/rfc1051.c
--- devel/drivers/net/arcnet/rfc1051.c~drivers-net-arcnet-possible-cleanups
2005-07-09 01:24:43.0 -0700
+++ devel-akpm/drivers/net/arcnet/rfc1051.c 2005-07-09 01:24:43.0
-0700
@@ -43,7 +43,7 @@ static int prepare_tx(struct net_device
int bufnum);
-struct ArcProto rfc1051_proto =
+static struct ArcProto rfc1051_proto =
{
.suffix = 's',
.mtu= XMTU - RFC1051_HDR_SIZE,
diff -puN drivers/net/arcnet/rfc1201.c~drivers-net-arcnet-possible-cleanups
drivers/net/arcnet/rfc1201.c
--- devel/drivers/net/arcnet/rfc1201.c~drivers-net-arcnet-possible-cleanups
2005-07-09 01:24:43.0 -0700
+++ devel-akpm/drivers/net/arcnet/rfc1201.c 2005-07-09 01:24:43.0
-0700
@@ -43,7 +43,7 @@ static int prepare_tx(struct net_device
int bufnum);
static int continue_tx(struct net_device *dev, int bufnum);
-struct ArcProto rfc1201_proto =
+static struct ArcProto rfc1201_proto =
{
.suffix = 'a',
.mtu= 1500, /* could be more, but some receivers can't
handle it... */
diff -puN
[2.6 patch] drivers/net/s2io.c: make code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 5 Jan 2006
drivers/net/s2io.c | 22 +++---
drivers/net/s2io.h | 17 +++--
2 files changed, 18 insertions(+), 21 deletions(-)
--- linux-2.6.15-mm1-full/drivers/net/s2io.h.old2006-01-05
20:46:34.0 +0100
+++ linux-2.6.15-mm1-full/drivers/net/s2io.h2006-01-05 21:10:33.0
+0100
@@ -64,7 +64,7 @@
#defineINTR_DBG4
/* Global variable that defines the present debug level of the driver. */
-int debug_level = ERR_DBG; /* Default level. */
+static int debug_level = ERR_DBG;
/* DEBUG message print. */
#define DBG_PRINT(dbg_level, args...) if(!(debug_leveldbg_level))
printk(args)
@@ -268,7 +268,7 @@
#define MAX_RX_RINGS 8
/* FIFO mappings for all possible number of fifos configured */
-int fifo_map[][MAX_TX_FIFOS] = {
+static int fifo_map[][MAX_TX_FIFOS] = {
{0, 0, 0, 0, 0, 0, 0, 0},
{0, 0, 0, 0, 1, 1, 1, 1},
{0, 0, 0, 1, 1, 1, 2, 2},
@@ -911,18 +911,16 @@
static void alarm_intr_handler(struct s2io_nic *sp);
static int s2io_starter(void);
-void s2io_closer(void);
static void s2io_tx_watchdog(struct net_device *dev);
static void s2io_tasklet(unsigned long dev_addr);
static void s2io_set_multicast(struct net_device *dev);
static int rx_osm_handler(ring_info_t *ring_data, RxD_t * rxdp);
-void s2io_link(nic_t * sp, int link);
-void s2io_reset(nic_t * sp);
+static void s2io_link(nic_t * sp, int link);
#if defined(CONFIG_S2IO_NAPI)
static int s2io_poll(struct net_device *dev, int *budget);
#endif
static void s2io_init_pci(nic_t * sp);
-int s2io_set_mac_addr(struct net_device *dev, u8 * addr);
+static int s2io_set_mac_addr(struct net_device *dev, u8 * addr);
static void s2io_alarm_handle(unsigned long data);
static int s2io_enable_msi(nic_t *nic);
static irqreturn_t s2io_msi_handle(int irq, void *dev_id, struct pt_regs
*regs);
@@ -930,14 +928,13 @@
s2io_msix_ring_handle(int irq, void *dev_id, struct pt_regs *regs);
static irqreturn_t
s2io_msix_fifo_handle(int irq, void *dev_id, struct pt_regs *regs);
-int s2io_enable_msi_x(nic_t *nic);
static irqreturn_t s2io_isr(int irq, void *dev_id, struct pt_regs *regs);
static int verify_xena_quiescence(nic_t *sp, u64 val64, int flag);
static struct ethtool_ops netdev_ethtool_ops;
static void s2io_set_link(unsigned long data);
-int s2io_set_swapper(nic_t * sp);
+static int s2io_set_swapper(nic_t * sp);
static void s2io_card_down(nic_t *nic);
static int s2io_card_up(nic_t *nic);
-int get_xena_rev_id(struct pci_dev *pdev);
-void restore_xmsi_data(nic_t *nic);
+static int get_xena_rev_id(struct pci_dev *pdev);
+static void restore_xmsi_data(nic_t *nic);
#endif /* _S2IO_H */
--- linux-2.6.15-mm1-full/drivers/net/s2io.c.old2006-01-05
20:45:51.0 +0100
+++ linux-2.6.15-mm1-full/drivers/net/s2io.c2006-01-05 20:54:26.0
+0100
@@ -72,8 +72,8 @@
static char s2io_driver_name[] = Neterion;
static char s2io_driver_version[] = DRV_VERSION;
-int rxd_size[4] = {32,48,48,64};
-int rxd_count[4] = {127,85,85,63};
+static int rxd_size[4] = {32,48,48,64};
+static int rxd_count[4] = {127,85,85,63};
static inline int RXD_IS_UP2DT(RxD_t *rxdp)
{
@@ -2127,7 +2127,7 @@
}
}
-int fill_rxd_3buf(nic_t *nic, RxD_t *rxdp, struct sk_buff *skb)
+static int fill_rxd_3buf(nic_t *nic, RxD_t *rxdp, struct sk_buff *skb)
{
struct net_device *dev = nic-dev;
struct sk_buff *frag_list;
@@ -2852,7 +2852,7 @@
* void.
*/
-void s2io_reset(nic_t * sp)
+static void s2io_reset(nic_t * sp)
{
XENA_dev_config_t __iomem *bar0 = sp-bar0;
u64 val64;
@@ -2940,7 +2940,7 @@
* SUCCESS on success and FAILURE on failure.
*/
-int s2io_set_swapper(nic_t * sp)
+static int s2io_set_swapper(nic_t * sp)
{
struct net_device *dev = sp-dev;
XENA_dev_config_t __iomem *bar0 = sp-bar0;
@@ -3089,7 +3089,7 @@
return ret;
}
-void restore_xmsi_data(nic_t *nic)
+static void restore_xmsi_data(nic_t *nic)
{
XENA_dev_config_t __iomem *bar0 = nic-bar0;
u64 val64;
@@ -3180,7 +3180,7 @@
return 0;
}
-int s2io_enable_msi_x(nic_t *nic)
+static int s2io_enable_msi_x(nic_t *nic)
{
XENA_dev_config_t __iomem *bar0 = nic-bar0;
u64 tx_mat, rx_mat;
@@ -4128,7 +4128,7 @@
* as defined in errno.h file on failure.
*/
-int s2io_set_mac_addr(struct net_device *dev, u8 * addr)
+static int s2io_set_mac_addr(struct net_device *dev, u8 * addr)
{
nic_t *sp = dev-priv;
XENA_dev_config_t __iomem *bar0 = sp-bar0;
@@ -5713,7 +5713,7 @@
* void.
*/
-void s2io_link(nic_t * sp, int link)
+static void s2io_link(nic_t * sp, int link)
{
struct net_device *dev = (struct net_device *) sp-dev;
@@ -5738,7 +5738,7 @@
* returns the revision ID of the device.
*/
-int get_xena_rev_id(struct
[2.6 patch] move some code to net/ipx/af_ipx.c
This patch moves some code only used in this file to net/ipx/af_ipx.c .
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This version was slightly adapted to apply against Linus' current tree.
include/net/p8022.h | 13 -
net/802/Makefile | 14 ++---
net/802/p8022.c | 66 ---
net/802/p8023.c | 61 -
net/8021q/vlan.c |1
net/8021q/vlan_dev.c |1
net/ethernet/Makefile |2
net/ethernet/pe2.c| 39
net/ipx/af_ipx.c | 102 --
9 files changed, 106 insertions(+), 193 deletions(-)
--- linux-2.6.15-rc1-mm1-full/net/ethernet/Makefile.old 2005-11-18
02:15:17.0 +0100
+++ linux-2.6.15-rc1-mm1-full/net/ethernet/Makefile 2005-11-18
02:15:22.0 +0100
@@ -4,5 +4,3 @@
obj-y += eth.o
obj-$(CONFIG_SYSCTL) += sysctl_net_ether.o
-obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
-obj-$(subst m,y,$(CONFIG_ATALK)) += pe2.o
--- linux-2.6.15-rc1-mm1-full/net/8021q/vlan.c.old 2005-11-18
02:19:40.0 +0100
+++ linux-2.6.15-rc1-mm1-full/net/8021q/vlan.c 2005-11-18 02:19:46.0
+0100
@@ -26,7 +26,6 @@
#include linux/mm.h
#include linux/in.h
#include linux/init.h
-#include net/p8022.h
#include net/arp.h
#include linux/rtnetlink.h
#include linux/notifier.h
--- linux-2.6.15-rc1-mm1-full/net/8021q/vlan_dev.c.old 2005-11-18
02:19:55.0 +0100
+++ linux-2.6.15-rc1-mm1-full/net/8021q/vlan_dev.c 2005-11-18
02:19:58.0 +0100
@@ -29,7 +29,6 @@
#include linux/netdevice.h
#include linux/etherdevice.h
#include net/datalink.h
-#include net/p8022.h
#include net/arp.h
#include vlan.h
--- linux-2.6.15-rc1-mm1-full/net/ipx/af_ipx.c.old 2005-11-18
02:17:00.0 +0100
+++ linux-2.6.15-rc1-mm1-full/net/ipx/af_ipx.c 2005-11-18 02:26:01.0
+0100
@@ -48,10 +48,10 @@
#include linux/termios.h
#include net/ipx.h
-#include net/p8022.h
#include net/psnap.h
#include net/sock.h
#include net/tcp_states.h
+#include net/llc.h
#include asm/uaccess.h
@@ -1939,8 +1939,104 @@
.notifier_call = ipxitf_device_event,
};
-extern struct datalink_proto *make_EII_client(void);
-extern void destroy_EII_client(struct datalink_proto *);
+static int p8022_request(struct datalink_proto *dl, struct sk_buff *skb,
+unsigned char *dest)
+{
+ llc_build_and_send_ui_pkt(dl-sap, skb, dest, dl-sap-laddr.lsap);
+ return 0;
+}
+
+static struct datalink_proto *register_8022_client(unsigned char type,
+ int (*func)(struct sk_buff *skb,
+ struct net_device *dev,
+ struct packet_type *pt,
+ struct net_device
*orig_dev))
+{
+ struct datalink_proto *proto;
+
+ proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
+ if (proto) {
+ proto-type[0] = type;
+ proto-header_length= 3;
+ proto-request = p8022_request;
+ proto-sap = llc_sap_open(type, func);
+ if (!proto-sap) {
+ kfree(proto);
+ proto = NULL;
+ }
+ }
+ return proto;
+}
+
+static void unregister_8022_client(struct datalink_proto *proto)
+{
+ llc_sap_put(proto-sap);
+ kfree(proto);
+}
+
+/*
+ * Place an 802.3 header on a packet. The driver will do the mac
+ * addresses, we just need to give it the buffer length.
+ */
+static int p8023_request(struct datalink_proto *dl,
+struct sk_buff *skb, unsigned char *dest_node)
+{
+ struct net_device *dev = skb-dev;
+
+ dev-hard_header(skb, dev, ETH_P_802_3, dest_node, NULL, skb-len);
+ return dev_queue_xmit(skb);
+}
+
+/*
+ * Create an 802.3 client. Note there can be only one 802.3 client
+ */
+static struct datalink_proto *make_8023_client(void)
+{
+ struct datalink_proto *proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
+
+ if (proto) {
+ proto-header_length = 0;
+ proto-request = p8023_request;
+ }
+ return proto;
+}
+
+/*
+ * Destroy the 802.3 client.
+ */
+static void destroy_8023_client(struct datalink_proto *dl)
+{
+ kfree(dl);
+}
+
+static int pEII_request(struct datalink_proto *dl,
+ struct sk_buff *skb, unsigned char *dest_node)
+{
+ struct net_device *dev = skb-dev;
+
+ skb-protocol = htons(ETH_P_IPX);
+ if (dev-hard_header)
+ dev-hard_header(skb, dev, ETH_P_IPX,
+dest_node, NULL, skb-len);
+ return dev_queue_xmit(skb);
+}
+
+static struct datalink_proto *make_EII_client(void)
+{
+ struct datalink_proto *proto =
[2.6 patch] drivers/net/wireless/hostap/hostap_main.c shouldn't #include C files
This patch contains an attempt to properly build hostap.o without
#include'ing C files.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 5 Jan 2006
drivers/net/wireless/hostap/Makefile |3
drivers/net/wireless/hostap/hostap.h | 37 +++
drivers/net/wireless/hostap/hostap_80211.h|3
drivers/net/wireless/hostap/hostap_80211_rx.c | 11 +++
drivers/net/wireless/hostap/hostap_80211_tx.c | 15
drivers/net/wireless/hostap/hostap_ap.c | 36 ++
drivers/net/wireless/hostap/hostap_ap.h |2
drivers/net/wireless/hostap/hostap_common.h |3
drivers/net/wireless/hostap/hostap_info.c |3
drivers/net/wireless/hostap/hostap_ioctl.c| 12 ++-
drivers/net/wireless/hostap/hostap_main.c | 60 +-
drivers/net/wireless/hostap/hostap_proc.c |8 ++
drivers/net/wireless/hostap/hostap_wlan.h |4 +
include/net/ieee80211_crypt.h |1
14 files changed, 120 insertions(+), 78 deletions(-)
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/Makefile.old
2005-12-03 00:40:33.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/Makefile 2005-12-03
00:49:47.0 +0100
@@ -1,4 +1,5 @@
-hostap-y := hostap_main.o
+hostap-y := hostap_80211_rx.o hostap_80211_tx.o hostap_ap.o hostap_info.o \
+hostap_ioctl.o hostap_main.o hostap_proc.o
obj-$(CONFIG_HOSTAP) += hostap.o
obj-$(CONFIG_HOSTAP_CS) += hostap_cs.o
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap.h.old
2005-12-03 00:41:48.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap.h 2005-12-03
02:37:21.0 +0100
@@ -1,6 +1,15 @@
#ifndef HOSTAP_H
#define HOSTAP_H
+#include linux/ethtool.h
+
+#include hostap_wlan.h
+#include hostap_ap.h
+
+static const long freq_list[] = { 2412, 2417, 2422, 2427, 2432, 2437, 2442,
+ 2447, 2452, 2457, 2462, 2467, 2472, 2484 };
+#define FREQ_COUNT (sizeof(freq_list) / sizeof(freq_list[0]))
+
/* hostap.c */
extern struct proc_dir_entry *hostap_proc;
@@ -40,6 +49,26 @@
int prism2_sta_send_mgmt(local_info_t *local, u8 *dst, u16 stype,
u8 *body, size_t bodylen);
int prism2_sta_deauth(local_info_t *local, u16 reason);
+int prism2_wds_add(local_info_t *local, u8 *remote_addr,
+ int rtnl_locked);
+int prism2_wds_del(local_info_t *local, u8 *remote_addr,
+ int rtnl_locked, int do_not_remove);
+
+
+/* hostap_ap.c */
+
+int ap_control_add_mac(struct mac_restrictions *mac_restrictions, u8 *mac);
+int ap_control_del_mac(struct mac_restrictions *mac_restrictions, u8 *mac);
+void ap_control_flush_macs(struct mac_restrictions *mac_restrictions);
+int ap_control_kick_mac(struct ap_data *ap, struct net_device *dev, u8 *mac);
+void ap_control_kickall(struct ap_data *ap);
+void * ap_crypt_get_ptrs(struct ap_data *ap, u8 *addr, int permanent,
+struct ieee80211_crypt_data ***crypt);
+int prism2_ap_get_sta_qual(local_info_t *local, struct sockaddr addr[],
+ struct iw_quality qual[], int buf_size,
+ int aplist);
+int prism2_ap_translate_scan(struct net_device *dev, char *buffer);
+int prism2_hostapd(struct ap_data *ap, struct prism2_hostapd_param *param);
/* hostap_proc.c */
@@ -54,4 +83,12 @@
void hostap_info_process(local_info_t *local, struct sk_buff *skb);
+/* hostap_ioctl.c */
+
+extern const struct iw_handler_def hostap_iw_handler_def;
+extern struct ethtool_ops prism2_ethtool_ops;
+
+int hostap_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd);
+
+
#endif /* HOSTAP_H */
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_common.h.old
2005-12-03 01:19:43.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_common.h
2005-12-03 01:21:13.0 +0100
@@ -1,6 +1,9 @@
#ifndef HOSTAP_COMMON_H
#define HOSTAP_COMMON_H
+#include linux/types.h
+#include linux/if_ether.h
+
#define BIT(x) (1 (x))
#define MAC2STR(a) (a)[0], (a)[1], (a)[2], (a)[3], (a)[4], (a)[5]
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_wlan.h.old
2005-12-03 01:22:53.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_wlan.h
2005-12-03 01:26:43.0 +0100
@@ -1,6 +1,10 @@
#ifndef HOSTAP_WLAN_H
#define HOSTAP_WLAN_H
+#include linux/wireless.h
+#include linux/netdevice.h
+#include net/iw_handler.h
+
#include hostap_config.h
#include hostap_common.h
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_ap.h.old
2005-12-03 01:28:46.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/hostap/hostap_ap.h
2005-12-03 01:29:01.0 +0100
@@ -1,6 +1,8 @@
#ifndef HOSTAP_AP_H
#define HOSTAP_AP_H
+#include hostap_80211.h
+
/* AP data structures for STAs */
/* maximum number of frames to buffer per STA */
---
Re: [git patches] 2.6.x net driver updates
On Fri, Jan 13, 2006 at 08:28:13PM +0100, Sam Ravnborg wrote: On Fri, Jan 13, 2006 at 08:23:16PM +0100, Jens Axboe wrote: 'select' is really cool as a concept, but when you can't figure out why you cannot disable CONFIG_FOO because CONFIG_BAR selects it it's really annoying. Would be nice to actually be able to see if another option has selected this option. In menuconfig: Typing '?' on CONFIG_HOTPLUG revealed: Selected by: PCCARD || HOTPLUG_PCI PCI EXPERIMENTAL || FW_LOADER ... Is there any trick to see them all when they are longer than the line in the terminal (e.g. what selects FW_LOADER?)? Sam 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] 2.6.x net driver updates
On Sat, 14 Jan 2006 03:29:49 +0100 Adrian Bunk wrote: On Fri, Jan 13, 2006 at 08:28:13PM +0100, Sam Ravnborg wrote: On Fri, Jan 13, 2006 at 08:23:16PM +0100, Jens Axboe wrote: 'select' is really cool as a concept, but when you can't figure out why you cannot disable CONFIG_FOO because CONFIG_BAR selects it it's really annoying. Would be nice to actually be able to see if another option has selected this option. In menuconfig: Typing '?' on CONFIG_HOTPLUG revealed: Selected by: PCCARD || HOTPLUG_PCI PCI EXPERIMENTAL || FW_LOADER ... Is there any trick to see them all when they are longer than the line in the terminal (e.g. what selects FW_LOADER?)? Use the right/left arrow keys to scroll horizontally. --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
