[PATCH] Add 32bit emulation for wireless

[PATCH] Add 32bit emulation for wireless

[Andi Kleen]

[First version of this mail seems to have gotten lost. Apologies if you
see it twice]

Some distributions call iwconfig at every bootup and I was sick of 
seeing all the unimplemented ioctl messages on AMD64 with a 32bit userland.

This patch implements ioctl emulation for the wireless subsytem.
The only structure that was incompatible from visual inspection was
"iw_point". The rest is just passed through.

It reuses the existing ioctl description table, but renames it to 
export it (standard_ioctls wasn't a good name for a global variable) 

I don't actually have have a working wireless card (only some non supported
Samsung one), so I wasn't able to test it, but at least the messages
are gone.

-Andi

diff -u linux-2.6.1-amd64/net/core/wireless.c-WIRELESS linux-2.6.1-amd64/net/core/wireless.c
--- linux-2.6.1-amd64/net/core/wireless.c-WIRELESS	2003-10-09 00:29:02.000000000 +0200
+++ linux-2.6.1-amd64/net/core/wireless.c	2004-01-17 18:46:58.000000000 +0100
@@ -27,7 +27,7 @@
  *	o Initial dumb commit strategy based on orinoco.c
  *
  * v3 - 19.12.01 - Jean II
- *	o Make sure we don't go out of standard_ioctl[] in ioctl_standard_call
+ *	o Make sure we don't go out of wireless_ioctl[] in ioctl_standard_call
  *	o Add event dispatcher function
  *	o Add event description
  *	o Propagate events as rtnetlink IFLA_WIRELESS option
@@ -91,7 +91,7 @@
  * Meta-data about all the standard Wireless Extension request we
  * know about.
  */
-static const struct iw_ioctl_description standard_ioctl[] = {
+const struct iw_ioctl_description wireless_ioctl[] = {
 	[SIOCSIWCOMMIT	- SIOCIWFIRST] = {
 		.header_type	= IW_HEADER_TYPE_NULL,
 	},
@@ -266,7 +266,7 @@
 		.header_type	= IW_HEADER_TYPE_PARAM,
 	},
 };
