All:
I finally have LiS running on a 2.5 kernel. Attached is the 2.5.46 version
of the syscall registration patch that was submitted for inclusion in the
2.4 kernel about a month ago. It has been tested on an Intel platform.
The patch follows inline for easy perusal and is attached as a file for
tab-preservation.
Comments welcome. If it looks good will someone tell me to whom to direct
it for inclusion in the kernel source?
Thanks,
-- Dave
--- arch/i386/kernel/entry.S.orig 2002-11-06 16:09:44.000000000 -0600
+++ arch/i386/kernel/entry.S 2002-11-06 16:28:23.000000000 -0600
@@ -671,8 +671,8 @@
.long sys_capset /* 185 */
.long sys_sigaltstack
.long sys_sendfile
- .long sys_ni_syscall /* reserved for streams1 */
- .long sys_ni_syscall /* reserved for streams2 */
+ .long sys_getpmsg /* streams1 */
+ .long sys_putpmsg /* streams2 */
.long sys_vfork /* 190 */
.long sys_getrlimit
.long sys_mmap2
--- kernel/sys.c.orig 2002-11-06 16:09:57.000000000 -0600
+++ kernel/sys.c 2002-11-06 16:30:46.000000000 -0600
@@ -195,6 +195,49 @@
return notifier_chain_unregister(&reboot_notifier_list, nb);
}
+static int (*do_putpmsg) (int, void *, void *, int, int) = NULL;
+static int (*do_getpmsg) (int, void *, void *, int, int) = NULL;
+
+static DECLARE_RWSEM(streams_call_sem);
+
+long asmlinkage
+sys_putpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
+{
+ int ret = -ENOSYS;
+ down_read(&streams_call_sem); /* should return int, but doesn't */
+ if (do_putpmsg)
+ ret = (*do_putpmsg) (fd, ctlptr, datptr, band, flags);
+ up_read(&streams_call_sem);
+ return ret;
+}
+
+long asmlinkage
+sys_getpmsg(int fd, void *ctlptr, void *datptr, int band, int flags)
+{
+ int ret = -ENOSYS;
+ down_read(&streams_call_sem); /* should return int, but doesn't */
+ if (do_getpmsg)
+ ret = (*do_getpmsg) (fd, ctlptr, datptr, band, flags);
+ up_read(&streams_call_sem);
+ return ret;
+}
+
+int
+register_streams_calls(int (*putpmsg) (int, void *, void *, int, int),
+ int (*getpmsg) (int, void *, void *, int, int))
+{
+ int ret = -EBUSY;
+ down_write(&streams_call_sem); /* should return int, but doesn't */
+ if ( (putpmsg == NULL || do_putpmsg == NULL)
+ && (getpmsg == NULL || do_getpmsg == NULL)) {
+ do_putpmsg = putpmsg;
+ do_getpmsg = getpmsg;
+ ret = 0;
+ }
+ up_write(&streams_call_sem);
+ return ret;
+}
+
asmlinkage long sys_ni_syscall(void)
{
return -ENOSYS;
@@ -1386,3 +1429,4 @@
EXPORT_SYMBOL(unregister_reboot_notifier);
EXPORT_SYMBOL(in_group_p);
EXPORT_SYMBOL(in_egroup_p);
+EXPORT_SYMBOL_GPL(register_streams_calls);
--- include/linux/sys.h.orig 2002-11-06 16:10:10.000000000 -0600
+++ include/linux/sys.h 2002-11-06 16:29:16.000000000 -0600
@@ -27,4 +27,16 @@
* These are system calls that haven't been implemented yet
* but have an entry in the table for future expansion..
*/
+
+/*
+ * These are registration routines for system calls that are
+ * implemented by loadable modules outside of the kernel
+ * source tree.
+ */
+#if !defined(__ASSEMBLY__)
+extern int
+register_streams_calls(int (*putpmsg) (int, void *, void *, int, int),
+ int (*getpmsg) (int, void *, void *, int, int)) ;
+
+#endif /* __ASSEMBLY__ */
#endif
On Thursday 07 November 2002 21:00, David Grothe wrote:
> All:
>
> I finally have LiS running on a 2.5 kernel. Attached is the 2.5.46 version
> of the syscall registration patch that was submitted for inclusion in the
> 2.4 kernel about a month ago. It has been tested on an Intel platform.
>
> The patch follows inline for easy perusal and is attached as a file for
> tab-preservation.
>
> Comments welcome. If it looks good will someone tell me to whom to direct
> it for inclusion in the kernel source?
Just a random comment, but the feature freeze was October 31st. Is this a
repost of something we saw before then?
Rob
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
At 06:37 AM 11/8/2002 Friday, Rob Landley wrote:
>On Thursday 07 November 2002 21:00, David Grothe wrote:
>
>Just a random comment, but the feature freeze was October 31st. Is this a
>repost of something we saw before then?
Yes. This came up in late September and I posted a patch in early October
for 2.4. It took until just a few days ago to get LiS ported to 2.5 so
that I could test the patch for 2.5.
-- Dave
Rob Landley wrote:
> On Thursday 07 November 2002 21:00, David Grothe wrote:
>> All:
>>
>> I finally have LiS running on a 2.5 kernel. Attached is the 2.5.46
>> version of the syscall registration patch that was submitted for
>> inclusion in the
>> 2.4 kernel about a month ago. It has been tested on an Intel platform.
^^^^^^^^^
>>
>> The patch follows inline for easy perusal and is attached as a file for
>> tab-preservation.
>>
>> Comments welcome. If it looks good will someone tell me to whom to
>> direct it for inclusion in the kernel source?
>
> Just a random comment, but the feature freeze was October 31st. Is this a
> repost of something we saw before then?
Seems to me that it is. Besides, as patches go, this is *hardly* obtrusive
and requires minimal changes to the kernel API. It's not like he's asking
to integrate the whole streams driver into the kernel. I don't think the
addition of this code will cause any new bugs to appear [the actual streams
driver aside], do you?
Cheers,
Nicholas
On Fri, 2002-11-08 at 06:37, Rob Landley wrote:
> > Comments welcome. If it looks good will someone tell me to whom to direct
> > it for inclusion in the kernel source?
>
> Just a random comment, but the feature freeze was October 31st. Is this a
> repost of something we saw before then?
Its just a fix for something that was broken before by cleanups and is
now being done right. It also has no impact on drivers and other stuff.
Dim prob
On Friday 08 November 2002 15:07, Nicholas Wourms wrote:
> > Just a random comment, but the feature freeze was October 31st. Is this
> > a repost of something we saw before then?
>
> Seems to me that it is.
That's why I asked. :)
> Besides, as patches go, this is *hardly* obtrusive
> and requires minimal changes to the kernel API. It's not like he's asking
> to integrate the whole streams driver into the kernel. I don't think the
> addition of this code will cause any new bugs to appear [the actual streams
> driver aside], do you?
The curse of 3 am posting, I thought the patch was about something else
(generic syscall registration for third party modules as mentioned months ago
on the list) in the 5 seconds I glanced at it. Having now actually read the
thing with both eyes focused, it's just sticking bodies on two already
reserved syscalls, which is pretty low impact, yeah. :)
(Although this mechanism could be USED for generic syscall registration by
third parties that don't intend to use streams, only want two syscalls, and
don't care deeply about their arguments. But it's exported GPL so that would
only ever be likely to be used for debugging purposes...)
To answer the original question for Dave: Alan Cox has now seen it, so life is
probably good for you.
> Cheers,
> Nicholas
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
At 05:59 PM 11/8/2002 Friday, Rob Landley wrote:
>On Friday 08 November 2002 15:07, Nicholas Wourms wrote:
>
>To answer the original question for Dave: Alan Cox has now seen it, so
>life is
>probably good for you.
Do I need to do anything more to get it into the kernel source?
-- Dave