All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Iago López Galeiras" <iago@endocode.com>
To: Jean Delvare <jdelvare@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Djalal Harouni <djalal@endocode.com>,
	Alban Crequy <alban@endocode.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: config PROC_CHILDREN
Date: Wed, 8 Jul 2015 16:18:28 +0200	[thread overview]
Message-ID: <559D3134.1080603@endocode.com> (raw)
In-Reply-To: <20150704190728.6a1b8a5a@endymion.delvare>

On 07/04/2015 07:07 PM, Jean Delvare wrote:
> Hi Iago,
> 
> Please don't top-post.
> 
> On Fri, 3 Jul 2015 11:10:45 +0200, Iago López Galeiras wrote:
>> Hi Jean,
>>
>> The purpose of this option is enabling /proc/<pid>/task/<tid>/children without
>> having to enable CHECKPOINT_RESTORE, which is hidden behind EXPERT.
>>
>> Regarding its lack of help, documentation is in already in place[1] but perhaps
>> that's not clear for the user because as you say the Kconfig help text is missing.
>>
>> I suggest adding something like:
>>
>>     Provides a fast way to retrieve first level children pids of a task. See
>>     <file:Documentation/filesystems/proc.txt> for more information.
>>
>> Do you think that's enough?
> 
> That's a start, the reference to Documentation/filesystems/proc.txt is
> good but I think we can do better. You need to help the user make the
> decision. Why should he/she say Y or N? The user should NOT have to look
> at an external documentation file if the answer is N. I would suggest
> the following:
> 
> Say Y if running any user-space software which takes benefit from this
> interface. For example, rkt is such a piece of software.

That makes it more clear for the user. Thanks!

> That being said, I am curious... Is this interface so expensive that it
> really deserves a separate option, instead of always enabling it? This
> seems to be a fairly generic feature that a lot of scripts and tools
> could benefit from (starting with pstree I suppose.)

I don't think I have enough information to answer that question. I'll CC Cyrill
Gorcunov and Andrew Morton.

-- 

Iago López Galeiras
Software developer @ Endocode AG
iago@endocode.com

  reply	other threads:[~2015-07-08 14:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-03  7:39 config PROC_CHILDREN Jean Delvare
2015-07-03  9:10 ` Iago López Galeiras
2015-07-04 17:07   ` Jean Delvare
2015-07-08 14:18     ` Iago López Galeiras [this message]
2015-07-08 14:46       ` Cyrill Gorcunov
2015-07-08 14:50       ` Djalal Harouni
2015-07-08 16:33         ` Jean Delvare
2015-07-08 16:34       ` Jean Delvare

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=559D3134.1080603@endocode.com \
    --to=iago@endocode.com \
    --cc=akpm@linux-foundation.org \
    --cc=alban@endocode.com \
    --cc=djalal@endocode.com \
    --cc=gorcunov@openvz.org \
    --cc=jdelvare@suse.de \
    --cc=linux-kernel@vger.kernel.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.