sys_ioctl export

sys_ioctl export

[Mark Haverkamp]

The ia64 arch doesn't export sys_ioctl like some other 64 bit
architectures like ppc64, sparc64 and x86_64.  Was this intentional?  If
not, where would be a good place to put the export?  The other
architectures put it in their respective ksysm.c file.  The ia64_ksyms.c
file says not to put exports not in an assembler file. Although
max_low_pfn is exported even though it is in linux/bootmem.h.

Thanks,
Mark.

-- 
Mark Haverkamp <markh@osdl.org>

Re: sys_ioctl export

[Grant Grundler]

On Thu, Jun 17, 2004 at 10:52:27AM -0700, Mark Haverkamp wrote:
> The ia64 arch doesn't export sys_ioctl like some other 64 bit
> architectures like ppc64, sparc64 and x86_64.  Was this intentional?

Yes. C files export their own symbols now. This is "new" to 2.6.
"fgrep EXPORT_SYMBOL arch/ia64/kernel/*.c" for examples.

Did you need to call sys_ioctl() directly from a module?

grant

Re: sys_ioctl export

[David Mosberger]

>>>>> On Thu, 17 Jun 2004 10:52:27 -0700, Mark Haverkamp <markh@osdl.org> said:

  Mark> The ia64 arch doesn't export sys_ioctl like some other 64 bit
  Mark> architectures like ppc64, sparc64 and x86_64.  Was this
  Mark> intentional?

It's intentional in the sense that Linux doesn't export symbols
without good reason.  AFAICT, the following arches export sys_ioctl:

 ppc64
 s390
 sparc64
 x86-64

AFAIK, there is no ia64-specific reason to export the symbol.  If
there is a platform-independent reason for doing so, then it should be
exported for all platform, by putting an EXPORT_SYMBOL() after
fs/ioctl.c:sys_ioctl().

	--david

Re: sys_ioctl export

[Mark Haverkamp]

On Thu, 2004-06-17 at 11:20, Grant Grundler wrote:
> On Thu, Jun 17, 2004 at 10:52:27AM -0700, Mark Haverkamp wrote:
> > The ia64 arch doesn't export sys_ioctl like some other 64 bit
> > architectures like ppc64, sparc64 and x86_64.  Was this intentional?
> 
> Yes. C files export their own symbols now. This is "new" to 2.6.
> "fgrep EXPORT_SYMBOL arch/ia64/kernel/*.c" for examples.
> 
> Did you need to call sys_ioctl() directly from a module?

Yes, a 32 bit compatible ioctl function needs to call sys_ioctl once it
has massaged the data, to execute its function. sys_ioctl isn't an arch
specific function.  It isn't exported normally.  It looks like it is
exported by 64 bit architectures only.

> 
> grant
-- 
Mark Haverkamp <markh@osdl.org>

Re: sys_ioctl export

[Andi Kleen]

> AFAIK, there is no ia64-specific reason to export the symbol.  If
> there is a platform-independent reason for doing so, then it should be
> exported for all platform, by putting an EXPORT_SYMBOL() after
> fs/ioctl.c:sys_ioctl().

It's needed to write 32bit compat ioctl handlers in modules.
I would suggest to export it on IA64 too or everywhere.

-Andi

Re: sys_ioctl export

[Grant Grundler]

On Thu, Jun 17, 2004 at 11:31:11AM -0700, Mark Haverkamp wrote:
> > Did you need to call sys_ioctl() directly from a module?
> 
> Yes, a 32 bit compatible ioctl function needs to call sys_ioctl once it
> has massaged the data, to execute its function. sys_ioctl isn't an arch
> specific function.  It isn't exported normally.  It looks like it is
> exported by 64 bit architectures only.

ia64 doesn't support a native 32-bit implementation like
parisc, mips, sparc, et al do. At least not yet. 
Adding that support will need to add those EXPORT_SYMBOLs.

I don't know how the current ia32 support works though.
Obviously not as a module...

grant

Re: sys_ioctl export

[David Mosberger]

>>>>> On Thu, 17 Jun 2004 20:42:28 +0200, Andi Kleen <ak@suse.de> said:

  >> AFAIK, there is no ia64-specific reason to export the symbol.  If
  >> there is a platform-independent reason for doing so, then it
  >> should be exported for all platform, by putting an
  >> EXPORT_SYMBOL() after fs/ioctl.c:sys_ioctl().

  Andi> It's needed to write 32bit compat ioctl handlers in modules.

