From: ebiederm@xmission.com (Eric W. Biederman)
To: Andi Kleen <andi@firstfloor.org>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Pavel Emelyanov <xemul@openvz.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Pavel Emelyanov <xemul@parallels.com>,
Andrey Vagin <avagin@openvz.org>,
KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Glauber Costa <glommer@parallels.com>, Tejun Heo <tj@kernel.org>,
Matt Helsley <matthltc@us.ibm.com>,
Pekka Enberg <penberg@kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
Vasiliy Kulikov <segoon@openwall.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Valdis.Kletnieks@vt.edu
Subject: Re: [RFC c/r 2/4] [RFC] syscalls, x86: Add __NR_kcmp syscall v7
Date: Fri, 27 Jan 2012 12:55:50 -0800 [thread overview]
Message-ID: <m1mx98zwyx.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20120127194058.GF11715@one.firstfloor.org> (Andi Kleen's message of "Fri, 27 Jan 2012 20:40:58 +0100")
Andi Kleen <andi@firstfloor.org> writes:
>> > The basic problem is if this interface is at the right level of abstraction.
>> > I have some doubts on that. It seems like a long term maintenance nightmare to
>> > me. It may be better to put the loop that would call this into the kernel.
>> >
>>
>> Hmm, ie selftest right in kenel?
>
> Not testing, but more the general stability of the interface. IMHO it exposes
> too many kernel internals. I know they are already exposed by clone/unshare,
> but in those nothing breaks if the user program doesn't know about some new
> flags. But this looks like the user always has to be updated for every change.
> I think I would prefer if more of the user was in kernel to not expose
> that much.
Do you vote for putting the entire process serializer in one system call
then?
With the serializer in userspace you only need to update your userspace
code if something uses a new facility. Which is the standard userspace
requirement. Userspace does not need to be strictly in sync with the
kernel.
Personally I think all of this exporting extra state a little at a time
is horrible, but it seems to have a better chance of getting merged
because the pain comes a little at time.
Eric
next prev parent reply other threads:[~2012-01-27 20:53 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-27 17:53 [RFC c/r 0/4] [RFC c/r 0/@total@] A pile in c/r sake Cyrill Gorcunov
2012-01-27 17:53 ` [RFC c/r 1/4] fs, proc: Introduce /proc/<pid>/task/<tid>/children entry v9 Cyrill Gorcunov
2012-01-27 17:53 ` [RFC c/r 2/4] [RFC] syscalls, x86: Add __NR_kcmp syscall v7 Cyrill Gorcunov
2012-01-27 18:05 ` H. Peter Anvin
2012-01-27 18:11 ` Cyrill Gorcunov
2012-01-27 18:15 ` Andi Kleen
2012-01-27 18:24 ` Cyrill Gorcunov
2012-01-27 18:30 ` H. Peter Anvin
2012-01-28 17:19 ` Michael Kerrisk
2012-01-28 17:34 ` Cyrill Gorcunov
2012-01-28 17:36 ` Cyrill Gorcunov
2012-01-27 18:31 ` Andi Kleen
2012-01-27 18:40 ` Cyrill Gorcunov
2012-01-27 19:40 ` Andi Kleen
2012-01-27 20:55 ` Eric W. Biederman [this message]
2012-01-27 18:40 ` Eric W. Biederman
2012-01-27 18:45 ` Cyrill Gorcunov
2012-01-27 19:10 ` Cyrill Gorcunov
2012-01-27 19:37 ` Vasiliy Kulikov
2012-01-27 19:59 ` hpanvin@gmail.com
2012-01-27 20:07 ` Cyrill Gorcunov
2012-01-27 20:19 ` KOSAKI Motohiro
2012-01-27 20:33 ` Eric W. Biederman
2012-01-27 20:50 ` Cyrill Gorcunov
2012-01-27 21:19 ` Eric W. Biederman
2012-01-27 20:34 ` Glauber Costa
2012-01-27 20:37 ` H. Peter Anvin
2012-01-27 20:47 ` Cyrill Gorcunov
2012-01-27 17:53 ` [RFC c/r 3/4] c/r: procfs: add arg_start/end, env_start/end and exit_code members to /proc/$pid/stat Cyrill Gorcunov
2012-01-27 18:29 ` Kees Cook
2012-01-27 20:00 ` KOSAKI Motohiro
2012-01-27 20:10 ` Cyrill Gorcunov
2012-01-27 17:53 ` [RFC c/r 4/4] c/r: prctl: Extend PR_SET_MM to set up more mm_struct entries Cyrill Gorcunov
2012-01-27 18:37 ` Kees Cook
2012-01-27 18:43 ` Cyrill Gorcunov
2012-01-27 20:31 ` KOSAKI Motohiro
2012-01-27 20:28 ` KOSAKI Motohiro
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=m1mx98zwyx.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=avagin@openvz.org \
--cc=eric.dumazet@gmail.com \
--cc=glommer@parallels.com \
--cc=gorcunov@openvz.org \
--cc=hpa@zytor.com \
--cc=kosaki.motohiro@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=mingo@elte.hu \
--cc=penberg@kernel.org \
--cc=segoon@openwall.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=xemul@openvz.org \
--cc=xemul@parallels.com \
/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.