sys_ioctl export consolidation

sys_ioctl export consolidation

[Jan Beulich]

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).

Regards, Jan

compat-sys_ioctl-export.patch:
diff -aur linux-2.6.5/arch/ppc64/kernel/ppc_ksyms.c
linux-2.6.5-ioctl/arch/ppc64/kernel/ppc_ksyms.c
--- linux-2.6.5/arch/ppc64/kernel/ppc_ksyms.c	2004-04-04
05:36:26.000000000 +0200
+++ linux-2.6.5-ioctl/arch/ppc64/kernel/ppc_ksyms.c	2004-05-06
13:07:28.000000000 +0200
@@ -49,7 +49,6 @@
 int abs(int);
 
 EXPORT_SYMBOL(do_signal);
-EXPORT_SYMBOL(sys_ioctl);
 
 EXPORT_SYMBOL(isa_io_base);
 EXPORT_SYMBOL(pci_io_base);
diff -aur linux-2.6.5/arch/s390/kernel/s390_ksyms.c
linux-2.6.5-ioctl/arch/s390/kernel/s390_ksyms.c
--- linux-2.6.5/arch/s390/kernel/s390_ksyms.c	2004-04-04
05:37:25.000000000 +0200
+++ linux-2.6.5-ioctl/arch/s390/kernel/s390_ksyms.c	2004-05-06
13:07:07.000000000 +0200
@@ -95,4 +95,3 @@
 EXPORT_SYMBOL_NOVERS(do_call_softirq);
 EXPORT_SYMBOL(sys_wait4);
 EXPORT_SYMBOL(cpcmd);
-EXPORT_SYMBOL(sys_ioctl);
diff -aur linux-2.6.5/arch/x86_64/kernel/x8664_ksyms.c
linux-2.6.5-ioctl/arch/x86_64/kernel/x8664_ksyms.c
--- linux-2.6.5/arch/x86_64/kernel/x8664_ksyms.c	2004-04-04
05:36:25.000000000 +0200
+++ linux-2.6.5-ioctl/arch/x86_64/kernel/x8664_ksyms.c	2004-05-06
13:06:39.000000000 +0200
@@ -220,7 +220,5 @@
 EXPORT_SYMBOL_GPL(flush_tlb_all);
 #endif
 
-EXPORT_SYMBOL(sys_ioctl);
-
 EXPORT_SYMBOL(memcpy_toio);
 EXPORT_SYMBOL(memcpy_fromio);
diff -aur linux-2.6.5/fs/ioctl.c linux-2.6.5-ioctl/fs/ioctl.c
--- linux-2.6.5/fs/ioctl.c	2004-04-04 05:36:26.000000000 +0200
+++ linux-2.6.5-ioctl/fs/ioctl.c	2004-05-06 13:05:56.000000000
+0200
@@ -4,6 +4,7 @@
  *  Copyright (C) 1991, 1992  Linus Torvalds
  */
 
+#include <linux/config.h>
 #include <linux/mm.h>
 #include <linux/smp_lock.h>
 #include <linux/file.h>
@@ -132,3 +133,6 @@
 out:
 	return error;
 }
+#ifdef CONFIG_COMPAT
+EXPORT_SYMBOL(sys_ioctl)
+#endif

Re: sys_ioctl export consolidation

[Christoph Hellwig]

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?

Re: sys_ioctl export consolidation

[Jan Beulich]

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?

Re: sys_ioctl export consolidation

[Andi Kleen]

Christoph Hellwig <hch@infradead.org> writes:

> 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.

I think it is better to call sys_ioctl always from the wrappers and
only convert the arguments. This way you are guaranteed to not get
subtle differences in behaviour. This gives a clear layering. Otherwise 
driver writers have to do this ad-hoc and only chaos can evolve from
that.

In addition this is how all the current ioctl handlers work, no need
to be different.

-Andi