That makes sense.

  Andi> I would suggest to export it on IA64 too or everywhere.

Why not export it everywhere then?  It seems strange to allow it to be
called from modules on 64-bit platforms but not 32-bit platforms.

	--david

Re: sys_ioctl export

[Andi Kleen]

On Thu, 17 Jun 2004 11:50:36 -0700
David Mosberger <davidm@napali.hpl.hp.com> wrote:

> >>>>> On Thu, 17 Jun 2004 20:42:28 +0200, Andi Kleen <ak@suse.de> said:
> 
>   >> AFAIK, there is no ia64-specific reason to export the symbol.  If
>   >> there is a platform-independent reason for doing so, then it
>   >> should be exported for all platform, by putting an
>   >> EXPORT_SYMBOL() after fs/ioctl.c:sys_ioctl().
> 
>   Andi> It's needed to write 32bit compat ioctl handlers in modules.
> 
> That makes sense.

Only partly to be honest. The module count handling for such modules
is currently quite dubious bordering to broken (it's possible to get it right, but
rather difficult) 
 
>   Andi> I would suggest to export it on IA64 too or everywhere.
> 
> Why not export it everywhere then?  It seems strange to allow it to be
> called from modules on 64-bit platforms but not 32-bit platforms.

Just someone has to submit the patch to do and and remove it from
all the archs.

-Andi

Re: sys_ioctl export

[Grant Grundler]

On Thu, Jun 17, 2004 at 11:50:36AM -0700, David Mosberger wrote:
>   Andi> I would suggest to export it on IA64 too or everywhere.
> 
> Why not export it everywhere then?  It seems strange to allow it to be
> called from modules on 64-bit platforms but not 32-bit platforms.

only 64-bit arches need to translate for 32-bit apps making sys_ioctl calls?

But exporting it for everyone would work too.

grant

Re: sys_ioctl export

[Mark Haverkamp]

On Thu, 2004-06-17 at 12:27, Grant Grundler wrote:
> On Thu, Jun 17, 2004 at 11:50:36AM -0700, David Mosberger wrote:
> >   Andi> I would suggest to export it on IA64 too or everywhere.
> > 
> > Why not export it everywhere then?  It seems strange to allow it to be
> > called from modules on 64-bit platforms but not 32-bit platforms.
> 
> only 64-bit arches need to translate for 32-bit apps making sys_ioctl calls?

I believe that this is true.

> 
> But exporting it for everyone would work too.

Wouldn't there be some reluctance to export a symbol to everyone when it
is only used for a special purpose?

> 
> grant

Mark.
-- 
Mark Haverkamp <markh@osdl.org>

Re: sys_ioctl export

[David Mosberger]

>>>>> On Thu, 17 Jun 2004 12:36:54 -0700, Mark Haverkamp <markh@osdl.org> said:

  Mark> Wouldn't there be some reluctance to export a symbol to
  Mark> everyone when it is only used for a special purpose?

It seems rather silly to try to limit the exporting of a symbol that's
exported for all 64-bit platforms.  But I don't really care.  If you
want to submit a tested patch to add the symbol to ia64_ksyms.c, I can
certainly live with that.

	--david

Re: sys_ioctl export

[Christoph Hellwig]

On Thu, Jun 17, 2004 at 02:25:16PM -0700, David Mosberger wrote:
> >>>>> On Thu, 17 Jun 2004 12:36:54 -0700, Mark Haverkamp <markh@osdl.org> said:
> 
>   Mark> Wouldn't there be some reluctance to export a symbol to
>   Mark> everyone when it is only used for a special purpose?
> 
> It seems rather silly to try to limit the exporting of a symbol that's
> exported for all 64-bit platforms.  But I don't really care.  If you
> want to submit a tested patch to add the symbol to ia64_ksyms.c, I can
> certainly live with that.

Just put the export into common code and guard it by CONFIG_COMPAT, matches
exactly the intended users.

Re: sys_ioctl export