-static const int standard_ioctl_num = (sizeof(standard_ioctl) /
+const int wireless_ioctl_num = (sizeof(wireless_ioctl) /
 				       sizeof(struct iw_ioctl_description));
 
 /*
@@ -593,9 +593,9 @@
 	int					user_size = 0;
 
 	/* Get the description of the IOCTL */
-	if((cmd - SIOCIWFIRST) >= standard_ioctl_num)
+	if((cmd - SIOCIWFIRST) >= wireless_ioctl_num)
 		return -EOPNOTSUPP;
-	descr = &(standard_ioctl[cmd - SIOCIWFIRST]);
+	descr = &(wireless_ioctl[cmd - SIOCIWFIRST]);
 
 #ifdef WE_IOCTL_DEBUG
 	printk(KERN_DEBUG "%s (WE) : Found standard handler for 0x%04X\n",
@@ -1041,8 +1041,8 @@
 	/* Get the description of the IOCTL */
 	if(cmd <= SIOCIWLAST) {
 		cmd_index = cmd - SIOCIWFIRST;
-		if(cmd_index < standard_ioctl_num)
-			descr = &(standard_ioctl[cmd_index]);
+		if(cmd_index < wireless_ioctl_num)
+			descr = &(wireless_ioctl[cmd_index]);
 	} else {
 		cmd_index = cmd - IWEVFIRST;
 		if(cmd_index < standard_event_num)
diff -u linux-2.6.1-amd64/fs/compat_ioctl.c-WIRELESS linux-2.6.1-amd64/fs/compat_ioctl.c
--- linux-2.6.1-amd64/fs/compat_ioctl.c-WIRELESS	2004-01-01 06:25:25.000000000 +0100
+++ linux-2.6.1-amd64/fs/compat_ioctl.c	2004-01-17 19:02:44.000000000 +0100
@@ -65,6 +65,8 @@
 #include <linux/ncp_fs.h>
 #include <linux/i2c.h>
 #include <linux/i2c-dev.h>
+#include <linux/wireless.h>
+#include <net/iw_handler.h>
 
 #include <net/sock.h>          /* siocdevprivate_ioctl */
 #include <net/bluetooth/bluetooth.h>
@@ -706,6 +708,69 @@
 	return err;
 }
 
+#ifdef CONFIG_NET_RADIO
+
+extern const struct iw_ioctl_description wireless_ioctl[];
+extern int wireless_ioctl_num;
+
+/* assumes no padding */
+struct iw_point32 { 
+	compat_uptr_t pointer;
+	u16 length;
+	u16 flags; 
+}; 
+
+struct iwreq32 { 
+	char ifrn_name[IFNAMSIZ]; 
+	struct iw_point32 iw_point; 
+};
+
+static int wireless_ioctl32(unsigned int fd, unsigned int cmd, unsigned long arg)
+{ 
+	int num = cmd - SIOCIWFIRSTPRIV;
+	if (num >= wireless_ioctl_num) { 
+		printk(KERN_DEBUG "%s: unknown wireless ioctl %x\n", current->comm, cmd);
+		return -EINVAL;
+	}
+
+	/* only iw_point needs conversion right now. If any others do add them
+	   to this switch. */ 
+
+	switch (wireless_ioctl[num].header_type) { 
+	case IW_HEADER_TYPE_POINT: { 
+		int err;
+		compat_uptr_t ptr;
+		struct iwreq32 *i32 = (struct iwreq32 *)arg;
+		struct iwreq i, *iu = compat_alloc_user_space(sizeof(struct iwreq));
+
+		if (!access_ok(VERIFY_READ, i32, sizeof(struct iwreq32)))
+			return -EFAULT;
+		
+		err = __copy_from_user(i.ifr_ifrn.ifrn_name, i32->ifrn_name,IFNAMSIZ);
+		err |= __get_user(ptr, &i32->iw_point.pointer); 
+		i.u.essid.pointer = compat_ptr(ptr);
+		err |= __get_user(i.u.essid.length, &i32->iw_point.length); 
+		err |= __get_user(i.u.essid.flags, &i32->iw_point.flags);; 
+		if (!err) 
+			err |= copy_to_user(iu, &i, sizeof(struct iwreq));
+		if (err) 
+			return -EFAULT;
+
+		arg = (unsigned long) iu; 			
+		break;
+	}
+	} 
+
+	return sys_ioctl(fd, cmd, arg);
+} 
+#else
+/* stub to avoid warning */
+static int wireless_ioctl32(unsigned int fd, unsigned int cmd, unsigned long arg)
+{ 
+	return -ENOTTY; 
+} 
+#endif
+
 struct rtentry32 {
         u32   		rt_pad1;
         struct sockaddr rt_dst;         /* target address               */
@@ -3133,6 +3198,39 @@
 HANDLE_IOCTL(I2C_FUNCS, w_long)
 HANDLE_IOCTL(I2C_RDWR, do_i2c_rdwr_ioctl)
 HANDLE_IOCTL(I2C_SMBUS, do_i2c_smbus_ioctl)
+/* wireless */
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+0,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+1,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+2,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+3,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+4,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+5,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+6,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+7,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+8,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+9,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+10,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+11,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+12,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+13,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+14,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+15,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+16,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+17,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+18,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+19,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+20,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+21,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+22,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+23,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+24,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+25,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+26,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+27,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+28,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+29,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+30,wireless_ioctl32)
+HANDLE_IOCTL(SIOCIWFIRSTPRIV+31,wireless_ioctl32)
 
 #undef DECLARES
 #endif

Re: [PATCH] Add 32bit emulation for wireless

[Christoph Hellwig]

On Mon, Jan 19, 2004 at 01:33:43PM +0100, Andi Kleen wrote:
> It reuses the existing ioctl description table, but renames it to 
> export it (standard_ioctls wasn't a good name for a global variable) 

What about register_ioctl32_conversion() from the wireless code to avoid
exposing it?

Re: [PATCH] Add 32bit emulation for wireless

[Andi Kleen]

On Mon, 19 Jan 2004 12:39:45 +0000
Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Jan 19, 2004 at 01:33:43PM +0100, Andi Kleen wrote:
> > It reuses the existing ioctl description table, but renames it to 
> > export it (standard_ioctls wasn't a good name for a global variable) 
> 
> What about register_ioctl32_conversion() from the wireless code to avoid
> exposing it?

At least for net/* stuff it seems to be standard to do it in the central file.
All other networking ioctls are implemented this way too.

-Andi

Re: [PATCH] Add 32bit emulation for wireless

[David S. Miller]

Andi please see the current 2.6.x BK tree, I already put in
preliminary work in this area.

Re: [PATCH] Add 32bit emulation for wireless

[Andi Kleen]

On Mon, 19 Jan 2004 05:56:15 -0800
"David S. Miller" <davem@redhat.com> wrote:

> 
> Andi please see the current 2.6.x BK tree, I already put in
> preliminary work in this area.

Went it in after 2.6.1? 2.6.1 definitely spews out warnings for it
at every boot, that is why I did this. If it's already fixed that's fine
for me of course.

-Andi

Re: [PATCH] Add 32bit emulation for wireless

[David S. Miller]

On Mon, 19 Jan 2004 15:39:19 +0100
Andi Kleen <ak@suse.de> wrote:

> Went it in after 2.6.1?

Yes, Linus sucked it in like 10 hours ago, about 4 hours right before you made
your initial posting on this thread.

Re: [PATCH] Add 32bit emulation for wireless

[Andi Kleen]

On Mon, 19 Jan 2004 06:39:21 -0800
"David S. Miller" <davem@redhat.com> wrote:

> On Mon, 19 Jan 2004 15:39:19 +0100
> Andi Kleen <ak@suse.de> wrote:
> 
> > Went it in after 2.6.1?
> 
> Yes, Linus sucked it in like 10 hours ago, about 4 hours right before you made
> your initial posting on this thread.

Oh, I actually posted it yesterday but due a broken MTA it didn't go out @)
But I didn't check BK anyways so it would not have made much difference.

-Andi

Re: [PATCH] Add 32bit emulation for wireless

[Jean Tourrilhes]

On Mon, Jan 19, 2004 at 01:33:43PM +0100, Andi Kleen wrote:
> 
> Some distributions call iwconfig at every bootup and I was sick of 
> seeing all the unimplemented ioctl messages on AMD64 with a 32bit userland.
> 
> This patch implements ioctl emulation for the wireless subsytem.
> The only structure that was incompatible from visual inspection was
> "iw_point". The rest is just passed through.
> 
> It reuses the existing ioctl description table, but renames it to 
> export it (standard_ioctls wasn't a good name for a global variable) 

	I'm glad that you found the ioctl description table useful,
the code look neat and simple. When I did redesign the driver API in
WE-13, ioctl emulation for 64 bits was definitely on my mind (thanks
to Dave warning me about it). Also, from the very start, the API was
defined with explicitely sized types, which help.

	However, this is my prefered way to do things. I would much
prefer to see you using native version of the Wireless Tools,
especially that the tools and the kernel need to be in sync as far as
version is concerned. It should be a simple matter of recompiling the
tools package.
	One of the main strength of OpenSource is that you can
recompile for your platform, and I think we should fully exploit this
advantage, especially for the base system. Otherwise, why not enable
16bit compatibility on i386 for ELKS packages ?

> I don't actually have have a working wireless card (only some non supported
> Samsung one), so I wasn't able to test it, but at least the messages
> are gone.

	Actually, the devil is always in the details.

On Mon, Jan 19, 2004 at 03:54:12PM +0100, Andi Kleen wrote:
> On Mon, 19 Jan 2004 06:39:21 -0800
> "David S. Miller" <davem@redhat.com> wrote:
> 
> > On Mon, 19 Jan 2004 15:39:19 +0100
> > Andi Kleen <ak@suse.de> wrote:
> > 
> > > Went it in after 2.6.1?
> > 
> > Yes, Linus sucked it in like 10 hours ago, about 4 hours right before you made
> > your initial posting on this thread.
> 
> Oh, I actually posted it yesterday but due a broken MTA it didn't go out @)
> But I didn't check BK anyways so it would not have made much difference.
> 
> -Andi

	It seems that the BK->Web stuff has not yet picked your
updates, because I don't see them (and of course the snapshot on
kernel.org is too old).
	Let's just be happy that some code is in ;-)

	Regards,

	Jean

Re: [PATCH] Add 32bit emulation for wireless

[Andi Kleen]

On Mon, 19 Jan 2004 11:49:43 -0800
Jean Tourrilhes <jt@bougret.hpl.hp.com> wrote:
> 	However, this is my prefered way to do things. I would much
> prefer to see you using native version of the Wireless Tools,
> especially that the tools and the kernel need to be in sync as far as
> version is concerned. It should be a simple matter of recompiling the
> tools package.

I don't use wireless at all[1] - I was just annoyed at the storm of
unimplemented ioctl messages when booting up 32bit userland.
SuSE 9.0 boot up calls iwconfig by default.

[1] I actually have a Samsung wireless card, but it's not working
due to missing support for the Cirrus 6729 PCMCIA bridge on there.

> 	One of the main strength of OpenSource is that you can
> recompile for your platform, and I think we should fully exploit this
> advantage, especially for the base system. Otherwise, why not enable
> 16bit compatibility on i386 for ELKS packages ?

I maintain the 32bit emulation on x86-64 and booting an unmodified 32bit distribution
is an important test case for me. Your suggestion is like someone suggesting 
to you to just use ethernet with cables instead of this unreliable wireless stuff...

> 
> 	It seems that the BK->Web stuff has not yet picked your
> updates, because I don't see them (and of course the snapshot on
> kernel.org is too old).

It's actually there, just hidden in a large batch of network updates.

-Andi

Re: [PATCH] Add 32bit emulation for wireless

[Jean Tourrilhes]

On Mon, Jan 19, 2004 at 09:01:32PM +0100, Andi Kleen wrote:
> 
> [1] I actually have a Samsung wireless card, but it's not working
> due to missing support for the Cirrus 6729 PCMCIA bridge on there.

	I was wondering, because Samsungs cards should be supported by
the HostAP driver (which remind me, HostAP needs to go in the kernel).

> > 	One of the main strength of OpenSource is that you can
> > recompile for your platform, and I think we should fully exploit this
> > advantage, especially for the base system. Otherwise, why not enable
> > 16bit compatibility on i386 for ELKS packages ?
> 
> I maintain the 32bit emulation on x86-64 and booting an unmodified 32bit distribution
> is an important test case for me. Your suggestion is like someone suggesting 
> to you to just use ethernet with cables instead of this unreliable wireless stuff...

	This analogy doesn't work. If your network is wireless, you
won't connect to it with an Ethernet card (and vice versa). A fully 64
bits userspace has only very minor downside, and most users won't see
any difference. If we follow your line of thought, we should all be
using a 16bit userspace on i386 (more compact, more compatible).

> > 	It seems that the BK->Web stuff has not yet picked your
> > updates, because I don't see them (and of course the snapshot on
> > kernel.org is too old).
> 
> It's actually there, just hidden in a large batch of network updates.

	It was backlogged, it seems to be catching up (but I need to
see if I find it).
http://linux.bkbits.net:8080/linux-2.5/ChangeSet@-4d?nav=index.html

> -Andi

	Jean

Re: [PATCH] Add 32bit emulation for wireless

[David S. Miller]

On Mon, 19 Jan 2004 12:19:12 -0800
Jean Tourrilhes <jt@bougret.hpl.hp.com> wrote:

> 	This analogy doesn't work. If your network is wireless, you
> won't connect to it with an Ethernet card (and vice versa). A fully 64
> bits userspace has only very minor downside, and most users won't see
> any difference. If we follow your line of thought, we should all be
> using a 16bit userspace on i386 (more compact, more compatible).

I think the situation is different.  On several 64-bit platforms we encourage
using 32-bit compilation and binaries by default because:

1) they're a lot faster than their 64-bit counterparts

2) they're a lot smaller than their 64-bit counterparts

3) 64-bits buys them absolutely nothing

Therefore the 32-bit compatability layer must be as fully supportive as humanly
possible.  Most 64-bit platforms still have %99 32-bit distributions.

This has been discussed to death a million times, please accept the situation and
work towards getting the 32-bit compat stuff working for these wireless ioctls.
We wouldn't be working on this if "just compile as 64-bit" we an acceptable solution
now would we :)

Re: [PATCH] Add 32bit emulation for wireless

[Andi Kleen]

On Mon, 19 Jan 2004 12:19:12 -0800
Jean Tourrilhes <jt@bougret.hpl.hp.com> wrote:

> On Mon, Jan 19, 2004 at 09:01:32PM +0100, Andi Kleen wrote:
> > 
> > [1] I actually have a Samsung wireless card, but it's not working
> > due to missing support for the Cirrus 6729 PCMCIA bridge on there.
> 
> 	I was wondering, because Samsungs cards should be supported by
> the HostAP driver (which remind me, HostAP needs to go in the kernel).

It apparently works with David Hinds' PCMCIA kit, but that is far
too messy to patch into a changing development kernel all the time.
The main problem seems to be the missing bridge support in the kernel
PCMCIA, so the wireless driver cannot even see the chip.

> > > 	One of the main strength of OpenSource is that you can
> > > recompile for your platform, and I think we should fully exploit this
> > > advantage, especially for the base system. Otherwise, why not enable
> > > 16bit compatibility on i386 for ELKS packages ?
> > 
> > I maintain the 32bit emulation on x86-64 and booting an unmodified 32bit distribution
> > is an important test case for me. Your suggestion is like someone suggesting 
> > to you to just use ethernet with cables instead of this unreliable wireless stuff...
> 
> 	This analogy doesn't work. If your network is wireless, you
> won't connect to it with an Ethernet card (and vice versa). A fully 64
> bits userspace has only very minor downside, and most users won't see
> any difference. If we follow your line of thought, we should all be
> using a 16bit userspace on i386 (more compact, more compatible).

My point was not that I think it's so great to run 32bit user space. In fact on AMD64 
the 64bit compiler generates in general better and often more compact code than the 
32bit compiler. Most of my 64bit machines are running with full 64bit userland.
But it's very useful to have working 32bit emulation for many reasons, 
and going from good application emulation to supporting a full distribution boot 
is only  a small step and a great test.

-Andi

Re: [PATCH] Add 32bit emulation for wireless

[Jean Tourrilhes]

On Mon, Jan 19, 2004 at 12:26:57PM -0800, David S. Miller wrote:
> 
> and work towards getting the 32-bit compat stuff working for these
> wireless ioctls.

	I think I've done my part, the wireless ioctls were clearly
not the most difficult to convert ;-)

	Jean

Re: [PATCH] Add 32bit emulation for wireless

[Andi Kleen]

> 1) they're a lot faster than their 64-bit counterparts
> 
> 2) they're a lot smaller than their 64-bit counterparts
> 
> 3) 64-bits buys them absolutely nothing

Just for the record: this doesn't apply to AMD64. While data structures
take a bit more memory at runtime the 64bit code is a lot better 
due to more registers and better ABI.  And it is also not signifcantly
bigger, in fact some programs get smaller when you recompile them for 
64bit.

Still good 32bit emulation is important because people expect 32bit
applications to run seamlessly on 64bit kernels.

> Therefore the 32-bit compatability layer must be as fully supportive as humanly
> possible.  Most 64-bit platforms still have %99 32-bit distributions.

AMD64 should usually run with 64bit userland, except for user who
transistion slowly from a 32bit user land.

-Andi

Re: [PATCH] Add 32bit emulation for wireless

[Jean Tourrilhes]

On Mon, Jan 19, 2004 at 09:35:01PM +0100, Andi Kleen wrote:
> On Mon, 19 Jan 2004 12:19:12 -0800
> Jean Tourrilhes <jt@bougret.hpl.hp.com> wrote:
> 
> > On Mon, Jan 19, 2004 at 09:01:32PM +0100, Andi Kleen wrote:
> > > 
> > > [1] I actually have a Samsung wireless card, but it's not working
> > > due to missing support for the Cirrus 6729 PCMCIA bridge on there.
> > 
> > 	I was wondering, because Samsungs cards should be supported by
> > the HostAP driver (which remind me, HostAP needs to go in the kernel).
> 
> It apparently works with David Hinds' PCMCIA kit, but that is far
> too messy to patch into a changing development kernel all the time.
> The main problem seems to be the missing bridge support in the kernel
> PCMCIA, so the wireless driver cannot even see the chip.

	I see you have it covered :
http://www.ussg.iu.edu/hypermail/linux/kernel/0312.1/0469.html
	You may want to get in touch with Dominik Brodowski and
Russell King, because the i82365 driver in 2.6.X is fairly stable (as
opposed to the CardBus stuff).

> -Andi

	Jean