From: Cyrill Gorcunov <gorcunov@openvz.org>
To: Pavel Emelyanov <xemul@parallels.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
Stanislav Kinsbursky <skinsbursky@parallels.com>,
James Bottomley <jbottomley@parallels.com>
Subject: Re: [patch 0/4] Resending, c/r series v2
Date: Wed, 15 Feb 2012 11:42:24 +0400 [thread overview]
Message-ID: <20120215074224.GB4533@moon> (raw)
In-Reply-To: <4F3B3A14.7000305@parallels.com>
On Wed, Feb 15, 2012 at 08:52:36AM +0400, Pavel Emelyanov wrote:
> On 02/15/2012 02:51 AM, Andrew Morton wrote:
> > On Mon, 13 Feb 2012 20:48:22 +0400
> > Cyrill Gorcunov <gorcunov@openvz.org> wrote:
> >
> >> Hi, this series hopefully in a good shape
> >>
> >> - sys_kcmp now depends on CONFIG_CHECKPOINT_RESTORE
> >>
> >> - the extension of /proc/pid/stat now done against
> >> linux-next/master
> >>
> >> Please letme know if I've missed something.
> >
> > Thus far our (my) approach has been to trickle the c/r support code
> > into mainline as it is developed. Under the assumption that the end
> > result will be acceptable and useful kernel code.
> >
> > I'm afraid that I'm losing confidence in that approach. We have this
> > patchset, we have Stanislav's "IPC: checkpoint/restore in userspace
> > enhancements" (which apparently needs to get more complex to support
> > LSM context c/r). I simply *don't know* what additional patchsets are
> > expected. And from what you told me it sounds like networking support
> > is at a very early stage and I fear for what the end result of that
> > will look like.
>
> I understand. But there was a confidence that nobody wanted the c/r stuff to
> be the "one big kernel subsystem", but it should rather be "a bunch of small
> API-s for what is required". The amount of code for the initial C/R attempt was
> ~100 patches. The amount of code to support our user-space C/R implementation
> *only* is ~10 and the feature-set of both is already comparable.
>
Andrew, I hope Pavel has addressed all your concerns? What I personally
trying to achieve mostly -- the patches should be as minimum as possible,
still usable. I believe the patches which are already in tree are useful for
other projects as well (for example -- /proc/pid/task/tid/"children" to find
all children and build process topology fast). prctl extension look a bit
redundant for kernel in general, but they are easily turnable off via Kconfig
option. /proc/pid/map_files/ might be redundant too but it could be eliminated
via Kconfig as well. So I think the both series actually do not bring much noise
into kernel itself.
Cyrill
prev parent reply other threads:[~2012-02-15 7:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 16:48 [patch 0/4] Resending, c/r series v2 Cyrill Gorcunov
2012-02-13 16:48 ` [patch 1/4] fs, proc: Introduce /proc/<pid>/task/<tid>/children entry v9 Cyrill Gorcunov
2012-02-13 16:48 ` [patch 2/4] syscalls, x86: Add __NR_kcmp syscall v8 Cyrill Gorcunov
2012-02-14 23:13 ` Andrew Morton
2012-02-15 6:52 ` Cyrill Gorcunov
2012-02-15 6:55 ` hpanvin@gmail.com
2012-02-15 7:04 ` Cyrill Gorcunov
2012-02-15 7:24 ` Cyrill Gorcunov
2012-02-15 21:53 ` Andrew Morton
2012-02-15 22:00 ` Cyrill Gorcunov
2012-02-15 22:09 ` Cyrill Gorcunov
2012-02-13 16:48 ` [patch 3/4] c/r: procfs: add arg_start/end, env_start/end and exit_code members to /proc/$pid/stat Cyrill Gorcunov
2012-02-13 16:48 ` [patch 4/4] c/r: prctl: Extend PR_SET_MM to set up more mm_struct entries v2 Cyrill Gorcunov
2012-02-14 22:51 ` [patch 0/4] Resending, c/r series v2 Andrew Morton
2012-02-15 4:52 ` Pavel Emelyanov
2012-02-15 7:42 ` Cyrill Gorcunov [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=20120215074224.GB4533@moon \
--to=gorcunov@openvz.org \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jbottomley@parallels.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=skinsbursky@parallels.com \
--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.