[Jesse Barnes]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Friday, June 18, 2004 2:54 am, Christoph Hellwig wrote:
> On Thu, Jun 17, 2004 at 02:25:16PM -0700, David Mosberger wrote:
> > >>>>> On Thu, 17 Jun 2004 12:36:54 -0700, Mark Haverkamp <markh@osdl.org>
> > >>>>> said:
> >
> >   Mark> Wouldn't there be some reluctance to export a symbol to
> >   Mark> everyone when it is only used for a special purpose?
> >
> > It seems rather silly to try to limit the exporting of a symbol that's
> > exported for all 64-bit platforms.  But I don't really care.  If you
> > want to submit a tested patch to add the symbol to ia64_ksyms.c, I can
> > certainly live with that.
>
> Just put the export into common code and guard it by CONFIG_COMPAT, matches
> exactly the intended users.

Like this totally untested and uncompiled patch?

Jesse


[-- Attachment #2: sys-ioctl-export.patch --]
[-- Type: text/x-diff, Size: 1944 bytes --]

===== arch/ppc64/kernel/ppc_ksyms.c 1.40 vs edited =====
--- 1.40/arch/ppc64/kernel/ppc_ksyms.c	2004-04-12 13:54:03 -04:00
+++ edited/arch/ppc64/kernel/ppc_ksyms.c	2004-06-18 10:28:45 -04:00
@@ -50,7 +50,6 @@
 int abs(int);
 
 EXPORT_SYMBOL(do_signal);
-EXPORT_SYMBOL(sys_ioctl);
 
 EXPORT_SYMBOL(isa_io_base);
 EXPORT_SYMBOL(pci_io_base);
===== arch/s390/kernel/s390_ksyms.c 1.23 vs edited =====
--- 1.23/arch/s390/kernel/s390_ksyms.c	2004-06-12 23:52:29 -04:00
+++ edited/arch/s390/kernel/s390_ksyms.c	2004-06-18 10:28:58 -04:00
@@ -76,4 +76,3 @@
 EXPORT_SYMBOL_NOVERS(do_call_softirq);
 EXPORT_SYMBOL(sys_wait4);
 EXPORT_SYMBOL(cpcmd);
-EXPORT_SYMBOL(sys_ioctl);
===== arch/sparc64/kernel/sparc64_ksyms.c 1.69 vs edited =====
--- 1.69/arch/sparc64/kernel/sparc64_ksyms.c	2004-06-09 01:29:44 -04:00
+++ edited/arch/sparc64/kernel/sparc64_ksyms.c	2004-06-18 10:29:12 -04:00
@@ -327,7 +327,6 @@
 EXPORT_SYMBOL(sys_getgid);
 EXPORT_SYMBOL(svr4_getcontext);
 EXPORT_SYMBOL(svr4_setcontext);
-EXPORT_SYMBOL(sys_ioctl);
 EXPORT_SYMBOL(compat_sys_ioctl);
 EXPORT_SYMBOL(sparc32_open);
 EXPORT_SYMBOL(sys_close);
===== arch/x86_64/kernel/x8664_ksyms.c 1.32 vs edited =====
--- 1.32/arch/x86_64/kernel/x8664_ksyms.c	2004-05-17 17:12:13 -04:00
+++ edited/arch/x86_64/kernel/x8664_ksyms.c	2004-06-18 10:29:26 -04:00
@@ -218,4 +218,3 @@
 EXPORT_SYMBOL_GPL(flush_tlb_all);
 #endif
 
-EXPORT_SYMBOL(sys_ioctl);
===== fs/ioctl.c 1.12 vs edited =====
--- 1.12/fs/ioctl.c	2004-05-29 14:22:13 -04:00
+++ edited/fs/ioctl.c	2004-06-18 10:30:30 -04:00
@@ -4,11 +4,13 @@
  *  Copyright (C) 1991, 1992  Linus Torvalds
  */
 
+#include <linux/config.h>
 #include <linux/mm.h>
 #include <linux/smp_lock.h>
 #include <linux/file.h>
 #include <linux/fs.h>
 #include <linux/security.h>
+#include <linux/module.h>
 
 #include <asm/uaccess.h>
 #include <asm/ioctls.h>
@@ -133,3 +135,7 @@
 out:
 	return error;
 }
+
+#ifdef CONFIG_COMPAT
+EXPORT_SYMBOL(sys_ioctl);
+#endif

Re: sys_ioctl export

[Christoph Hellwig]

