[lkml]   [2012]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 0/4] Resending, c/r series v2
On Mon, 13 Feb 2012 20:48:22 +0400
Cyrill Gorcunov <> 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.

So I don't feel that I can continue feeding these things into mainline
until someone can convince me that we won't have a nasty mess (and/or
an unsufficiently useful feature) at the end of the project.

The traditional approach is to develop the feature out-of-tree until it
is "finished". That's a lot more hackwork for you guys and it leads to
a poorer feature - this approach inevitably has a lower level of review
and inhibits code rework.

An alternative is for me to buffer the patches in my tree until it is
all sufficiently finished. That also is more work for your team, but
it will produce better code, because of additional review and code
rework resulting from that review.

I don't know how many patches that would end up being (this is part of
the problem!) nor how long they would be carried for.

So. Please talk to me. How long is this all going to take, and what
will the final result look like?

 \ /
  Last update: 2012-02-14 23:53    [W:0.085 / U:14.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site