Re: two x86_64 fixes for 2.4.21-pre3

[Andi Kleen <ak@suse.de>]

On Mon, Feb 03, 2003 at 11:49:23AM -0800, Jean Tourrilhes wrote:
> On Mon, Feb 03, 2003 at 08:17:39PM +0100, Mikael Pettersson wrote:
> > Andi Kleen writes:
> >  > > 1. One unknown ioctl is logged from RH8.0 init:
> >  > > 
> >  > > ioctl32(iwconfig:185): Unknown cmd fd(3) cmd(00008b01){00} arg(ffffda90) on socket:[389]
> >  > 
> >  > Probably harmless, but if you figure it out please send me a patch.
> > 
> > The ioctl is SIOCGIWNAME, which is used by iwconfig from the wireless-tools
> > package to check if a given net dev is a wireless thing or not (called from
> > ifup in RedHat as a type test on the net dev).
> > 
> > Unfortunately, include/linux/wireless.h has a big pile of ioctls and arg/res
> > types that would need to be checked, so I'll defer this to Jean Tourrilhes (cc:d).
> > 
> > /Mikael
> 
> 	Why don't you just recompile the Wireless Tools (iwconfig and
> friends) for 64 bits ?

We normally try to at least support all ioctls which are used in 
standard distributions as 32bit. This way users can easily switch
between 32bit and 64bit userland. The coverage is very good
(standing on the shoulders of sparc64 emulation gigants).

Of course 64bit tools exist, just the 64bit distributions are not commonly
available yet and it's still nice to switch at will.

Also some ports rely on emulation for all user land (sparc64, ppc64, mips64);
for these it would be eventually needed anyways.

> 	The source of Wireless Tools should be 64 bit clean (was
> working on Alpha), and I don't think it's worth adding a whole pile of
> cruft in the kernel when it's used by a few system utilities that you
> can simply recompile. Personally, I expect every distribution to ship
> the base system compiled natively.
> 	With regards to this specific problem, just return an
> error. The Wireless Tools should gracefully handle it and report to

That is currently done (-EINVAL), but the emulation layer logs an 
warning.

> 	Just food for thought... I you think the wireless ioctls are
> bad, there is worse. The linux-wlan-ng driver defines it's own driver
> specific ioctls, and it has 3 times the number of ioctls. Just for one
> driver. And the ioctl format sometimes changes with revision.

That's bad. Do they at least have unique numbers?

> 	So, clearly you can't expect to deal with every ioctl under
> the sun, that's just not practical.

So far it works.

-Andi