export of sys_call_tabl

Yes, it's ok with me. You can still do
register(NULL, notNULL);
register(notNULL, NULL);
without trigerring any error, but maybe that it can be called feature.
Best regards,
Petr Vandrovec [email protected]

Attached is the "final" patch. I eliminated the unregister function. This is tested on stock 2.4.19 kernel.

Will someone see that it is added to the kernel source?

Thanks,
Dave

@@ -584,8 +584,8 @@
 	.long SYMBOL_NAME(sys_capset)           /* 185 */
 	.long SYMBOL_NAME(sys_sigaltstack)
 	.long SYMBOL_NAME(sys_sendfile)
-	.long SYMBOL_NAME(sys_ni_syscall)		/* streams1 */
-	.long SYMBOL_NAME(sys_ni_syscall)		/* streams2 */
+	.long SYMBOL_NAME(sys_getpmsg)		/* streams1 */
+	.long SYMBOL_NAME(sys_putpmsg)		/* streams2 */
 	.long SYMBOL_NAME(sys_vfork)            /* 190 */
 	.long SYMBOL_NAME(sys_getrlimit)
 	.long SYMBOL_NAME(sys_mmap2)

@@ -497,6 +497,9 @@
 EXPORT_SYMBOL(seq_release);
 EXPORT_SYMBOL(seq_read);
 EXPORT_SYMBOL(seq_lseek);
+extern int register_streams_calls(int (*putpmsg) (int,void *,void *,int,int),
+				   int (*getpmsg) (int,void *,void *,int,int));
+EXPORT_SYMBOL(register_streams_calls);
 
 /* Program loader interfaces */
 EXPORT_SYMBOL(setup_arg_pages);

a) please read Documentation/CodingStyle
b) please add a prototype in a header
c) please make it EXPORT_SYMBOL_GPL

Is there a specific problem here? We tried to imitate the kernel coding style with this patch.

Can you suggest which header file would be appropriate? I would be glad to add the prototype there.

LiS is LGPL. Would it work if the exported symbol was GPL only?

As this is something of a replacement for the old exported sys_call_table, which was exported generally, we thought that a general export was appropriate.

Thanks,
Dave

since LiS becomes GPL when you link it into the kernel with insmod, that's not a problem ;)

Guys, I think we are closing in on it.

I ran the patch through Lindent. I moved the exported symbol to sys.c and made it GPL only. I tested it on 2.4.19.

If we could agree on a header file location for the prototype, or not to have a prototype, I could cook up another candidate for "final" in short order.

Thanks for all the suggestions,
Dave

AFAIK, iBCS use these syscalls to emulate TLI, and iBCS only has this emulation working for the IP protocol suite.

LiS is hooking the same syscalls, and is more protocol independent.

In this way, iBCS and LiS are competing projects, even if their base objectives are very different (iBCS aims for user-level binary portability from SysV, while LiS aims for kernel-level STREAMS code portability from SysV to extend to Linux).

An LGPL module with proprietary code linked into it will taint the kernel. LiS is often linked with proprietary code, since it is under LGPL.

IMHO, A not-GPL-only export from the kernel is needed here.

That will not make these syscalls proprietary. Even with proprietary drivers linked into LiS, it is impossible to deviate from the SysV definition of putpmsg/getpmsg unless the code of LiS itself is modified.

Best Regards,

Ole Husgaard.

iBCS doesn't exist for 2.4 or 2.5 kernels
it's called linux-abi now and does NOT use these syscalls

Ole,

I don't think that exporting putpmsg and getpmsg as _GPL will stop proprietary modules from being linked with LiS. LiS exports its symbols on a different basis. There is no need for a proprietary module using LiS to access putpmsg or getpmsg or the syscall registration facility for that matter. Is you concern that LiS using a _GPL only facility will force GPL on modules linked with LiS even though LiS is LGPL?

--brian

Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

The _GPL is just to help people and guide them. It doesn't alter what is and is not an offence under copyright law.

No, my concern is that the kernel should be marked as tainted when appropriate, thus giving volunteer kernel hackers a change to decide if they want to help with an oops from a tainted kernel.

For well-defined fundamental interfaces between genuinely seperate works, I think using EXPORT_SYMBOL is more appropriate than EXPORT_SYMBOL_GPL.
Syscalls like putpmsg and getpmsg fall into this category, even if wrapped in a thin layer to facilitate MP-safe registration and deregistration.

The simple act of a LGPL module hooking two syscalls not implemented by the standard kernel is IMHO no good reason for marking the kernel as such tainted.

Best Regards,

Ole Husgaard.