Extending syscalls (was: [PATCH 1/2] Extend sys_clone and
sys_unshare system calls API)
corbet at lwn.net
Thu Jan 17 07:02:05 PST 2008
Al Viro sez:
> Nah, just put an XML parser into the kernel to have the form match the
> 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,
- Set a flag saying "I've stashed some additional parameters somewhere
else." That's sys_indirect() and the current proposal for extending
- 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.
More information about the Containers