* Re: pcnet32 devices with incorrect trident vendor ID
From: Jon Mason @ 2006-01-12 22:33 UTC (permalink / raw)
To: Don Fry
Cc: Matthew Wilcox, Daniel Drake, Jon Mason, mulix, linux-kernel,
netdev, linux-pci
In-Reply-To: <20060112222320.GA19668@us.ibm.com>
On Thu, Jan 12, 2006 at 02:23:20PM -0800, Don Fry wrote:
> There are just a few differences between the 2.4 (1.30h) version of
> pcnet32.c and the 2.6 (1.30j) version, as I have tried to keep them
> as similar as possible.
>
> The driver was changed in February 2004 to recognize the incorrect
> vendor ID so that the ppc workaround was no longer required, and so that
> the cards would work in non ppc systems. From the driver perspective
> the ppc workaround could be deleted.
>
> On my systems lspci shows all the devices with the correct name whether
> it is ppc or x86.
Funny, I get the following on my opteron system:
# lspci | grep Ethernet
0000:03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02)
0000:0e:01.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
>
> PPC:
> donf@elm3b48:/usr/src> lspci | grep Ethernet
> 0000:01:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 54)
> 0000:21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
> 0000:62:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0001:21:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44)
> 0001:31:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0001:41:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
> 0001:61:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
> donf@elm3b48:/usr/src>
>
> x86:
> [donf@elm3b45 linux-2.6.14-git11]$ lspci | grep Ethernet
> 00:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
> 00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
> 02:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 16)
> 02:06.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 36)
> 05:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
> 05:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
> 05:04.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
> [donf@elm3b45 linux-2.6.14-git11]$
>
> On Thu, Jan 12, 2006 at 04:24:35PM -0500, Bill Nottingham wrote:
> > Bill Nottingham (notting@redhat.com) said:
> > > I remember looking at this a while back. I think the corrected information
> > > is only being propagated to the 'vendor' file, and the write_config_word
> > > isn't actually updating the 'config' entry in sysfs.
> >
> > Ah, here's an example from the box I remember working on this on
> > (without the libpci change):
> >
> > root@pseries 0000:00:0c.0]# pwd
> > /sys/bus/pci/devices/0000:00:0c.0
> > [root@pseries 0000:00:0c.0]# lspci | grep 0c.0
> > 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
> > [root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
> > 00:0c.0 Class 0200: 1023:2000 (rev 26)
> > [root@pseries 0000:00:0c.0]# cat vendor
> > 0x1022
> > [root@pseries 0000:00:0c.0]# cat device
> > 0x2000
> > [root@pseries 0000:00:0c.0]# od -x config
> > 0000000 2310 0020 4701 8002 2600 0002 0048 0000
> > 0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
> > 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> > 0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
> > 0000100 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > 0000400
> >
> > Note that the config space is different than the vendor file. This
> > was with 2.6.9-ish, I don't have the box around any more to confirm
> > with something more recent.
> >
> > Bill
> --
> Don Fry
> brazilnut@us.ibm.com
>
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Andrew Morton @ 2006-01-12 22:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jgarzik, netdev, linux-kernel, Roman Zippel
In-Reply-To: <Pine.LNX.4.64.0601121423120.3535@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> 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?
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Jeff Garzik @ 2006-01-12 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0601121423120.3535@g5.osdl.org>
On Thu, Jan 12, 2006 at 02:30:19PM -0800, Linus Torvalds 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".
OK
> Otherwise people won't see it just because they don't have crypto enabled,
> which is not very user-friendly.
>
> Btw, why are these casts there? Either the functions are of the right
> type, or they aren't. In neither case is the cast correct.
>
> I do realize that there are comments in <net/iw_handler.h> that says that
> you should do the cast, but that's no excuse for crap or stupid code.
>
> If it's an issue of trying to make greppable code, why not have
> just the comment?
>
> > @@ -2378,6 +2566,15 @@ static const iw_handler atmel_handler[]
> > (iw_handler) atmel_get_encode, /* SIOCGIWENCODE */
> > (iw_handler) atmel_set_power, /* SIOCSIWPOWER */
> > (iw_handler) atmel_get_power, /* SIOCGIWPOWER */
> > + (iw_handler) NULL, /* -- hole -- */
> > + (iw_handler) NULL, /* -- hole -- */
> ...
>
> Hmm?
Welcome to the awful wireless driver API. This type crapola is a key
thing that needs changing, but its not the only thing. There are also
some nasty wireless APIs which do casts based on variable (passed-in)
struct offsets...
This needs to change to a type-safe thingy like struct ethtool_ops, but
the above is what we were lumped with.
Jeff
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Linus Torvalds @ 2006-01-12 22:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: jgarzik, netdev, linux-kernel, Roman Zippel
In-Reply-To: <20060112143938.5cf7d6a5.akpm@osdl.org>
On Thu, 12 Jan 2006, Andrew Morton 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..
So this isn't new..
Linus
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Adrian Bunk @ 2006-01-12 23:14 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linus Torvalds, Andrew Morton, netdev, linux-kernel
In-Reply-To: <20060112224227.GA26888@havoc.gtf.org>
On Thu, Jan 12, 2006 at 05:42:27PM -0500, Jeff Garzik wrote:
> On Thu, Jan 12, 2006 at 02:30:19PM -0800, Linus Torvalds 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".
>
> OK
>...
What was wrong with my patch [1] that did not only this, but also fixes
the same bug with AIRO_CS and removes all the #ifdef's for the
non-compiling CRYPTO=n case from the driver?
> Jeff
cu
Adrian
[1] http://lkml.org/lkml/2006/1/10/328
--
"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
^ permalink raw reply
* Re: [PATCH 2/4 - 2.6.15]net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-13 3:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, x25 maintainer,
David S. Miller, netdev, SP
In-Reply-To: <200601121924.02747.arnd@arndb.de>
Hi Arnd
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.
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.
Lastly, if anyone following this mail can help with adding this into the
next release, that would be really helpful. We are building a network
management application on linux for a telco and while they have
the support of the SuSE's and Redhat's, any patches accepted by the
kernel community makes a difference, besides saving us from building
custom patches. (BTW, the application used to run on HP-UX, we are now
porting it to linux).
Many Thanks
Shaun
------------------------------
ghostview:/home/spereira/x25_32/src/func_tests/server # uname -a
Linux ghostview 2.6.15-smp #9 SMP Fri Jan 13 12:43:27 EST 2006 x86_64
x86_64 x86_64 GNU/Linux
ghostview:/home/spereira/x25_32/src/func_tests/server # file server
server: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped
ghostview:/home/spereira/x25_32/src/func_tests/server # ./server
usage: server <local X.121 address> <interface name>
ghostview:/home/spereira/x25_32/src/func_tests/server # ./server
05052384500000 x25tap0
TEST1: create socket : passed
TEST2: bind socket : passed
TEST3: set subscription: passed
TEST4: set facilities: passed
**************
Window size in = 2
Window size out = 2
Packet size in = 7
Packet size out = 7
Reverse flag = 00
Throughput = DD
**************
TEST5: set call user data on listen passed
cud[ 0 ] = 02
cud[ 1 ] = 03
TEST6: set matchlength on listen socket handle passed
The time stamp is Fri Jan 13 13:37:17 2006
TEST7: listen on socket: passed
Waiting for X25 packets
-----------------------------------------------------------
On Thu, 2006-01-12 at 19:24 +0000, Arnd Bergmann wrote:
> On Thursday 12 January 2006 06:02, Shaun Pereira wrote:
> > +int compat_sock_get_timestamp(struct sock *sk, struct timeval __user
> > *userstamp)
> > +{
> > + struct compat_timeval __user *ctv;
> > + ctv = (struct compat_timeval __user*) userstamp;
> > + if(!sock_flag(sk, SOCK_TIMESTAMP))
> > + sock_enable_timestamp(sk);
> > + if(sk->sk_stamp.tv_sec == -1)
> > + return -ENOENT;
> > + if(sk->sk_stamp.tv_sec == 0)
> > + do_gettimeofday(&sk->sk_stamp);
> > + return copy_to_user(ctv, &sk->sk_stamp, sizeof(struct
> > compat_timeval)) ?
> > + -EFAULT : 0;
> > +}
>
> This looks wrong, you're not doing any conversion here.
> You cannot just copy sk_stamp to ctv, they are not compatible.
> See compat_sys_gettimeofday on how to copy a struct timeval
> correctly.
>
> The other patches look good.
>
> Arnd <><
^ permalink raw reply
* Re: Tx packet fragmentation?
From: Denis Vlasenko @ 2006-01-13 11:00 UTC (permalink / raw)
To: acx100-devel, netdev; +Cc: Andreas Mohr
In-Reply-To: <20060112165853.GA17789@rhlx01.fht-esslingen.de>
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
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: [PATCH 2/4 - 2.6.15]net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann @ 2006-01-13 11:46 UTC (permalink / raw)
To: spereira
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, x25 maintainer,
David S. Miller, netdev, SP
In-Reply-To: <1137122079.5589.34.camel@spereira05.tusc.com.au>
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 high tv_usec low
You code copies the first eight bytes of the 64 bit data structure
into the 32 bit data structure.
Arnd <><
^ permalink raw reply
* Re: WCONF, netlink based WE replacement.
From: Thomas Graf @ 2006-01-13 13:15 UTC (permalink / raw)
To: Michael Buesch; +Cc: linux-kernel, netdev
In-Reply-To: <200601121824.02892.mbuesch@freenet.de>
* Michael Buesch <mbuesch@freenet.de> 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.
^ permalink raw reply
* [2.6 patch] schedule SHAPER for removal
From: Adrian Bunk @ 2006-01-13 14:13 UTC (permalink / raw)
To: Alan Cox; +Cc: Andi Kleen, David Woodhouse, jgarzik, netdev, linux-kernel
In-Reply-To: <1136944738.28616.0.camel@localhost.localdomain>
On Wed, Jan 11, 2006 at 01:58:58AM +0000, 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 <bunk@stusta.de>
--- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old 2006-01-13 15:02:15.000000000 +0100
+++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt 2006-01-13 15:06:19.000000000 +0100
@@ -164,0 +165,6 @@
+---------------------------
+
+What: Traffic Shaper (CONFIG_SHAPER)
+When: July 2006
+Why: obsoleted by the code in net/sched/
+Who: Adrian Bunk <bunk@stusta.de
--- linux-2.6.15-mm3-full/drivers/net/Kconfig.old 2006-01-13 15:06:34.000000000 +0100
+++ linux-2.6.15-mm3-full/drivers/net/Kconfig 2006-01-13 15:06:49.000000000 +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
^ permalink raw reply
* Re: WCONF, netlink based WE replacement.
From: Stephen Hemminger @ 2006-01-13 17:55 UTC (permalink / raw)
To: Michael Buesch; +Cc: linux-kernel, netdev
In-Reply-To: <200601121824.02892.mbuesch@freenet.de>
On Thu, 12 Jan 2006 18:24:02 +0100
Michael Buesch <mbuesch@freenet.de> 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.
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Roman Zippel @ 2006-01-13 17:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, jgarzik, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0601121444030.3535@g5.osdl.org>
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
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Jens Axboe @ 2006-01-13 19:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, jgarzik, netdev, linux-kernel, Roman Zippel
In-Reply-To: <20060112143938.5cf7d6a5.akpm@osdl.org>
On Thu, Jan 12 2006, Andrew Morton wrote:
> Linus Torvalds <torvalds@osdl.org> 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
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Sam Ravnborg @ 2006-01-13 19:28 UTC (permalink / raw)
To: Jens Axboe
Cc: Andrew Morton, Linus Torvalds, jgarzik, netdev, linux-kernel,
Roman Zippel
In-Reply-To: <20060113192316.GX3945@suse.de>
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.
Sam
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Jens Axboe @ 2006-01-13 19:36 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Andrew Morton, Linus Torvalds, jgarzik, netdev, linux-kernel,
Roman Zippel
In-Reply-To: <20060113192813.GA10560@mars.ravnborg.org>
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
^ permalink raw reply
* wireless: recap of current issues (intro)
From: John W. Linville @ 2006-01-13 21:26 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Jiri Benc, Stefan Rompf, Mike Kershaw,
Krzysztof Halasa, Robert Hancock, Alistair John Strachan,
Dominik Brodowski, Denis Vlasenko, Danny van Dyk,
Stephen Hemminger, feyd, Chase Venters, Andreas Mohr,
Bas Vermeulen, Jean Tourrilhes, Daniel Drake, Ulrich Kunitz,
Phil Dibowitz, Simon Kelley, Michael Buesch, Marcel Holtmann,
Patrick McHardy, Ingo Oeser
In-Reply-To: <20060113195723.GB16166@tuxdriver.com>
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
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (configuration)
From: John W. Linville @ 2006-01-13 22:19 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213011.GE16166@tuxdriver.com>
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
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (compatibility)
From: John W. Linville @ 2006-01-13 22:20 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213126.GF16166@tuxdriver.com>
Compatibility
=============
The netlink configuration mechanism needs compatibility code to
translate wireless extension ioctls into netlink transactions.
We need to be an 802.11 stack (i.e. drivers need to handle 802.11
frames). Ethernet emulation is bound to paint us into a corner
eventually (if it hasn't already).
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?
802.11 framing may break older protocols (e.g. DECnet). I don't
see this as a big problem, as I imagine such installations aren't
rolling-out lots of WiFi...if I'm wrong, will the translational
bridging code resolve this issue?
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?
How about if WiPHY initialization triggered a netlink broadcast?
Then a daemon could monitor those broadcasts and create whatever wlan
devices (ethernet emulation, rfmon, none at all) that the daemon was
configured to create. How would this effect modprobe behaviour?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (stack)
From: John W. Linville @ 2006-01-13 22:22 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213200.GG16166@tuxdriver.com>
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.)
I think we need to rally as many driver writers as possible a) to
get into the kernel now; and, b) move away from duplicating stack
features. I don't see how to achieve that with the DeviceScape stack
in the short- or medium-term timeframe. I get the impression that
porting drivers from one stack to the other is not all that painful,
particularly in the ieee80211->DeviceScape direction. Is it reasonable
to expect short-term development to stay with the ieee80211 stack,
while planning either a migration to DeviceScape or a major ieee80211
overhaul based on the DeviceScape code?
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.
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (other issues)
From: John W. Linville @ 2006-01-13 22:24 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213237.GH16166@tuxdriver.com>
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
linville@tuxdriver.com
^ permalink raw reply
* wireless: recap of current issues (actions)
From: John W. Linville @ 2006-01-13 22:25 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113213311.GI16166@tuxdriver.com>
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
linville@tuxdriver.com
^ permalink raw reply
* Re: wireless: recap of current issues (configuration)
From: Johannes Berg @ 2006-01-13 22:32 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113221935.GJ16166@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]
[since none our replies made it to the lists, here mine are again.
apologies to those who see it twice, just skip it, I only pasted my
previous replies]
> 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?
IMHO there's not much point in allowing changes. I have a feeling that
might create icky issues you don't want to have to tackle when the
solution is easy by just not allowing it. Part of my thinking is that
different virtual types have different structures associated, so
changing it needs re-creating structures anyway. And different virtual
device types might even be provided by different kernel modules so you
don't carry around AP mode if you don't need it.
> 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?)
Right [global config targets wiphy]. I do think this is an important UI
issue that userspace will have to tackle, but I think the correct way
for the kernel is to surface this issue instead of creating workarounds.
> 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'm not sure this is worth it. While putting this into the WiPHY device
creates more logic there, putting knowledge like 'how many different
channels can this WiPHY device support' etc. into some representation
that can be used by the stack to decide is much more trouble than it is
worth.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: wireless: recap of current issues (compatibility)
From: Johannes Berg @ 2006-01-13 22:33 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113222054.GK16166@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
> The netlink configuration mechanism needs compatibility code to
> translate wireless extension ioctls into netlink transactions.
I think we could restrict this to allow ioctl configuration only if
there's just a single active virtual dev [excluding some special cases
like changing the mode which would (see above) require deactivating one
and activating another virtual dev. or is that not possible without
screwing up naming etc? that might get tricky if we disallow mode
changing, but can probably be worked around easier than allowing mode
changing, especially since this is to be deprecated]
> 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?
If you want the old userspace API to 'just work' you have to create one
default wlan device at WiPHY init.
> How about if WiPHY initialization triggered a netlink broadcast?
It definitely should, in any case.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH] [NETFILTER] x_tables
From: David S. Miller @ 2006-01-13 22:33 UTC (permalink / raw)
To: laforge; +Cc: netdev, netfilter-devel
In-Reply-To: <20060112204734.GQ4430@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Thu, 12 Jan 2006 21:47:34 +0100
> Finally, I included all the suggestions/comments for x_tables "take 5",
> ran the nfsim testsuite and feel confident that this is ready for prime
> time.
>
> Please apply this huge one for 2.6.16,
It's been in my tree since last night, I'll try to see if
I can get Linus to eat this along with TIPC which are the
last two major things I plan to try and merge.
Let's get into bug fix mode people...
^ permalink raw reply
* Re: wireless: recap of current issues (stack)
From: Johannes Berg @ 2006-01-13 22:34 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060113222259.GL16166@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
On Fri, 2006-01-13 at 17:22 -0500, John W. Linville wrote:
> 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?
Well, softmac doesn't really have too many issues [that make it
incompatible with the planned stuff, that is]. Right now it layers
above ieee80211_device, and it would continue doing so, with
ieee80211_device transformed into the representation of the virtual STA
device.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox