mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: Adrian Reber <adrian@lisas.de>,
	linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	Andrei Vagin <avagin@virtuozzo.com>,
	Hendrik Brueckner <brueckner@linux.vnet.ibm.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Kees Cook <keescook@chromium.org>,
	Linux Containers <containers@lists.linux-foundation.org>
Subject: Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE
Date: Fri, 13 Jul 2018 13:55:41 -0700	[thread overview]
Message-ID: <20180713135541.7ada72437862c32f4563a9a8@linux-foundation.org> (raw)
In-Reply-To: <87sh4o5s82.fsf@xmission.com>

On Thu, 12 Jul 2018 11:33:33 -0500 ebiederm@xmission.com (Eric W. Biederman) wrote:

> 
> Adrian Reber <adrian@lisas.de> writes:
> 
> > The CHECKPOINT_RESTORE configuration option was introduced in 2012 and
> > combined with EXPERT. CHECKPOINT_RESTORE is already enabled in many
> > distribution kernels and also part of the defconfigs of various
> > architectures.
> >
> > To make it easier for distributions to enable CHECKPOINT_RESTORE this
> > removes EXPERT and moves the configuration option out of the EXPERT
> > block.
> 
> I think we should change the help text at the same time, to match
> our improve understanding of the situation.
> 
> Does anyone remember why this option was added at all?

Because at the time it was quite unclear that the overall project would
produce a viable result.  But the code is splattered over so many
places that getting it all going out-of-tree was impractical.  So the
#ifdef CONFIG_CHECKPOINT_RESTORE markers were initially there to a)
identify places where we should go if we decide to rip the whole thing
out and to b) ensure that the kernel would still compile and work OK
after that removal.

This caution eventually proved to be unnecessary.

> Why this option was placed under expert?

Dunno.

> What is the value of disabling this functionality ever?
> 
> Is there any reason why we don't just delete CONFIG_CHECKPOINT_RESTORE
> entirely?

For the vast number of Linux machines which aren't servers?  Check out
some defconfigs - only one of arm's 119 defconfigs selects it.



  parent reply	other threads:[~2018-07-13 20:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-12 13:07 Adrian Reber
2018-07-12 13:47 ` Oleg Nesterov
2018-07-12 13:47 ` Hendrik Brueckner
2018-07-12 13:51   ` Alice Frosi
2018-07-12 16:33 ` Eric W. Biederman
2018-07-13  8:35   ` Pavel Emelyanov
2018-07-13 13:46     ` Eric W. Biederman
2018-07-13 14:20       ` Adrian Reber
2018-07-13 20:55   ` Andrew Morton [this message]
2018-07-14  4:44     ` Kees Cook
2018-07-14  6:02       ` Josh Triplett
2018-07-14 19:04       ` Eric W. Biederman
2018-07-14 19:10         ` Josh Triplett
2018-07-14 19:39           ` Eric W. Biederman
2018-07-14 20:16             ` Josh Triplett
2018-07-14 20:19             ` Cyrill Gorcunov
2018-07-13  8:23 ` Pavel Emelyanov

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=20180713135541.7ada72437862c32f4563a9a8@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=adrian@lisas.de \
    --cc=avagin@virtuozzo.com \
    --cc=brueckner@linux.vnet.ibm.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=gorcunov@openvz.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=xemul@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome