lkml.org 
[lkml]   [2008]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectExtending syscalls (was: [PATCH 1/2] Extend sys_clone and sys_unshare system calls API)
From
Date
Al Viro sez:

> Nah, just put an XML parser into the kernel to have the form match the
> contents...
>
> Al "perhaps we should newgroup alt.tasteless.api for all that stuff" Viro

Heh, indeed. But we do seem to have a recurring problem of people
wanting to extend sys_foo() beyond the confines of its original API.
I've observed a few ways of doing that:

- create sys_foo2() (or sys_foo64(), or sys_fooat(), or sys_pfoo(),
or...) and add the new stuff there.

- Put a version number into the API somewhere - wireless extensions,
for example.

- Set a flag saying "I've stashed some additional parameters somewhere
else." That's sys_indirect() and the current proposal for extending
clone().

- Just do it all with a kernel-based XML parser. I think we should
call this approach sys_viro() in honor of its champion.

- Do it all in sysfs

The first approach has traditionally been the most popular. If we have
a consensus that this is the way to extend system calls in the future,
it would be nice to set that down somewhere. We could avoid a lot of
API blind alleys that way.

jon


\
 
 \ /
  Last update: 2008-01-17 16:05    [W:0.079 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site