linux-kernel - Re: [PATCH 0/3] x86: add cpuset

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080402012006.1722c2bd.pj@sgi.com>
Date:	Wed, 2 Apr 2008 01:20:06 -0500
From:	Paul Jackson <pj@....com>
To:	Mike Travis <travis@....com>
Cc:	mingo@...e.hu, tglx@...utronix.de, hpa@...or.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] x86: add cpuset_scnprintf function

Hmmm ... my apologies, Mike, if I overlooked some earlier discussion
of this patchset on one of the other more limited email threads that
we share ... however a couple of aspects of this patchset don't fit
so well for me.
 1) I'm surprised to see this new routine called 'cpuset_scnprintf'
    (with the "cpuset" prefix), rather than a variant of a trio of
    names with prefixes of bitmap_, cpumask_, and nodemask_, like
    the other print routines in the bitmap family.  This doesn't
    seem to be a cpuset function to me, but a bitmap (and derived
    types cpumask and nodemask) printing function.
 2) The idea of the patch, that being a kernel modal flag that if
    set, changes a few particular details of the kernel API for all,
    seems like something I'd rarely want to do, unless I was really
    short of other options.  It leads to one app breaking another
    as a result of changing this mode, and to head butting between
    apps which cannot agree on how to set the mode.  And it introduces
    the option of breaking an existing API, which is seldom a good
    option.

I tried reading the opening "discussion that led up" comments you
posted, but couldn't find any overwhelming problem that had to be
solved of sufficient magnitude and quandry of sufficient difficulty
to justify the API conflicts and breakage in (2) above.  I did find
this comment, apparently by Bert Wesarg (though that's not clear
from your presentation):

>  If you change the format, the brown-paper-bag is yours.

I don't see a compelling response to the above comment.

Granted, what you've done isn't outright changing the format.  Rather it
is handing user space a means to change the format system-wide.

However doing this is worse in my view than simply breaking the format
outright, unilaterally and irrevocably.  If you just flat out stick a
fork in an API and break it hard on some release, then at least user
space knows that it must adapt or die at that version.  If you hand
user space the means to break that API, then any properly and
defensively written user code has to be prepared to deal with both API
flavors, and the majority of user space code is broken half the time,
when run on a system with the API variant it wasn't expecting.  More
over, you end up with apps having "toilet seat wars" with each other:
you left it up and it should be down; no you left it down and it should
be up.  Not a pretty sight.

Perhaps I totally misunderstand this patchset ?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.940.382.4214
--
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/