public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* any remaining interest in a Kbuild "maturity" level?
@ 2009-08-02 13:26 Robert P. J. Day
  0 siblings, 0 replies; only message in thread
From: Robert P. J. Day @ 2009-08-02 13:26 UTC (permalink / raw)
  To: Linux Kernel Mailing List


  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
========================================================================

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2009-08-02 13:29 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-02 13:26 any remaining interest in a Kbuild "maturity" level? Robert P. J. Day

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox