linux-kernel - Re: [PATCH v4] control groups: documentation improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20140417145723.GI15326@htj.dyndns.org>
Date:	Thu, 17 Apr 2014 10:57:23 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Glyn Normington <gnormington@...ivotal.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] control groups: documentation improvements

Hello, Glyn.

On Thu, Apr 17, 2014 at 03:51:32PM +0100, Glyn Normington wrote:
> >It's kinda useless to go through all the precise terms to re-define
> >hierarchical grouping of tasks, which is both accurate and intuitive
> >enough.  Adding extra descriptions to clarify ambiguities and just to
> >reinforce the concept would be fine but trying to build the concept
> >from the ground is silly at best.  Starting with something intuitive
> >and refining it is a far better approach.
>
> I'm sorry you feel this way. A couple of us (full disclosure: both
> mathematicians) tried hard to get a precise understanding of cgroups
> from cgroups.txt, but several terms remained vague until we had done
> some experiments and discussed our findings on the mailing list.
> 
> The aim of the patch is to crisp up the definitions of those terms
> for other newcomers, so they won't have to go through the same
> exercise.

Oh, don't get me wrong.  The current documentation is neither
intuitive or precise.  I have hard time understanding what it's
saying, so probably even just increasing precision is an improvement.

> Interestingly, after we had understood the terms, cgroups.txt seemed
> much clearer than it did originally. But that's because we were
> tending to read our new-found understanding into the text. Might you
> not be doing the same?

Sure thing.  Please go ahead and improve it.  It's not good at all in
all fronts.

> So, how would you like to proceed? You could reject the patch
> outright if you think our experience is unrepresentative. Or, for
> the benefit of other newcomers, we are willing to try reworking the
> parts you find unreadable if you could kindly pick them out. The
> choice is yours. :-)

Again, I think it's an improvement but was just hoping you could add a
bit more intuitive explanations so that it's more approchable.  The
two properties aren't mutually exclusive.

> Thanks for the clarification. If you agree to proceed, we should be
> able to find a simpler way to cover this paragraph.

I really don't mind being verbose if it makes things clearer and
easier to understand.

Thanks!

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/