Re: sys_ioctl export consolidation

["Jan Beulich" <JBeulich@novell.com>]

That's certainly another possibility, putting under question why for
certain architectures sys_ioctl gets exported (by inspection I can see a
valid reason only for sparc64).

Anyway, I don't have a list of drivers ready, I just ran into the issue
because a driver I had to port over from 2.4 worked on all intended
architectures but ia64, and I initially intended to go the route you
point out until I found that most 64-bit architectures with 32-bit
emulation layers actually export the symbol for appearantly this very
purpose.

>>> Christoph Hellwig <hch@infradead.org> 06.05.04 16:50:08 >>>
On Thu, May 06, 2004 at 01:23:24PM +0200, Jan Beulich wrote:
> Since we noted that sys_ioctl is not currently being exported for
ia64
> to be used in the 32-bit emulation routines I'd like to suggest the
> following patch, which, instead of making this available in another
> individual architecture, exports the symbol whenever CONFIG_COMPAT
is
> defined (legal users should be a subset of
> [un]register_ioctl32_conversion users, which is scoped by the same
> config option).

Should ioctl32 handlers in drivers really call sys_ioctl?  Calling
sys_ioctl
makes sense for ioctls that are supported by a broad range of drivers,
but
in that case the ioctl32 translation should be in the core compat
code.

Drivers using register_ioctl32_conversion should rather call their own
ioctl handlers directly if you ask me.

Do you have a list of drivers currently needing sys_ioctl?