* Wireless: One small step towards a more perfect union...?
From: John W. Linville @ 2006-01-11 2:05 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060106042218.GA18974@havoc.gtf.org>
A few days ago, Jeff Garzik reminded us all of the grossly imperfect
state of wireless (802.11 aka WiFi) networking in Linux. First in
his list of key issues was the lack of a permanent maintainer for the
kernel wireless code. Jeff approached me to see if I was interested
in that role, and after some discussions with Jeff and others I have
agreed to assume it. Consequently...
I hereby claim responsibility for the state of wireless networking
support in the Linux kernel.
By that statement I do not mean to claim credit for that which has
already been done. Nor do I shoulder the blame for any missteps which
have occurred to date. I simply mean that I intend to do my best to
improve the wireless networking support in Linux at an observable rate
for the foreseeable future. I intend to do that both through my own
work and through facilitating and/or coordinating the work of others.
I intend to do so with the ultimate goal of achieving the same sort of
"best of breed" networking support for wireless that Linux already
enjoys in traditional networking technologies. I hope that I can
count on all of you for development, testing, and/or moral support
in that endeavour.
Who am I?
Hopefully many of you recognize me through my upstream contributions.
Others may have seen some of my work with Fedora and/or RHEL
(http://people.redhat.com/linville/). My recent announcement of
the Fedora-netdev line of kernels seems to have drawn a fair amount
of publicity.
Beyond that, I have spent a decade or so in networking, mostly with
LAN switches. I have good experience with LAN technologies, including
Token Ring, ATM, and especially Ethernet. I have considerably less
experience with 802.11, but I am building on that as quickly as I can.
I have no doubt that there are many with more 802.11 expertise than
I have. Still, I believe that I have enough expertise to combine with
my judgment and experience in order to carry-out this duty effectively.
Maintenance Plans
I will, of course, establish a public GIT tree to act as a repository
for wireless development. I have requested space at kernel.org, and
I will announce that location once the tree is established. In the
meantime, please copy me on any wireless and/or wireless-related
patches you may submit to make sure that I see them.
If you are the maintainer of an out-of-tree driver or other component
(e.g. softmac), please let me hear from you (publicly or privately).
I want to be sure to identify all the major stakeholders. I would
also like to hear your plans for getting your code into the tree... :-)
I realize there are some burning issues at the moment, especially the
DeviceScape vs. ieee80211 stack wars. I do not intend to pronounce
summary judgment on any issues here or in the immediate future.
Please do copy me on any important discussions, and feel free to
invite me into any pertinent mailing lists or IRC channels. I would
also love to hear about any ongoing projects, even if they may not
be ready to be discussed publicly.
Once again, I appreciate your support in this. I thank Jeff for the
role he has played to date and the role he will continue to play.
Likewise I thank all of the wireless contributors, including driver,
stack, and userland tool maintainers. I hope to enjoy your continued
contributions and your support.
May the Force be with us!
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [2.6 patch] drivers/net/{,wireless/}Kconfig: remove dead URL
From: Alan Cox @ 2006-01-11 2:00 UTC (permalink / raw)
To: Adrian Bunk; +Cc: David Woodhouse, jgarzik, netdev, linux-kernel
In-Reply-To: <20060111012141.GB29663@stusta.de>
On Mer, 2006-01-11 at 02:21 +0100, Adrian Bunk wrote:
> The Debian package lists as upstream a dead URL pointing to the SRPM for
> the package in RedHat 9...
As far as I'm concerned the Fedora/Red Hat RPM is "definitive", but
thats a bit like arguing which museum owns the 'original'.
Alan
^ permalink raw reply
* Re: [2.6 patch] drivers/net/{,wireless/}Kconfig: remove dead URL
From: Alan Cox @ 2006-01-11 1:58 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Woodhouse, Adrian Bunk, jgarzik, netdev, linux-kernel
In-Reply-To: <200601110153.21989.ak@suse.de>
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.
^ permalink raw reply
* Re: [2.6 patch] drivers/net/{,wireless/}Kconfig: remove dead URL
From: Adrian Bunk @ 2006-01-11 1:21 UTC (permalink / raw)
To: David Woodhouse; +Cc: jgarzik, netdev, linux-kernel
In-Reply-To: <1136940409.3435.126.camel@localhost.localdomain>
On Wed, Jan 11, 2006 at 12:46:48AM +0000, David Woodhouse wrote:
> On Wed, 2006-01-11 at 01:37 +0100, Adrian Bunk wrote:
> > shadow.cabi.net does no longer exist.
>
> Surely it would be better to point to the new home of these tools rather
> than removing the reference to them entirely?
If you know one I'm glad to rework my patch.
The Debian package lists as upstream a dead URL pointing to the SRPM for
the package in RedHat 9...
> dwmw2
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
^ permalink raw reply
* Re: [2.6 patch] drivers/net/{,wireless/}Kconfig: remove dead URL
From: Alan Cox @ 2006-01-11 1:08 UTC (permalink / raw)
To: David Woodhouse; +Cc: Adrian Bunk, jgarzik, netdev, linux-kernel
In-Reply-To: <1136940409.3435.126.camel@localhost.localdomain>
On Mer, 2006-01-11 at 00:46 +0000, David Woodhouse wrote:
> On Wed, 2006-01-11 at 01:37 +0100, Adrian Bunk wrote:
> > shadow.cabi.net does no longer exist.
>
> Surely it would be better to point to the new home of these tools rather
> than removing the reference to them entirely?
I don't think they have a current home as such. I've got the scarabd tar
ball here so you can archive that somewhere on infradead if you'd rather
a reference remain.
^ permalink raw reply
* Re: [2.6 patch] drivers/net/{,wireless/}Kconfig: remove dead URL
From: David Woodhouse @ 2006-01-11 1:06 UTC (permalink / raw)
To: Alan Cox; +Cc: Adrian Bunk, jgarzik, netdev, linux-kernel
In-Reply-To: <1136941684.27448.4.camel@localhost.localdomain>
On Wed, 2006-01-11 at 01:08 +0000, Alan Cox wrote:
> I don't think they have a current home as such. I've got the scarabd
> tar ball here so you can archive that somewhere on infradead if you'd
> rather a reference remain.
ftp.uk.linux.org would probably make more sense.
--
dwmw2
^ permalink raw reply
* Re: [2.6 patch] drivers/net/{,wireless/}Kconfig: remove dead URL
From: Andi Kleen @ 2006-01-11 0:53 UTC (permalink / raw)
To: David Woodhouse; +Cc: Adrian Bunk, jgarzik, netdev, linux-kernel
In-Reply-To: <1136940409.3435.126.camel@localhost.localdomain>
On Wednesday 11 January 2006 01:46, David Woodhouse wrote:
> On Wed, 2006-01-11 at 01:37 +0100, Adrian Bunk wrote:
> > shadow.cabi.net does no longer exist.
>
> Surely it would be better to point to the new home of these tools rather
> than removing the reference to them entirely?
shaper is completely obsolete and it's probably best to just remove
all references to it and the kernel driver too.
-Andi
^ permalink raw reply
* Re: [2.6 patch] drivers/net/{,wireless/}Kconfig: remove dead URL
From: David Woodhouse @ 2006-01-11 0:46 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jgarzik, netdev, linux-kernel
In-Reply-To: <20060111003747.GJ3911@stusta.de>
On Wed, 2006-01-11 at 01:37 +0100, Adrian Bunk wrote:
> shadow.cabi.net does no longer exist.
Surely it would be better to point to the new home of these tools rather
than removing the reference to them entirely?
--
dwmw2
^ permalink raw reply
* [2.6 patch] drivers/net/{,wireless/}Kconfig: remove dead URL
From: Adrian Bunk @ 2006-01-11 0:37 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
shadow.cabi.net does no longer exist.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/Kconfig | 4 ----
drivers/net/wireless/Kconfig | 4 ----
2 files changed, 8 deletions(-)
--- linux-2.6.15-mm2-full/drivers/net/Kconfig.old 2006-01-11 01:14:12.000000000 +0100
+++ linux-2.6.15-mm2-full/drivers/net/Kconfig 2006-01-11 01:16:43.000000000 +0100
@@ -2663,10 +2663,6 @@
Class-Based Queueing (CBQ) scheduling support which you get if you
say Y to "QoS and/or fair queueing" above.
- To set up and configure shaper devices, you need the shapecfg
- program, available from <ftp://shadow.cabi.net/pub/Linux/> in the
- shaper package.
-
To compile this driver as a module, choose M here: the module
will be called shaper. If unsure, say N.
--- linux-2.6.15-mm2-full/drivers/net/wireless/Kconfig.old 2006-01-11 01:16:56.000000000 +0100
+++ linux-2.6.15-mm2-full/drivers/net/wireless/Kconfig 2006-01-11 01:17:08.000000000 +0100
@@ -24,10 +24,6 @@
the tools from
<http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
- Some user-level drivers for scarab devices which don't require
- special kernel support are available from
- <ftp://shadow.cabi.net/pub/Linux/>.
-
# Note : the cards are obsolete (can't buy them anymore), but the drivers
# are not, as people are still using them...
comment "Obsolete Wireless cards support (pre-802.11)"
^ permalink raw reply
* Re: RFC: kill acx100-devel, migrate to netdev@vger.kernel.org
From: Carlos Martín @ 2006-01-10 23:16 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: acx100-devel, netdev
In-Reply-To: <200601100829.47592.vda@ilport.com.ua>
On Tuesday 10 January 2006 07:29, Denis Vlasenko wrote:
> Hi folks,
>
> Please read http://lkml.org/lkml/2006/1/5/671
>
> What about moving all acx development discussion
> to netdev@vger.kernel.org?
Sure, if the driver ships with mainline. Until it does, it would be OT here,
IMO.
>
> If yes, can acx100-devel address be automatically
> redirected?
If you'd like for people to still be able to use acx100-devel as before,
you'd have to forward everything back and forth, and a discussion that started
in netdev wouldn't have an easy way to get copied to acx100-devel unless it
was manually CCd.
I think it'd be easier just to tell people that discussion happens at netdev
from now/whenever on.
cmn
--
Carlos Martín http://www.cmartin.tk
-------------------------------------------------------
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_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* Re: [2.6 patch] drivers/net/irda/Kconfig: DONGLE_OLD: remove dependency on non-existing symbol
From: David S. Miller @ 2006-01-10 21:11 UTC (permalink / raw)
To: bunk; +Cc: netdev, linux-kernel, reiga
In-Reply-To: <20060110170903.GQ3911@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Tue, 10 Jan 2006 18:09:03 +0100
> Jean-Luc Leger <reiga@dspnet.fr.eu.org> reported this alternative
> dependency on a non-existing symbol.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks.
^ permalink raw reply
* [ANNOUNCE] iproute2 2.6.15-060110
From: Stephen Hemminger @ 2006-01-10 19:25 UTC (permalink / raw)
To: netdev; +Cc: linux-net
Update to iproute2 is available. Most of the changes were to repair the
things that broke with the introduction of the batch mode to the ip command.
http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.15-060110.tar.gz
For information see:
http://linux-net.osdl.org/index.php/Iproute2
Recent changes
Masahide NAKAMURA
Add ip link ntable
Stephen Hemminger
Update headers to santized kernel 2.6.15
Fix ipv6 priority option in u32
Add corrupt feature for netem
Jamal Hadi Salim
Add ifb documention
Patrick McHardy
Add back ip command aliases
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* [2.6 patch] drivers/net/irda/Kconfig: DONGLE_OLD: remove dependency on non-existing symbol
From: Adrian Bunk @ 2006-01-10 17:09 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Jean-Luc Leger
Jean-Luc Leger <reiga@dspnet.fr.eu.org> reported this alternative
dependency on a non-existing symbol.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.15-mm2-full/drivers/net/irda/Kconfig.old 2006-01-10 17:48:41.000000000 +0100
+++ linux-2.6.15-mm2-full/drivers/net/irda/Kconfig 2006-01-10 17:48:59.000000000 +0100
@@ -1,4 +1,3 @@
-
menu "Infrared-port device drivers"
depends on IRDA!=n
@@ -156,7 +155,7 @@
config DONGLE_OLD
bool "Old Serial dongle support"
- depends on (IRTTY_OLD || IRPORT_SIR) && BROKEN_ON_SMP
+ depends on IRPORT_SIR && BROKEN_ON_SMP
help
Say Y here if you have an infrared device that connects to your
computer's serial port. These devices are called dongles. Then say Y
^ permalink raw reply
* Transmit timeout with E1000
From: Erik Mouw @ 2006-01-10 15:12 UTC (permalink / raw)
To: e1000-devel; +Cc: netdev
Hi,
I have lots of transmit timeouts with an Intel E1000 card during large
TCP transmissions (remotely viewing a 3000x2000 jpeg image using XV is
an excellent way to trigger it). This is what I get in linux-2.6.8.1:
Jan 10 15:24:41 zurix kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jan 10 15:24:41 zurix kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
Jan 10 15:24:46 zurix kernel: nfs: server abra2 not responding, still trying
Jan 10 15:24:46 zurix kernel: nfs: server abra2 OK
And this is with linux-2.6.15:
Jan 10 06:53:27 zurix kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Jan 10 06:53:27 zurix kernel: TDH <b0>
Jan 10 06:53:27 zurix kernel: TDT <b0>
Jan 10 06:53:27 zurix kernel: next_to_use <b0>
Jan 10 06:53:27 zurix kernel: next_to_clean <c3>
Jan 10 06:53:27 zurix kernel: buffer_info[next_to_clean]
Jan 10 06:53:27 zurix kernel: dma <e938a5e>
Jan 10 06:53:27 zurix kernel: time_stamp <872de93>
Jan 10 06:53:27 zurix kernel: next_to_watch <c3>
Jan 10 06:53:27 zurix kernel: jiffies <872e086>
Jan 10 06:53:27 zurix kernel: next_to_watch.status <0>
Jan 10 06:53:29 zurix kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Jan 10 06:53:29 zurix kernel: TDH <b0>
Jan 10 06:53:29 zurix kernel: TDT <b0>
Jan 10 06:53:29 zurix kernel: next_to_use <b0>
Jan 10 06:53:29 zurix kernel: next_to_clean <c3>
Jan 10 06:53:29 zurix kernel: buffer_info[next_to_clean]
Jan 10 06:53:29 zurix kernel: dma <e938a5e>
Jan 10 06:53:29 zurix kernel: time_stamp <872de93>
Jan 10 06:53:29 zurix kernel: next_to_watch <c3>
Jan 10 06:53:29 zurix kernel: jiffies <872e27a>
Jan 10 06:53:29 zurix kernel: next_to_watch.status <0>
Jan 10 06:53:31 zurix kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Jan 10 06:53:31 zurix kernel: TDH <b0>
Jan 10 06:53:31 zurix kernel: TDT <b0>
Jan 10 06:53:31 zurix kernel: next_to_use <b0>
Jan 10 06:53:31 zurix kernel: next_to_clean <c3>
Jan 10 06:53:31 zurix kernel: buffer_info[next_to_clean]
Jan 10 06:53:31 zurix kernel: dma <e938a5e>
Jan 10 06:53:31 zurix kernel: time_stamp <872de93>
Jan 10 06:53:31 zurix kernel: next_to_watch <c3>
Jan 10 06:53:31 zurix kernel: jiffies <872e46e>
Jan 10 06:53:31 zurix kernel: next_to_watch.status <0>
Jan 10 06:53:32 zurix kernel: nfs: server abra2 not responding, still trying
Jan 10 06:53:33 zurix kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jan 10 06:53:36 zurix kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
Jan 10 06:53:37 zurix kernel: nfs: server abra2 OK
The system is a an AMD Athlon XP 2000+ running at 1.666 GHz with a VIA
KT400 chipset (Asrock K7VT4APro).
Here's the relevant output from lspci:
0000:00:0b.0 Ethernet controller: Intel Corporation 82541PI Gigabit
Ethernet Controller (rev 05)
Subsystem: Intel Corporation: Unknown device 1376
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (63750ns min), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 19
Region 0: Memory at dffc0000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at dffa0000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at d400 [size=64]
Expansion ROM at fffe0000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [e4] PCI-X non-bridge device.
Command: DPERE- ERO+ RBC=0 OST=0
Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, DC=simple, DMMRBC=2, DMOST=0, DMCRS=0, RSCEM-
00: 86 80 7c 10 17 00 30 02 05 00 00 02 08 20 00 00
10: 00 00 fc df 00 00 fa df 01 d4 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 76 13
30: 00 00 fe ff dc 00 00 00 00 00 00 00 0c 01 ff 00
Loaded modules (with 2.6.8.1): nfsd exportfs sd_mod sg lp sr_mod
autofs4 nfs lockd sunrpc ide_cd cdrom floppy parport_pc parport
8250_pnp 8250 serial_core snd_via82xx snd_ac97_codec snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart
snd_rawmidi snd_seq_device snd soundcore joydev evdev ehci_hcd usbhid
uhci_hcd usbcore sata_via libata e1000 reiserfs mga via_agp agpgart .
So far I have replaced the NIC, the motherboard, the power supply, RAM,
network cable, and gigE switch, but to no avail. I've tried three
different kernels (2.6.8.1, 2.6.11-ac7, and 2.6.15) but the problem
remains. I've been stress testing the system by continuously compiling
kernels (over NFS), but after 288 runs there hasn't been a single error
so I guess the CPU and RAM are OK. The amount of transmit timeouts is
less with linux-2.6.8.1, so for the moment I keep running that version.
We have about 15 other machines using the Intel E1000, but I haven't
seen these kind of problems on any of the other machines. I have run
out of ideas, so I hope somebody knows how to solve this. If you need
more information, just let me know.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
-------------------------------------------------------
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: [2.6.15] running tcpdump on 3c905b causes freeze (reproducable)
From: Folkert van Heusden @ 2006-01-10 14:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, linux-kernel
In-Reply-To: <20060109224821.7a40bc69.akpm@osdl.org>
> > > > Have you tried enabling the NMI watchdog? Enable CONFIG_X86_LOCAL_APIC and
> > > > boot with `nmi_watchdog=1' on the command line, make sure that the NMI line
> > > > of /proc/interrupts is incrementing.
> > > I'll give it a try. I've added it to the append-line in the lilo config.
> > > Am now compiling the kernel.
> > No change. Well, that is: the last message on the console now is
> > "setting eth1 to promiscues mode".
> Did you confirm that the NMI counters in /proc/interrupts are incrementing?
Yes:
root@muur:/home/folkert# for i in `seq 1 5` ; do cat /proc/interrupts | grep NMI ; sleep 1 ; done
NMI: 6949080 6949067
NMI: 6949182 6949169
NMI: 6949284 6949271
NMI: 6949386 6949373
NMI: 6949488 6949475
Folkert van Heusden
--
Try MultiTail! Multiple windows with logfiles, filtered with regular
expressions, colored output, etc. etc. www.vanheusden.com/multitail/
----------------------------------------------------------------------
Get your PGP/GPG key signed at www.biglumber.com!
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* Re: State of the Union: Wireless
From: Johannes Berg @ 2006-01-10 13:18 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: Jeff Garzik, netdev, linux-kernel
In-Reply-To: <200601071649.35321.vda@ilport.com.ua>
Denis Vlasenko wrote:
> I am confused.
Which isn't really all that surprising.
> ftp://ftp.berlios.de/pub/bcm43xx/snapshots/softmac/ieee80211softmac-20060107.tar.bz2
> which is not the same. For example, ieee80211softmac.h file exists in both
> tarballs but is not identical.
>
> Suppose one wants to use softmac in a project. What tarball contains
> the bleeding edge of softmac?
The one from the softmac page is created from the git repository. The one
on the bcm page is created from the now historical mercurial archive.
I need to get the bcm people to take away that snapshot and link to the
correct one.
johannes
^ permalink raw reply
* Re: [PATCH 2/2 - 2.6.15]net:32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann @ 2006-01-10 13:00 UTC (permalink / raw)
To: spereira
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, x25 maintainer,
netdev, SP
In-Reply-To: <1136871083.5742.27.camel@spereira05.tusc.com.au>
On Tuesday 10 January 2006 05:31, Shaun Pereira wrote:
> --- linux-2.6.15-vanilla/include/net/x25.h 2006-01-03 14:21:10.000000000
> +1100
> +++ linux-2.6.15/include/net/x25.h 2006-01-10 16:15:16.000000000 +1100
> @@ -223,6 +223,18 @@ extern struct x25_route *x25_get_route(s
> extern struct net_device *x25_dev_get(char *);
> extern void x25_route_device_down(struct net_device *dev);
> extern int x25_route_ioctl(unsigned int, void __user *);
> +
> +#ifdef CONFIG_COMPAT
> +#include <linux/compat.h>
Don't hide #include <...> inside #ifdef, just add this in the beginning.
> +
> +struct x25_route_struct32{
> + struct x25_address address;
> + compat_uint_t sigdigits;
> + char device[200];
> +};
> +extern int compat_x25_route_ioctl(unsigned int, struct
> x25_route_struct32 __user *);
> +#endif
> +
Hmm. Declarations should not be hidden by #ifdef either, but of course
compat_uint_t is not defined on 32 bit systems.
Actually, the structure should already be the same on all 32 and 64 bit
systems, there is no 'long' or pointer in there.
I'm pretty sure you can simply call x25_route_ioctl instead of
introducing a new compat_x25_route_ioctl(), or did you have a different
reason to do this?
> extern void x25_route_free(void);
>
> static __inline__ void x25_route_hold(struct x25_route *rt)
> diff -uprN -X dontdiff linux-2.6.15-vanilla/net/x25/af_x25.c
> linux-2.6.15/net/x25/af_x25.c
> --- linux-2.6.15-vanilla/net/x25/af_x25.c 2006-01-10 16:06:29.000000000
> +1100
> +++ linux-2.6.15/net/x25/af_x25.c 2006-01-10 16:15:16.000000000 +1100
> @@ -475,6 +475,12 @@ out:
>
> void x25_init_timers(struct sock *sk);
>
> +#ifdef CONFIG_COMPAT
> +#include "x25_ioctl_compat.c"
> +#else
> +#define compat_x25_ioctl NULL
> +#endif
> +
No, this is not a good way to do it. It's good put it in a separate file,
if the compat code is large, but then better use Makefile magic to do
conditional compilation, like:
obj-$(CONFIG_X25) += x25.o
x25-$(CONFIG_COMPAT) += x25_ioctl_compat.o
[ OTOH, with the changes I propose below, it probably becomes so small
that it's no longer worth doing a separate file. ]
> static int x25_create(struct socket *sock, int protocol)
> {
> struct sock *sk;
> @@ -1403,7 +1409,7 @@ static struct proto_ops SOCKOPS_WRAPPED(
> .getname = x25_getname,
> .poll = datagram_poll,
> .ioctl = x25_ioctl,
> - .compat_ioctl= NULL,
> + .compat_ioctl= compat_x25_ioctl,
> .listen = x25_listen,
> .shutdown = sock_no_shutdown,
> .setsockopt = x25_setsockopt,
Then this normally becomes
.poll = datagram_poll,
.ioctl = x25_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl= compat_x25_ioctl,
+#endif
.listen = x25_listen,
.shutdown = sock_no_shutdown,
or you change the declaration in the header file to become
#ifdef CONFIG_COMPAT
extern long compat_x25_ioctl(struct file *, unsigned int, unsigned long);
#else
#define compat_x25_ioctl NULL
#endif
> diff -uprN -X dontdiff linux-2.6.15-vanilla/net/x25/x25_ioctl_compat.c
> linux-2.6.15/net/x25/x25_ioctl_compat.c
> --- linux-2.6.15-vanilla/net/x25/x25_ioctl_compat.c 1970-01-01
> 10:00:00.000000000 +1000
> +++ linux-2.6.15/net/x25/x25_ioctl_compat.c 2006-01-10
> 16:15:16.000000000 +1100
> @@ -0,0 +1,264 @@
> +#include <linux/compat.h>
> +
> +struct x25_subscrip_struct32{
> + char device[200-sizeof(compat_ulong_t)];
> + compat_ulong_t global_facil_mask;
> + compat_uint_t extended;
> +};
Please don't use a compat_ prefix instead of a 32 postfix,
i.e. compat_x25_subscrip_struct.
> +
> +struct x25_facilities32{
> + compat_uint_t winzize_in, winsize_out;
> + compat_uint_t pacsize_in, packsize_out;
> + compat_uint_t throughput;
> + compat_uint_t reverse;
> +};
> +
> +struct x25_calluserdata32 {
> + compat_uint_t cudlength;
> + unsigned char cuddata[128];
> +};
> +
> +struct x25_subaddr32 {
> + compat_uint_t cudmatchlength;
> +};
These should all be compatible and not need a conversion at all.
> +
> +static int compat_x25_subscr_ioctl(unsigned int cmd,
> + struct x25_subscrip_struct32 __user *x25_subscr32)
> +{
> ...
that function looks good.
> +static int compat_x25_facility_ioctl(struct socket *sock, struct
> x25_facilities32 __user *facilities32)
> +static int compat_x25_get_facility_ioctl(struct socket *sock, struct
> x25_facilities32 __user *facility32)
> +static int compat_x25_cud_ioctl(struct socket *sock, struct
> x25_calluserdata32 __user *calluserdata32)
> +static int compat_x25_get_cud_ioctl(struct socket *sock, struct
> x25_calluserdata32 __user *calluserdata32)
> +static int compat_x25_cud_match_ioctl(struct socket *sock, struct
> x25_subaddr32 __user *sub_addr32)
> +static int compat_x25_accept_ctrl(struct socket *sock, unsigned int
> cmd)
All these appear pointless to me, as the arguments are the same as in
the native 64 bit case.
> +
> +static int compat_x25_ioctl(struct socket *sock, unsigned int cmd,
> unsigned long arg)
> ...
> + case SIOCX25GFACILITIES:
> + rc = compat_x25_get_facility_ioctl(sock, argp);
> + break;
> + case SIOCX25SFACILITIES:
> + rc = compat_x25_facility_ioctl(sock, argp);
> + break;
> + case SIOCX25GCALLUSERDATA:
> + rc = compat_x25_get_cud_ioctl(sock, argp);
> + break;
> + case SIOCX25SCALLUSERDATA:
> + rc = compat_x25_cud_ioctl(sock, argp);
> + break;
> + case SIOCX25GCAUSEDIAG:
> + case SIOCX25SCUDMATCHLEN:
> + rc = compat_x25_cud_match_ioctl(sock,argp);
> + break;
> + case SIOCX25CALLACCPTAPPRV:
> + rc = compat_x25_accept_ctrl(sock,SIOCX25CALLACCPTAPPRV);
> + break;
> + case SIOCX25SENDCALLACCPT:
> + rc = compat_x25_accept_ctrl(sock,SIOCX25SENDCALLACCPT);
> + break;
Then these could become
+ case SIOCX25GFACILITIES:
+ case SIOCX25SFACILITIES:
+ case SIOCX25GCALLUSERDATA:
+ case SIOCX25SCALLUSERDATA:
+ case SIOCX25GCAUSEDIAG:
+ case SIOCX25SCUDMATCHLEN:
+ case SIOCX25CALLACCPTAPPRV:
+ case SIOCX25SENDCALLACCPT:
+ rc = x25_ioctl(sock, cmd, (unsigned long)argp);
+ break;
The casting argp to unsigned long instead of using arg takes care of
the pointer type problem, so it even works on s390 (your code did as well).
> +#ifdef CONFIG_COMPAT
> +
> +int compat_x25_route_ioctl(unsigned int cmd, struct x25_route_struct32
> __user *rt32)
> +{
AFAICS; this function is identical to x25_route_ioctl, so just call that
one.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/2 RESEND- 2.6.15] net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann @ 2006-01-10 12:03 UTC (permalink / raw)
To: spereira
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, x25 maintainer,
netdev, SP
In-Reply-To: <1136871078.5742.26.camel@spereira05.tusc.com.au>
On Tuesday 10 January 2006 05:31, Shaun Pereira wrote:
> Hi Arnd, Arnaldo
> Thanks for your comments. I initially did not wish to change any of the
> other modules, but based on Arnd's comments I have removed the
> extra macro, SOCKOPS_COMPAT_WRAP and use the original SOCKOPS_WRAP.
Ok, looks better now. Just a few tiny style comments:
> +++ linux-2.6.15/net/appletalk/ddp.c 2006-01-10 15:56:55.000000000 +1100
> @@ -1852,6 +1852,7 @@ static struct proto_ops SOCKOPS_WRAPPED(
> .getname = atalk_getname,
> .poll = datagram_poll,
> .ioctl = atalk_ioctl,
> + .compat_ioctl = NULL,
> .listen = sock_no_listen,
> .shutdown = sock_no_shutdown,
> .setsockopt = sock_no_setsockopt,
No need to set .compat_ioctl to NULL, that's what it already is when you
don't assign it at all. Leaving it out makes it easier to grep for users.
> @@ -709,6 +710,7 @@ static struct proto_ops SOCKOPS_WRAPPED(
> .getname = econet_getname,
> .poll = datagram_poll,
> .ioctl = econet_ioctl,
> + .compat_ioctl= NULL,
> .listen = sock_no_listen,
> .shutdown = sock_no_shutdown,
> .setsockopt = sock_no_setsockopt,
> diff -uprN -X dontdiff linux-2.6.15-vanilla/net/ipx/af_ipx.c
> linux-2.6.15/net/ipx/af_ipx.c
> --- linux-2.6.15-vanilla/net/ipx/af_ipx.c 2006-01-03 14:21:10.000000000
> +1100
> +++ linux-2.6.15/net/ipx/af_ipx.c 2006-01-10 15:56:55.000000000 +1100
> @@ -1912,6 +1912,7 @@ static struct proto_ops SOCKOPS_WRAPPED(
> .getname = ipx_getname,
> .poll = datagram_poll,
> .ioctl = ipx_ioctl,
> + .compat_ioctl = NULL,
> .listen = sock_no_listen,
> .shutdown = sock_no_shutdown, /* FIXME: support shutdown */
> .setsockopt = ipx_setsockopt,
> diff -uprN -X dontdiff linux-2.6.15-vanilla/net/irda/af_irda.c
> linux-2.6.15/net/irda/af_irda.c
> --- linux-2.6.15-vanilla/net/irda/af_irda.c 2006-01-03
> 14:21:10.000000000 +1100
> +++ linux-2.6.15/net/irda/af_irda.c 2006-01-10 15:56:55.000000000 +1100
> @@ -2474,6 +2474,7 @@ static struct proto_ops SOCKOPS_WRAPPED(
> .getname = irda_getname,
> .poll = irda_poll,
> .ioctl = irda_ioctl,
> + .compat_ioctl= NULL,
> .listen = irda_listen,
> .shutdown = irda_shutdown,
> .setsockopt = irda_setsockopt,
> @@ -2495,6 +2496,7 @@ static struct proto_ops SOCKOPS_WRAPPED(
> .getname = irda_getname,
> .poll = datagram_poll,
> .ioctl = irda_ioctl,
> + .compat_ioctl= NULL,
> .listen = irda_listen,
> .shutdown = irda_shutdown,
> .setsockopt = irda_setsockopt,
> @@ -2516,6 +2518,7 @@ static struct proto_ops SOCKOPS_WRAPPED(
> .getname = irda_getname,
> .poll = datagram_poll,
> .ioctl = irda_ioctl,
> + .compat_ioctl= NULL,
> .listen = irda_listen,
> .shutdown = irda_shutdown,
> .setsockopt = irda_setsockopt,
> @@ -2538,6 +2541,7 @@ static struct proto_ops SOCKOPS_WRAPPED(
> .getname = irda_getname,
> .poll = datagram_poll,
> .ioctl = irda_ioctl,
> + .compat_ioctl= NULL,
> .listen = sock_no_listen,
> .shutdown = irda_shutdown,
> .setsockopt = irda_setsockopt,
> static struct proto_ops SOCKOPS_WRAPPED(x25_proto_ops) = {
> .family = AF_X25,
> .owner = THIS_MODULE,
> @@ -1402,6 +1403,7 @@ static struct proto_ops SOCKOPS_WRAPPED(
> .getname = x25_getname,
> .poll = datagram_poll,
> .ioctl = x25_ioctl,
> + .compat_ioctl= NULL,
> .listen = x25_listen,
> .shutdown = sock_no_shutdown,
> .setsockopt = x25_setsockopt,
>
>
Same comment applies to all these.
> +static long compat_sock_ioctl(struct file *file, unsigned cmd, unsigned
> long arg)
> +{
> + struct socket *sock;
> + sock = file->private_data;
> +
> + int ret = -ENOIOCTLCMD;
> + if(sock->ops->compat_ioctl) {
> + ret = sock->ops->compat_ioctl(sock,cmd,arg);
> + }
Leave out the curly braces here and put a space between the function
arguments, so it becomes
+ if(sock->ops->compat_ioctl)
+ ret = sock->ops->compat_ioctl(sock, cmd, arg);
Arnd <><
^ permalink raw reply
* Re: Re: State of the Union: Wireless
From: Andreas Mohr @ 2006-01-10 10:41 UTC (permalink / raw)
To: acx100-devel; +Cc: Jeff Garzik, netdev, linux-kernel
In-Reply-To: <200601100839.26052.vda@ilport.com.ua>
Hi,
On Tue, Jan 10, 2006 at 08:39:25AM +0200, Denis Vlasenko wrote:
> On Friday 06 January 2006 06:22, Jeff Garzik wrote:
> >
> > State of the Union - Wireless
> > January 5, 2006
>
> [ snip ]
>
> > * Wireless drivers and the wireless stack need to be maintained IN-TREE
> > as a COLLECTIVE ENTITY, not piecemeal maintenance as its done now.
> >
> > The whole point of working in-tree, the whole point of this open source
> > thing is that everybody works on the same code, and the entire Internet
> > is your test bed. Quality improves the more people work together.
> > The entire Linux kernel engineering process is focused on getting core
> > kernel code out to distributions (then to end users) and power users.
> > Out-of-tree code breaks that model, breaking the It Just Works(tm)
> > theme applicable to other Linux-supported hardware.
>
> Cool, so may I please know why acx driver is not included in the mainline?
> In case it needs more work, well, (a) at least tell us what exactly
> you want improved, and (b) why do you think that in-tree acx would not
> be improved? It will get more visibility, maybe some people will
> get interested and will send a patch or two to us...
I think wording is a tad bit too aggressive here, since we (well, at least me)
haven't made many efforts to get it included, since we had to work out
some things. However at this point we should really go for inclusion,
the sooner the better (right?).
> > * Release early, release often. Pushing from an external repository to
> > the official kernel tree every few months creates more problems
> > than it solves. Out-of-tree drivers fail to take advantage of
> > recent kernel changes and coding practices, which leads to bugs and
> > incompatibilities. Slow pushing leads to huge periodic updates,
> > which are awful for debugging, testing, and general use.
>
> I want to avoid exactly this, and therefore want acx in mainline.
ACK.
> How are we going to find out which stack is best and which stack
> we should concentrate our efforts on? In an absense of wifi maintainer,
> maybe we should throw _all stacks_ (currently two) into the mainline,
> and evolution will find the best one. Yes, it would be a bit ugly
> at first, but I hope it will speed up evolution a lot.
I have to admit that a big item on our acx ToDo list was the missing ieee80211
integration, but now that there's a second stack on the horizon and things
look less decided I'm not that much troubled by our lack of ieee80211 use
any more ;)
That said, of course we should try to get rid of our own, historic (originating
from binary TI driver!) in-driver stack very soon.
I won't do any comments on which stack to use, though, I will do research first
and then work out which one to use depending on popularity and features
matching our chips' properties.
Andreas Mohr
-------------------------------------------------------
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
* [PATCH] net: fix PRIO qdisc bands init
From: Amnon Aaronsohn @ 2006-01-10 10:30 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
The PRIO queuing discipline currently initializes only the bands
that appear in the priomap. It should instead initialize all the
configured bands.
Signed-off-by: Amnon Aaronsohn <bla@cs.huji.ac.il>
---
--- linux-2.6.14/net/sched/sch_prio.c 2005-10-28 02:02:08.000000000 +0200
+++ work-2.6.14/net/sched/sch_prio.c 2006-01-10 12:02:20.000000000 +0200
@@ -227,14 +227,13 @@ static int prio_tune(struct Qdisc *sch,
}
sch_tree_unlock(sch);
- for (i=0; i<=TC_PRIO_MAX; i++) {
- int band = q->prio2band[i];
- if (q->queues[band] == &noop_qdisc) {
+ for (i=0; i<q->bands; i++) {
+ if (q->queues[i] == &noop_qdisc) {
struct Qdisc *child;
child = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops);
if (child) {
sch_tree_lock(sch);
- child = xchg(&q->queues[band], child);
+ child = xchg(&q->queues[i], child);
if (child != &noop_qdisc)
qdisc_destroy(child);
^ permalink raw reply
* Re: State of the Union: Wireless
From: Chase Venters @ 2006-01-10 8:36 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: Jeff Garzik, netdev, linux-kernel, acx100-devel
In-Reply-To: <200601100839.26052.vda@ilport.com.ua>
On Tuesday 10 January 2006 00:39, Denis Vlasenko wrote:
> How are we going to find out which stack is best and which stack
> we should concentrate our efforts on? In an absense of wifi maintainer,
> maybe we should throw _all stacks_ (currently two) into the mainline,
> and evolution will find the best one. Yes, it would be a bit ugly
> at first, but I hope it will speed up evolution a lot.
>
> Let current stack sit in include/net/ieee80211*.h and net/ieee80211/*,
> add dcape one into include/net/wlan*.h and net/wlan/*
> (s/wlan/dscape/ or whatever)
>
> We can even give Devicescape folks blanket permissions to
> maintain their stack in include/net/wlan*.h and net/wlan/*.
> Maybe they can act as a wifi maintainer long term.
>
> Existing drivers won't need to closely track every change
> in dscape stack. If dscape will survive, old drivers can be
> converted to it gradually. If not, just dike it out.
I don't like the idea of maintaining two of anything. What if I have two
wireless interfaces, each using a different stack?
Performance--,
Kernel size++
I get that it's hard to get everyone to agree on one stack or another, but we
need to make the decision now because the longer we don't have a decision
made (this includes maintaining two in-tree stacks) the longer it's going to
take us to have serious / robust / reliable / consistent wireless support.
I know basically nothing about 802.11, but it seems to me that what should
happen is that if there is sufficient motivation to boot ieee80211 in favor
of DeviceScape, someone should cook up the patches.
Besides, assume we did bless two stacks. Every new driver / driver that wanted
to go mainline would choose one or another (it's already clear that people
disagree). Thus we end up with *more* work to do in order to decide one way
or another (since we have to partially break & fully port all the drivers
from one stack to another).
There's incompatibility all over this wireless landscape. The best way to deal
with it is to make all the big hard decisions now - say "this is the way it's
going to be" and work from there. We can always undo mistakes later, but
we'll never get to that point if we don't start moving in one direction
instead of ten.
> --
> vda
> -
Cheers,
Chase
^ permalink raw reply
* Re: [2.6.15] running tcpdump on 3c905b causes freeze (reproducable)
From: Andrew Morton @ 2006-01-10 6:48 UTC (permalink / raw)
To: Folkert van Heusden; +Cc: netdev, linux-kernel
In-Reply-To: <20060109193754.GD12673@vanheusden.com>
Folkert van Heusden <folkert@vanheusden.com> wrote:
>
> > > Have you tried enabling the NMI watchdog? Enable CONFIG_X86_LOCAL_APIC and
> > > boot with `nmi_watchdog=1' on the command line, make sure that the NMI line
> > > of /proc/interrupts is incrementing.
> > I'll give it a try. I've added it to the append-line in the lilo config.
> > Am now compiling the kernel.
>
> No change. Well, that is: the last message on the console now is
> "setting eth1 to promiscues mode".
>
Did you confirm that the NMI counters in /proc/interrupts are incrementing?
^ permalink raw reply
* Re: State of the Union: Wireless
From: Denis Vlasenko @ 2006-01-10 6:39 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, acx100-devel
In-Reply-To: <20060106042218.GA18974@havoc.gtf.org>
On Friday 06 January 2006 06:22, Jeff Garzik wrote:
>
> State of the Union - Wireless
> January 5, 2006
[ snip ]
> * Wireless drivers and the wireless stack need to be maintained IN-TREE
> as a COLLECTIVE ENTITY, not piecemeal maintenance as its done now.
>
> The whole point of working in-tree, the whole point of this open source
> thing is that everybody works on the same code, and the entire Internet
> is your test bed. Quality improves the more people work together.
> The entire Linux kernel engineering process is focused on getting core
> kernel code out to distributions (then to end users) and power users.
> Out-of-tree code breaks that model, breaking the It Just Works(tm)
> theme applicable to other Linux-supported hardware.
Cool, so may I please know why acx driver is not included in the mainline?
In case it needs more work, well, (a) at least tell us what exactly
you want improved, and (b) why do you think that in-tree acx would not
be improved? It will get more visibility, maybe some people will
get interested and will send a patch or two to us...
> * Release early, release often. Pushing from an external repository to
> the official kernel tree every few months creates more problems
> than it solves. Out-of-tree drivers fail to take advantage of
> recent kernel changes and coding practices, which leads to bugs and
> incompatibilities. Slow pushing leads to huge periodic updates,
> which are awful for debugging, testing, and general use.
I want to avoid exactly this, and therefore want acx in mainline.
> * ALL wireless stacks need work. It is currently fashionable to laud
> DeviceScape and trash in-kernel ieee80211, but outside of the
> cheerleading, BOTH have real technical issues that need addressing.
> IOW, no matter what code is chosen, _somebody_ is on the hook for
> a fair amount of work. A switch is not without its costs.
>
> * I would prefer that people patch the in-tree ieee80211 code,
> probably in the direction of Jiri Benc's proposed ieee80211_device
> direction. I take patches from all parties, not just Intel.
>
> * However, if the engineering reasons for switching to DeviceScape
> or another wireless stack are powerful enough to overcome Linux's
> "no big patches, evolve it" maxim, great! But make sure to work
> on converting drivers to this new stack. The wireless drivers and
> wireless stack should evolve in tandem. Otherwise, drivers get
> left behind, grow moldy, and Linux users suffer.
How are we going to find out which stack is best and which stack
we should concentrate our efforts on? In an absense of wifi maintainer,
maybe we should throw _all stacks_ (currently two) into the mainline,
and evolution will find the best one. Yes, it would be a bit ugly
at first, but I hope it will speed up evolution a lot.
Let current stack sit in include/net/ieee80211*.h and net/ieee80211/*,
add dcape one into include/net/wlan*.h and net/wlan/*
(s/wlan/dscape/ or whatever)
We can even give Devicescape folks blanket permissions to
maintain their stack in include/net/wlan*.h and net/wlan/*.
Maybe they can act as a wifi maintainer long term.
Existing drivers won't need to closely track every change
in dscape stack. If dscape will survive, old drivers can be
converted to it gradually. If not, just dike it out.
> * Feel free to submit radical changes -- wireless is yet young --
> just make sure all drivers keep working from release to release.
>
> * Long term, wireless should go from being a library of common code to a
> "real" wireless stack, as shown in the template developed by David Miller:
> http://kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2
> Zhu Yi @ Intel and Vladmir @ somewhere both independently did some
> work in this area.
>
> * Please CC wireless stack/driver discussions to netdev@vger.kernel.org
> mailing list, rather than everybody hiding in their own little
> corner.
[snip]
> So... there it is. We suck. There's hope. No Luke Skywalker in sight.
> I hope we can avoid being slaves to fashion, by merging a rewrite, but
> that way be the way to go.
--
vda
^ permalink raw reply
* RFC: kill acx100-devel, migrate to netdev@vger.kernel.org
From: Denis Vlasenko @ 2006-01-10 6:29 UTC (permalink / raw)
To: acx100-devel; +Cc: netdev
Hi folks,
Please read http://lkml.org/lkml/2006/1/5/671
What about moving all acx development discussion
to netdev@vger.kernel.org?
If yes, can acx100-devel address be automatically
redirected?
--
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
* [2.6.15 patch] wireless/atmel: add IWENCODEEXT, IWAUTH, and association event support
From: Dan Williams @ 2006-01-10 5:56 UTC (permalink / raw)
To: simon; +Cc: netdev, jgarzik
Hi,
This patch allows the Atmel driver to work correctly with wpa_supplicant
and other programs that require some conformance with WEXT-18. It
should not affect current behavior of the driver. The patch does four
things:
1) Implements SIOCSIWENCODEEXT, SIOCGIWENCODEEXT, SIOCSIWAUTH, and
SIOCGIWAUTH calls for unencrypted and WEP operation
2) Accepts zero-filled addresses for SIOCSIWAP, which are legal and
should turn off any previous forced WAP address
3) Sends association and de-association events to userspace at most of
the appropriate times
4) Fixes erroneous order of CIPHER_SUITE_WEP_* arguments in one location
which are actually unused anyway
Signed-off-by: Dan Williams <dcbw@redhat.com>
--- a/drivers/net/wireless/atmel.c 2006-01-09 12:45:00.000000000 -0500
+++ b/drivers/net/wireless/atmel.c 2006-01-10 00:10:46.000000000 -0500
@@ -1407,6 +1407,17 @@
{
struct atmel_private *priv = netdev_priv(dev);
+ /* Send event to userspace that we are disassociating */
+ if (priv->station_state == STATION_STATE_READY) {
+ union iwreq_data wrqu;
+
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN);
+ wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
+ }
+
atmel_enter_state(priv, STATION_STATE_DOWN);
if (priv->bus_type == BUS_TYPE_PCCARD)
@@ -1780,10 +1791,10 @@
priv->wep_is_on = 1;
priv->exclude_unencrypted = 1;
if (priv->wep_key_len[index] > 5) {
- priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_64;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_128;
priv->encryption_level = 2;
} else {
- priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_128;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_64;
priv->encryption_level = 1;
}
}
@@ -1853,6 +1864,181 @@
return 0;
}
+static int atmel_set_encodeext(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu,
+ char *extra)
+{
+ struct atmel_private *priv = netdev_priv(dev);
+ struct iw_point *encoding = &wrqu->encoding;
+ struct iw_encode_ext *ext = (struct iw_encode_ext *)extra;
+ int idx, key_len;
+
+ /* Determine and validate the key index */
+ idx = encoding->flags & IW_ENCODE_INDEX;
+ if (idx) {
+ if (idx < 1 || idx > WEP_KEYS)
+ return -EINVAL;
+ idx--;
+ } else
+ idx = priv->default_key;
+
+ if ((encoding->flags & IW_ENCODE_DISABLED) ||
+ ext->alg == IW_ENCODE_ALG_NONE) {
+ priv->wep_is_on = 0;
+ priv->encryption_level = 0;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_NONE;
+ }
+
+ if (ext->ext_flags & IW_ENCODE_EXT_SET_TX_KEY)
+ priv->default_key = idx;
+
+ /* Set the requested key */
+ switch (ext->alg) {
+ case IW_ENCODE_ALG_NONE:
+ break;
+ case IW_ENCODE_ALG_WEP:
+ if (ext->key_len > 5) {
+ priv->wep_key_len[idx] = 13;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_128;
+ priv->encryption_level = 2;
+ } else if (ext->key_len > 0) {
+ priv->wep_key_len[idx] = 5;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_64;
+ priv->encryption_level = 1;
+ } else {
+ return -EINVAL;
+ }
+ priv->wep_is_on = 1;
+ memset(priv->wep_keys[idx], 0, 13);
+ key_len = min ((int)ext->key_len, priv->wep_key_len[idx]);
+ memcpy(priv->wep_keys[idx], ext->key, key_len);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return -EINPROGRESS;
+}
+
+static int atmel_get_encodeext(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu,
+ char *extra)
+{
+ struct atmel_private *priv = netdev_priv(dev);
+ struct iw_point *encoding = &wrqu->encoding;
+ struct iw_encode_ext *ext = (struct iw_encode_ext *)extra;
+ int idx, max_key_len;
+
+ max_key_len = encoding->length - sizeof(*ext);
+ if (max_key_len < 0)
+ return -EINVAL;
+
+ idx = encoding->flags & IW_ENCODE_INDEX;
+ if (idx) {
+ if (idx < 1 || idx > WEP_KEYS)
+ return -EINVAL;
+ idx--;
+ } else
+ idx = priv->default_key;
+
+ encoding->flags = idx + 1;
+ memset(ext, 0, sizeof(*ext));
+
+ if (!priv->wep_is_on) {
+ ext->alg = IW_ENCODE_ALG_NONE;
+ ext->key_len = 0;
+ encoding->flags |= IW_ENCODE_DISABLED;
+ } else {
+ if (priv->encryption_level > 0)
+ ext->alg = IW_ENCODE_ALG_WEP;
+ else
+ return -EINVAL;
+
+ ext->key_len = priv->wep_key_len[idx];
+ memcpy(ext->key, priv->wep_keys[idx], ext->key_len);
+ encoding->flags |= IW_ENCODE_ENABLED;
+ }
+
+ return 0;
+}
+
+static int atmel_set_auth(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu, char *extra)
+{
+ struct atmel_private *priv = netdev_priv(dev);
+ struct iw_param *param = &wrqu->param;
+
+ switch (param->flags & IW_AUTH_INDEX) {
+ case IW_AUTH_WPA_VERSION:
+ case IW_AUTH_CIPHER_PAIRWISE:
+ case IW_AUTH_CIPHER_GROUP:
+ case IW_AUTH_KEY_MGMT:
+ case IW_AUTH_RX_UNENCRYPTED_EAPOL:
+ case IW_AUTH_PRIVACY_INVOKED:
+ /*
+ * atmel does not use these parameters
+ */
+ break;
+
+ case IW_AUTH_DROP_UNENCRYPTED:
+ priv->exclude_unencrypted = param->value ? 1 : 0;
+ break;
+
+ case IW_AUTH_80211_AUTH_ALG: {
+ if (param->value & IW_AUTH_ALG_SHARED_KEY) {
+ priv->exclude_unencrypted = 1;
+ } else if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
+ priv->exclude_unencrypted = 0;
+ } else
+ return -EINVAL;
+ break;
+ }
+
+ case IW_AUTH_WPA_ENABLED:
+ /* Silently accept disable of WPA */
+ if (param->value > 0)
+ return -EOPNOTSUPP;
+ break;
+
+ default:
+ return -EOPNOTSUPP;
+ }
+ return -EINPROGRESS;
+}
+
+static int atmel_get_auth(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu, char *extra)
+{
+ struct atmel_private *priv = netdev_priv(dev);
+ struct iw_param *param = &wrqu->param;
+
+ switch (param->flags & IW_AUTH_INDEX) {
+ case IW_AUTH_DROP_UNENCRYPTED:
+ param->value = priv->exclude_unencrypted;
+ break;
+
+ case IW_AUTH_80211_AUTH_ALG:
+ if (priv->exclude_unencrypted == 1)
+ param->value = IW_AUTH_ALG_SHARED_KEY;
+ else
+ param->value = IW_AUTH_ALG_OPEN_SYSTEM;
+ break;
+
+ case IW_AUTH_WPA_ENABLED:
+ param->value = 0;
+ break;
+
+ default:
+ return -EOPNOTSUPP;
+ }
+ return 0;
+}
+
+
static int atmel_get_name(struct net_device *dev,
struct iw_request_info *info,
char *cwrq,
@@ -2289,13 +2475,15 @@
{
struct atmel_private *priv = netdev_priv(dev);
int i;
- static const u8 bcast[] = { 255, 255, 255, 255, 255, 255 };
+ static const u8 any[] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
+ static const u8 off[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
unsigned long flags;
if (awrq->sa_family != ARPHRD_ETHER)
return -EINVAL;
- if (memcmp(bcast, awrq->sa_data, 6) == 0) {
+ if (!memcmp(any, awrq->sa_data, 6) ||
+ !memcmp(off, awrq->sa_data, 6)) {
del_timer_sync(&priv->management_timer);
spin_lock_irqsave(&priv->irqlock, flags);
atmel_scan(priv, 1);
@@ -2378,6 +2566,15 @@
(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 -- */
+ (iw_handler) NULL, /* SIOCSIWGENIE */
+ (iw_handler) NULL, /* SIOCGIWGENIE */
+ (iw_handler) atmel_set_auth, /* SIOCSIWAUTH */
+ (iw_handler) atmel_get_auth, /* SIOCGIWAUTH */
+ (iw_handler) atmel_set_encodeext, /* SIOCSIWENCODEEXT */
+ (iw_handler) atmel_get_encodeext, /* SIOCGIWENCODEEXT */
+ (iw_handler) NULL, /* SIOCSIWPMKSA */
};
static const iw_handler atmel_private_handler[] =
@@ -2924,6 +3121,8 @@
u16 ass_id = le16_to_cpu(ass_resp->ass_id);
u16 rates_len = ass_resp->length > 4 ? 4 : ass_resp->length;
+ union iwreq_data wrqu;
+
if (frame_len < 8 + rates_len)
return;
@@ -2954,6 +3153,14 @@
priv->station_is_associated = 1;
priv->station_was_associated = 1;
atmel_enter_state(priv, STATION_STATE_READY);
+
+ /* Send association event to userspace */
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ memcpy(wrqu.ap_addr.sa_data, priv->CurrentBSSID, ETH_ALEN);
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
+
return;
}
@@ -3632,6 +3839,7 @@
struct atmel_private *priv = netdev_priv(dev);
u8 configuration;
+ int old_state = priv->station_state;
/* data to add to the firmware names, in priority order
this implemenents firmware versioning */
@@ -3792,6 +4000,17 @@
else
build_wep_mib(priv);
+ if (old_state == STATION_STATE_READY)
+ {
+ union iwreq_data wrqu;
+
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN);
+ wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
+ }
+
return 1;
}
^ 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