linux-kernel - Re: maturity and status and attributes, oh my!

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.64.0709010425400.26137@localhost.localdomain>
Date:	Sat, 1 Sep 2007 04:34:24 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Dave Jones <davej@...hat.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: maturity and status and attributes, oh my!

On Fri, 31 Aug 2007, Dave Jones wrote:

> On Fri, Aug 31, 2007 at 05:38:34PM -0400, Robert P. J. Day wrote:

> > it's a natural progression and, at any point, a feature cannot
> > possibly have more than one maturity value.  it would be as absurd
> > as saying that someone was a teenager *and* was a twenty-something
> > at the same time.  not possible.
>
> Again, not so black and white. It's feasible that something can be
> experimental on one architecture, stable on another (typically x86),
> or even deprecated on x86, but still supported on other
> architectures. It's not just a per arch thing either, in some cases,
> we've had differing levels of maturity based upon other hardware
> constraints, or even varying versions of system software.

absolutely agreed.  but in cases like that, it might just be easier to
not tag that feature *at all*.  nothing in this proposal *forces*
someone to start tagging kernel features in any way.  as you point
out, there may be cases where trying to tag a feature becomes so
hopelessly vague and special-cased, it's easier to just leave it
alone.  but that still doesn't take away from the value of being able
to use this construct elsewhere where its use *is* clear-cut and
unambiguous.

it's like the current use of "EXPERIMENTAL" -- choosing to see
features that are EXPERIMENTAL doesn't change the build process in any
way -- it just affects the choices you're allowed to make.  it doesn't
*force* you to *take* any of those choices.  that's all this new
construct is supposed to do as well.

rday

p.s.  if i read simon's earlier patch correctly, all it's doing right
now is allowing assignment of attributes and values to kernel features
-- it does nothing in terms of being able to use that feature in the
config process.  that would be step two, after this first step is
added and seems to be correct.

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================
-
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/