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-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702251650580.29271@CPE00045a9c397f-CM001225dbafb6>
Date:	Sun, 25 Feb 2007 17:07:24 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: second thoughts about DEPRECATED and OBSOLETE maturity levels


  having championed the cause of adding those two code maturity levels
to init/Kconfig, i just realized that implementing them as simple
dependencies has a *really* annoying shortcoming.

  in order to display that a kernel config feature is experimental,
developers have not only made that feature depend on EXPERIMENTAL, but
they've also had to *explicitly* add the trailer "(EXPERIMENTAL)" to
the prompt line in the Kconfig file, to make it visually obvious.

  obviously, it would be *way* nicer if that trailer were produced on
the fly for any "EXPERIMENTAL" feature, just as it would be for
OBSOLETE or DEPRECATED (or any other maturity levels people can dream
up).

  one solution is to hack Kconfig to look for specific dependencies
that represent maturity levels and add them automatically to those
respective lines.  doable, but kind of hacky.

  another solution is to add a new keyword like "status" or
"maturity", so that:

  config EXT4DEV_FS
        tristate "Ext4dev/ext4 extended fs support development (EXPERIMENTAL)"
        depends on EXPERIMENTAL
	...

becomes simply:

 config EXT4DEV_FS
        tristate "Ext4dev/ext4 extended fs support development"
        maturity EXPERIMENTAL
	...

internally, it could still be treated as a simple dependency, and
everything would still work.

  you know, this seemed so simple at first ...

rday

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