linux-kernel - any remaining interest in a Kbuild "maturity" level?

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

Date:	Sun, 2 Aug 2009 09:26:48 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...shcourse.ca>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: any remaining interest in a Kbuild "maturity" level?

  every few months or so, i wonder again if there's sufficient
interest in implementing a Kbuild "maturity" level to allow a kernel
builder to conveniently select or de-select kernel features of varying
levels of maturity.

  that was all covered here a while back:

    http://kerneltrap.org/node/7593

in a nutshell, i think there's considerable value in adding a new
Kconfig directive, "maturity", which would have values like:

config FUBAR
	maturity DEPRECATED
        or
        maturity OBSOLETE

where "maturity" describes the position along the life cycle of some
feature -- anywhere from, say, BLEEDING_EDGE to EXPERIMENTAL all the
way over to OBSOLETE, in much the same way EXPERIMENTAL is used now,
but not as a simple dependency since that's just plain hacky.  i think
it makes more sense to introduce a whole new "attribute" for that,
that would allow the user to, in short order, specify that he wanted
to build a new kernel but not use any features that were, say,
OBSOLETE or DEPRECATED.

  the additional convenience of this new attribute means that, when
you're configuring a kernel, you can have a "non-normal" maturity
level automatically printed next to the option, so you can immediately
see what is currently DEPRECATED or OBSOLETE, as opposed to the messy
way it's done now, where config options and their EXPERIMENTAL-ness
have a bad habit of getting out of sync, as you see here in
crypto/Kconfig:

config CRYPTO_XCBC
        tristate "XCBC support"
        depends on EXPERIMENTAL

as you can see, there's a mismatch between what's printed and the fact
that that config variable is EXPERIMENTAL, and that sort of mismatch
happens fairly frequently.

  i don't think this would be all that hard to implement, and it
wouldn't be very disruptive -- the new directive could be added but,
until it's used, it would have no effect whatever.

  thoughts?  or should i just forget this idea?

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Linux Consulting, Training and Annoying Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
"Kernel Newbie Corner" column @ linux.com:          http://cli.gs/WG6WYX
========================================================================
--
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/