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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/