> > Just put the export into common code and guard it by CONFIG_COMPAT, matches
> > exactly the intended users.
> 
> Like this totally untested and uncompiled patch?

Looks good.  Maybe a small comment?

Re: sys_ioctl export

[Jesse Barnes]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Friday, June 18, 2004 10:37 am, Christoph Hellwig wrote:
> > > Just put the export into common code and guard it by CONFIG_COMPAT,
> > > matches exactly the intended users.
> >
> > Like this totally untested and uncompiled patch?
>
> Looks good.  Maybe a small comment?

Small patch to export sys_ioctl if CONFIG_COMPAT is set.  This allows 
platforms to implement 32 bit compatibility ioctl handlers in modules.

Submitted-by: Jesse Barnes <jbarnes@sgi.com>


[-- Attachment #2: sys-ioctl-export-2.patch --]
[-- Type: text/x-diff, Size: 2051 bytes --]

===== arch/ppc64/kernel/ppc_ksyms.c 1.40 vs edited =====
--- 1.40/arch/ppc64/kernel/ppc_ksyms.c	2004-04-12 13:54:03 -04:00
+++ edited/arch/ppc64/kernel/ppc_ksyms.c	2004-06-18 10:28:45 -04:00
@@ -50,7 +50,6 @@
 int abs(int);
 
 EXPORT_SYMBOL(do_signal);
-EXPORT_SYMBOL(sys_ioctl);
 
 EXPORT_SYMBOL(isa_io_base);
 EXPORT_SYMBOL(pci_io_base);
===== arch/s390/kernel/s390_ksyms.c 1.23 vs edited =====
--- 1.23/arch/s390/kernel/s390_ksyms.c	2004-06-12 23:52:29 -04:00
+++ edited/arch/s390/kernel/s390_ksyms.c	2004-06-18 10:28:58 -04:00
@@ -76,4 +76,3 @@
 EXPORT_SYMBOL_NOVERS(do_call_softirq);
 EXPORT_SYMBOL(sys_wait4);
 EXPORT_SYMBOL(cpcmd);
-EXPORT_SYMBOL(sys_ioctl);
===== arch/sparc64/kernel/sparc64_ksyms.c 1.69 vs edited =====
--- 1.69/arch/sparc64/kernel/sparc64_ksyms.c	2004-06-09 01:29:44 -04:00
+++ edited/arch/sparc64/kernel/sparc64_ksyms.c	2004-06-18 10:29:12 -04:00
@@ -327,7 +327,6 @@
 EXPORT_SYMBOL(sys_getgid);
 EXPORT_SYMBOL(svr4_getcontext);
 EXPORT_SYMBOL(svr4_setcontext);
-EXPORT_SYMBOL(sys_ioctl);
 EXPORT_SYMBOL(compat_sys_ioctl);
 EXPORT_SYMBOL(sparc32_open);
 EXPORT_SYMBOL(sys_close);
===== arch/x86_64/kernel/x8664_ksyms.c 1.32 vs edited =====
--- 1.32/arch/x86_64/kernel/x8664_ksyms.c	2004-05-17 17:12:13 -04:00
+++ edited/arch/x86_64/kernel/x8664_ksyms.c	2004-06-18 10:29:26 -04:00
@@ -218,4 +218,3 @@
 EXPORT_SYMBOL_GPL(flush_tlb_all);
 #endif
 
-EXPORT_SYMBOL(sys_ioctl);
===== fs/ioctl.c 1.12 vs edited =====
--- 1.12/fs/ioctl.c	2004-05-29 14:22:13 -04:00
+++ edited/fs/ioctl.c	2004-06-18 10:42:23 -04:00
@@ -4,11 +4,13 @@
  *  Copyright (C) 1991, 1992  Linus Torvalds
  */
 
+#include <linux/config.h>
 #include <linux/mm.h>
 #include <linux/smp_lock.h>
 #include <linux/file.h>
 #include <linux/fs.h>
 #include <linux/security.h>
+#include <linux/module.h>
 
 #include <asm/uaccess.h>
 #include <asm/ioctls.h>
@@ -133,3 +135,11 @@
 out:
 	return error;
 }
+
+/*
+ * Platforms implementing 32 bit compatibility ioctl handlers in
+ * modules need this exported
+ */
+#ifdef CONFIG_COMPAT
+EXPORT_SYMBOL(sys_ioctl);
+#endif