From: "H. Peter Anvin" <hpa@zytor.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
Pavel Emelyanov <xemul@openvz.org>,
Linux Containers <containers@lists.osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Cedric Le Goater <clg@fr.ibm.com>,
drepper@redhat.com, Serge Hallyn <serue@us.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Extending syscalls
Date: Thu, 17 Jan 2008 14:26:23 -0500 [thread overview]
Message-ID: <478FABDF.1020002@zytor.com> (raw)
In-Reply-To: <25712.1200582125@vena.lwn.net>
Jonathan Corbet wrote:
>
> 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.
>
> 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.
>
I would argue it is the right approach. It lets the kernel system call
entry dispatch directly to the system call for the "new" case, and to a
compatibility thunk for the "old" case. It has the following desirable
properties:
- No overhead for the "new" case.
- Minimal overhead for the "old" case.
- Easily dealt with by tools like strace that examine system calls.
-hpa
prev parent reply other threads:[~2008-01-17 19:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-16 12:58 [PATCH 1/2] Extend sys_clone and sys_unshare system calls API Pavel Emelyanov
2008-01-16 12:58 ` Pavel Emelyanov
[not found] ` <478DFF8F.9030006-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-01-16 13:00 ` [PATCH 2/2] Propagate the long_clone_arg up to the create_new_namespaces Pavel Emelyanov
2008-01-16 13:00 ` Pavel Emelyanov
2008-01-23 20:59 ` [PATCH 1/2] Extend sys_clone and sys_unshare system calls API Pavel Machek
2008-01-23 20:59 ` Pavel Machek
[not found] ` <20080123205930.GA5233-+ZI9xUNit7I@public.gmane.org>
2008-01-24 17:09 ` Cedric Le Goater
2008-01-24 17:09 ` Cedric Le Goater
2008-01-24 17:24 ` Dave Hansen
2008-01-24 17:37 ` Pavel Machek
2008-01-24 17:46 ` Dave Hansen
2008-01-24 17:50 ` Pavel Machek
2008-01-16 14:23 ` Jonathan Corbet
[not found] ` <9803.1200493420-k5ufJzZ057zk1uMJSBkQmQ@public.gmane.org>
2008-01-16 15:05 ` Pavel Emelyanov
2008-01-16 15:05 ` Pavel Emelyanov
2008-01-17 3:48 ` Al Viro
2008-01-17 9:28 ` Cedric Le Goater
2008-01-17 15:02 ` Extending syscalls (was: [PATCH 1/2] Extend sys_clone and sys_unshare system calls API) Jonathan Corbet
2008-01-17 19:26 ` H. Peter Anvin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=478FABDF.1020002@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=clg@fr.ibm.com \
--cc=containers@lists.osdl.org \
--cc=corbet@lwn.net \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serue@us.ibm.com \
--cc=viro@ZenIV.linux.org.uk \
--cc=xemul@openvz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.