[PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Gabriel C]

Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus.


Signed-off-by: Gabriel Craciunescu <crazy@pimpmylinux.org>

---

 drivers/net/irda/Kconfig              |   14 +++++++-------
 drivers/net/usb/Kconfig               |    4 ++--
 drivers/net/wireless/Kconfig          |    8 ++++----
 drivers/net/wireless/bcm43xx/Kconfig  |    2 +-
 drivers/net/wireless/zd1211rw/Kconfig |    2 +-
 net/9p/Kconfig                        |    2 +-
 net/Kconfig                           |    2 +-
 net/decnet/netfilter/Kconfig          |    2 +-
 net/ieee80211/softmac/Kconfig         |    2 +-
 net/ipv4/Kconfig                      |   16 ++++++++--------
 net/ipv6/Kconfig                      |    2 +-
 net/ipv6/netfilter/Kconfig            |    2 +-
 net/mac80211/Kconfig                  |    2 +-
 net/rxrpc/Kconfig                     |    2 +-
 net/wanrouter/Kconfig                 |    2 +-
 15 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
index 829da9a..87285a1 100644
--- a/drivers/net/irda/Kconfig
+++ b/drivers/net/irda/Kconfig
@@ -84,7 +84,7 @@ config LITELINK_DONGLE
 	  "irattach -d litelink".
 
 config MA600_DONGLE
-	tristate "Mobile Action MA600 dongle"
+	tristate "Mobile Action MA600 dongle (EXPERIMENTAL)"
 	depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL
 	help
 	  Say Y here if you want to build support for the Mobile Action MA600
@@ -97,7 +97,7 @@ config MA600_DONGLE
 	  "irattach -d ma600".
 
 config GIRBIL_DONGLE
-	tristate "Greenwich GIrBIL dongle"
+	tristate "Greenwich GIrBIL dongle (EXPERIMENTAL)"
 	depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL
 	help
 	  Say Y here if you want to build support for the Greenwich GIrBIL
@@ -108,7 +108,7 @@ config GIRBIL_DONGLE
 	  like this: "irattach -d girbil".
 
 config MCP2120_DONGLE
-	tristate "Microchip MCP2120"
+	tristate "Microchip MCP2120 (EXPERIMENTAL)"
 	depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL
 	help
 	  Say Y here if you want to build support for the Microchip MCP2120
@@ -122,7 +122,7 @@ config MCP2120_DONGLE
 	  <http://www.eyetap.org/~tangf/irda_sir_linux.html>
 
 config OLD_BELKIN_DONGLE
-	tristate "Old Belkin dongle"
+	tristate "Old Belkin dongle (EXPERIMENTAL)"
 	depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL
 	help
 	  Say Y here if you want to build support for the Adaptec Airport 1000
@@ -131,7 +131,7 @@ config OLD_BELKIN_DONGLE
 	  at the top of <file:drivers/net/irda/old_belkin.c>.
 
 config ACT200L_DONGLE
-	tristate "ACTiSYS IR-200L dongle"
+	tristate "ACTiSYS IR-200L dongle (EXPERIMENTAL)"
 	depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL
 	help
 	  Say Y here if you want to build support for the ACTiSYS IR-200L
@@ -142,7 +142,7 @@ config ACT200L_DONGLE
 	  start irattach like this: "irattach -d act200l".
 
 config KINGSUN_DONGLE
-	tristate "KingSun/DonShine DS-620 IrDA-USB dongle"
+	tristate "KingSun/DonShine DS-620 IrDA-USB dongle (EXPERIMENTAL)"
 	depends on IRDA && USB && EXPERIMENTAL
 	help
 	  Say Y or M here if you want to build support for the KingSun/DonShine
@@ -433,7 +433,7 @@ config PXA_FICP
 	  another.
 
 config MCS_FIR
-	tristate "MosChip MCS7780 IrDA-USB dongle"
+	tristate "MosChip MCS7780 IrDA-USB dongle (EXPERIMENTAL)"
 	depends on IRDA && USB && EXPERIMENTAL
 	help
 	  Say Y or M here if you want to build support for the MosChip
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 8dc09a3..387ae30 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -214,7 +214,7 @@ config USB_NET_NET1080
 	  optionally with LEDs that indicate traffic
 
 config USB_NET_PLUSB
-	tristate "Prolific PL-2301/2302 based cables"
+	tristate "Prolific PL-2301/2302 based cables (EXPERIMENTAL)"
 	# if the handshake/init/reset problems, from original 'plusb',
 	# are ever resolved ... then remove "experimental"
 	depends on USB_USBNET && EXPERIMENTAL
@@ -310,7 +310,7 @@ config USB_EPSON2888
 	  by some sample firmware from Epson.
 
 config USB_KC2190
-	boolean "KT Technology KC2190 based cables (InstaNet)"
+	boolean "KT Technology KC2190 based cables (InstaNet) (EXPERIMENTAL)"
 	depends on USB_NET_CDC_SUBSET && EXPERIMENTAL
 	help
 	  Choose this option if you're using a host-to-host cable
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index ae27af0..636a370 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -250,7 +250,7 @@ config IPW2200_PROMISCUOUS
             % echo 1 > /sys/bus/pci/drivers/ipw2200/*/rtap_iface
 
 config IPW2200_QOS
-        bool "Enable QoS support"
+        bool "Enable QoS support (EXPERIMENTAL)"
         depends on IPW2200 && EXPERIMENTAL
 
 config IPW2200_DEBUG
@@ -473,7 +473,7 @@ config PCMCIA_ATMEL
 	  Atmel at76c502 and at76c504 chips.
 
 config PCMCIA_WL3501
-      tristate "Planet WL3501 PCMCIA cards"
+      tristate "Planet WL3501 PCMCIA cards (EXPERIMENTAL)"
       depends on EXPERIMENTAL && PCMCIA && WLAN_80211
       select WIRELESS_EXT
        ---help---
@@ -482,7 +482,7 @@ config PCMCIA_WL3501
 	 micro support for ethtool.
 
 config PRISM54
-	tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus' 
+	tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus (EXPERIMENTAL)' 
 	depends on PCI && EXPERIMENTAL && WLAN_80211
 	select WIRELESS_EXT
 	select FW_LOADER
@@ -547,7 +547,7 @@ config USB_ZD1201
 	  module will be called zd1201.
 
 config RTL8187
-	tristate "Realtek 8187 USB support"
+	tristate "Realtek 8187 USB support (EXPERIMENTAL)"
 	depends on MAC80211 && USB && WLAN_80211 && EXPERIMENTAL
 	select EEPROM_93CX6
 	---help---
diff --git a/drivers/net/wireless/bcm43xx/Kconfig b/drivers/net/wireless/bcm43xx/Kconfig
index ce397e4..057781d 100644
--- a/drivers/net/wireless/bcm43xx/Kconfig
+++ b/drivers/net/wireless/bcm43xx/Kconfig
@@ -1,5 +1,5 @@
 config BCM43XX
-	tristate "Broadcom BCM43xx wireless support"
+	tristate "Broadcom BCM43xx wireless support (EXPERIMENTAL)"
 	depends on PCI && IEEE80211 && IEEE80211_SOFTMAC && WLAN_80211 && EXPERIMENTAL
 	select WIRELESS_EXT
 	select FW_LOADER
diff --git a/drivers/net/wireless/zd1211rw/Kconfig b/drivers/net/wireless/zd1211rw/Kconfig
index d1ab24a..1e7231b 100644
--- a/drivers/net/wireless/zd1211rw/Kconfig
+++ b/drivers/net/wireless/zd1211rw/Kconfig
@@ -1,5 +1,5 @@
 config ZD1211RW
-	tristate "ZyDAS ZD1211/ZD1211B USB-wireless support"
+	tristate "ZyDAS ZD1211/ZD1211B USB-wireless support (EXPERIMENTAL)"
 	depends on USB && IEEE80211_SOFTMAC && WLAN_80211 && EXPERIMENTAL
 	select WIRELESS_EXT
 	select FW_LOADER
diff --git a/net/9p/Kconfig b/net/9p/Kconfig
index 66821cd..02d86cc 100644
--- a/net/9p/Kconfig
+++ b/net/9p/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig NET_9P
 	depends on NET && EXPERIMENTAL
-	tristate "Plan 9 Resource Sharing Support (9P2000) (Experimental)"
+	tristate "Plan 9 Resource Sharing Support (9P2000) (EXPERIMENTAL)"
 	help
 	  If you say Y here, you will get experimental support for
 	  Plan 9 resource sharing via the 9P2000 protocol.
diff --git a/net/Kconfig b/net/Kconfig
index cdba08c..13e3d3b 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -191,7 +191,7 @@ config NET_PKTGEN
 	  module will be called pktgen.
 
 config NET_TCPPROBE
-	tristate "TCP connection probing"
+	tristate "TCP connection probing (EXPERIMENTAL)"
 	depends on INET && EXPERIMENTAL && PROC_FS && KPROBES
 	---help---
 	This module allows for capturing the changes to TCP connection
diff --git a/net/decnet/netfilter/Kconfig b/net/decnet/netfilter/Kconfig
index ecdb3f9..1b53545 100644
--- a/net/decnet/netfilter/Kconfig
+++ b/net/decnet/netfilter/Kconfig
@@ -2,7 +2,7 @@
 # DECnet netfilter configuration
 #
 
-menu "DECnet: Netfilter Configuration"
+menu "DECnet: Netfilter Configuration (EXPERIMENTAL)"
 	depends on DECNET && NETFILTER && EXPERIMENTAL
 
 config DECNET_NF_GRABULATOR
diff --git a/net/ieee80211/softmac/Kconfig b/net/ieee80211/softmac/Kconfig
index 2811651..02f14e4 100644
--- a/net/ieee80211/softmac/Kconfig
+++ b/net/ieee80211/softmac/Kconfig
@@ -1,5 +1,5 @@
 config IEEE80211_SOFTMAC
-	tristate "Software MAC add-on to the IEEE 802.11 networking stack"
+	tristate "Software MAC add-on to the IEEE 802.11 networking stack (EXPERIMENTAL)"
 	depends on IEEE80211 && EXPERIMENTAL
 	select WIRELESS_EXT
 	select IEEE80211_CRYPT_WEP
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index fb79097..3771fc5 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -469,7 +469,7 @@ config TCP_CONG_HTCP
 	other Reno and H-TCP flows.
 
 config TCP_CONG_HSTCP
-	tristate "High Speed TCP"
+	tristate "High Speed TCP (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	default n
 	---help---
@@ -480,7 +480,7 @@ config TCP_CONG_HSTCP
  	For more detail	see http://www.icir.org/floyd/hstcp.html
 
 config TCP_CONG_HYBLA
-	tristate "TCP-Hybla congestion control algorithm"
+	tristate "TCP-Hybla congestion control algorithm (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	default n
 	---help---
@@ -490,7 +490,7 @@ config TCP_CONG_HYBLA
 	terrestrial connections.
 
 config TCP_CONG_VEGAS
-	tristate "TCP Vegas"
+	tristate "TCP Vegas (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	default n
 	---help---
@@ -501,7 +501,7 @@ config TCP_CONG_VEGAS
 	not as aggressive as TCP Reno.
 
 config TCP_CONG_SCALABLE
-	tristate "Scalable TCP"
+	tristate "Scalable TCP (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	default n
 	---help---
@@ -511,7 +511,7 @@ config TCP_CONG_SCALABLE
 	See http://www.deneholme.net/tom/scalable/
 
 config TCP_CONG_LP
-	tristate "TCP Low Priority"
+	tristate "TCP Low Priority (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	default n
 	---help---
@@ -521,7 +521,7 @@ config TCP_CONG_LP
 	See http://www-ece.rice.edu/networks/TCP-LP/
 
 config TCP_CONG_VENO
-	tristate "TCP Veno"
+	tristate "TCP Veno (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	default n
 	---help---
@@ -533,7 +533,7 @@ config TCP_CONG_VENO
 	See http://www.ntu.edu.sg/home5/ZHOU0022/papers/CPFu03a.pdf
 
 config TCP_CONG_YEAH
-	tristate "YeAH TCP"
+	tristate "YeAH TCP (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	select TCP_CONG_VEGAS
 	default n
@@ -548,7 +548,7 @@ config TCP_CONG_YEAH
 	  http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf
 
 config TCP_CONG_ILLINOIS
-	tristate "TCP Illinois"
+	tristate "TCP Illinois (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	default n
 	---help---
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index eb0b808..1c16638 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -187,7 +187,7 @@ config IPV6_TUNNEL
 	  If unsure, say N.
 
 config IPV6_MULTIPLE_TABLES
-	bool "IPv6: Multiple Routing Tables"
+	bool "IPv6: Multiple Routing Tables (EXPERIMENTAL)"
 	depends on IPV6 && EXPERIMENTAL
 	select FIB_RULES
 	---help---
diff --git a/net/ipv6/netfilter/Kconfig b/net/ipv6/netfilter/Kconfig
index 838b8dd..15b81b6 100644
--- a/net/ipv6/netfilter/Kconfig
+++ b/net/ipv6/netfilter/Kconfig
@@ -41,7 +41,7 @@ config IP6_NF_QUEUE
 	  To compile it as a module, choose M here.  If unsure, say N.
 
 config IP6_NF_IPTABLES
-	tristate "IP6 tables support (required for filtering)"
+	tristate "IP6 tables support (required for filtering) (EXPERIMENTAL)"
 	depends on INET && IPV6 && EXPERIMENTAL
 	select NETFILTER_XTABLES
 	help
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 6fffb38..7b7709e 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -1,5 +1,5 @@
 config MAC80211
-	tristate "Generic IEEE 802.11 Networking Stack (mac80211)"
+	tristate "Generic IEEE 802.11 Networking Stack (mac80211) (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	select CRYPTO
 	select CRYPTO_ECB
diff --git a/net/rxrpc/Kconfig b/net/rxrpc/Kconfig
index e662f1d..739c58b 100644
--- a/net/rxrpc/Kconfig
+++ b/net/rxrpc/Kconfig
@@ -3,7 +3,7 @@
 #
 
 config AF_RXRPC
-	tristate "RxRPC session sockets"
+	tristate "RxRPC session sockets (EXPERIMENTAL)"
 	depends on INET && EXPERIMENTAL
 	select KEYS
 	help
diff --git a/net/wanrouter/Kconfig b/net/wanrouter/Kconfig
index 1debe1c..3fa44c9 100644
--- a/net/wanrouter/Kconfig
+++ b/net/wanrouter/Kconfig
@@ -3,7 +3,7 @@
 #
 
 config WAN_ROUTER
-	tristate "WAN router"
+	tristate "WAN router (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	---help---
 	  Wide Area Networks (WANs), such as X.25, frame relay and leased

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Wed, 18 Jul 2007, Gabriel C wrote:

> Everything 'depends on' EXPERIMENTAL should be marked as such,
> visible in the menus.

rather than add all that extraneous dreck to the Kconfig files, i
*really* wish folks would give serious thought to my earlier
suggestion about a "maturity level" attribute that could be used to
not only add a parenthesized maturity level during display, but could
also be used to activate/deactivate entire levels in one operation.

there's no point adding all that redundant content when it can all be
done automatically.

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Randy Dunlap]

On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:

> On Wed, 18 Jul 2007, Gabriel C wrote:
> 
> > Everything 'depends on' EXPERIMENTAL should be marked as such,
> > visible in the menus.
> 
> rather than add all that extraneous dreck to the Kconfig files, i
> *really* wish folks would give serious thought to my earlier
> suggestion about a "maturity level" attribute that could be used to
> not only add a parenthesized maturity level during display, but could
> also be used to activate/deactivate entire levels in one operation.
> 
> there's no point adding all that redundant content when it can all be
> done automatically.

I like it.  Are there any kconfig patches to support this plan?


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Wed, 18 Jul 2007, Randy Dunlap wrote:

> On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:
>
> > On Wed, 18 Jul 2007, Gabriel C wrote:
> >
> > > Everything 'depends on' EXPERIMENTAL should be marked as such,
> > > visible in the menus.
> >
> > rather than add all that extraneous dreck to the Kconfig files, i
> > *really* wish folks would give serious thought to my earlier
> > suggestion about a "maturity level" attribute that could be used to
> > not only add a parenthesized maturity level during display, but could
> > also be used to activate/deactivate entire levels in one operation.
> >
> > there's no point adding all that redundant content when it can all be
> > done automatically.
>
> I like it.  Are there any kconfig patches to support this plan?

once upon a time, i'd proposed just adding a couple new "config"
entries, but i eventually decided that a better approach would be
to define a whole new Kconfig directive, as in:

config FUBAR
	maturity EXPERIMENTAL (or DEPRECATED or OBSOLETE or ...)

that would require extra processing in the parser, but it would allow
the "maturity" attribute to be used for all sorts of new and wacky
things, such as automatically displaying it at the end of a config
selection, or deselecting everything OBSOLETE in a build, etc.

how hard would it be to add processing like that to the Kconfig
infrastructure?

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Jeff Garzik]

Randy Dunlap wrote:
> On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:
>> there's no point adding all that redundant content when it can all be
>> done automatically.
> 
> I like it.  Are there any kconfig patches to support this plan?


Speaking specifically to adding 'EXPERIMENTAL', I distinctly remember at 
some point in the past the config system was smart enough to print " 
(EXPERIMENTAL)" if that entry depended on CONFIG_EXPERIMENTAL.

We should head in that direction.

I strongly NAK the original patch from Gabriel C in this thread -- it 
just adds too much redundant info.  Better to add it -once-, somewhere 
inside Kconfig system.

	Jeff

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Gabriel C]

Robert P. J. Day wrote:
> On Wed, 18 Jul 2007, Gabriel C wrote:
> 
>> Everything 'depends on' EXPERIMENTAL should be marked as such,
>> visible in the menus.
> 
> rather than add all that extraneous dreck to the Kconfig files, i
> *really* wish folks would give serious thought to my earlier
> suggestion about a "maturity level" attribute that could be used to
> not only add a parenthesized maturity level during display, but could
> also be used to activate/deactivate entire levels in one operation.
> 
> there's no point adding all that redundant content when it can all be
> done automatically.


I don't know what your suggestion was , I'm sorry.

It may be for sure a good idea to add all this maturity levels
automatically but for now such an thing does not exists.

> 
> rday


Gabriel

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Wed, 18 Jul 2007, Jeff Garzik wrote:

> Randy Dunlap wrote:
> > On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:
> > > there's no point adding all that redundant content when it can all be
> > > done automatically.
> >
> > I like it.  Are there any kconfig patches to support this plan?
>
> Speaking specifically to adding 'EXPERIMENTAL', I distinctly
> remember at some point in the past the config system was smart
> enough to print " (EXPERIMENTAL)" if that entry depended on
> CONFIG_EXPERIMENTAL.
>
> We should head in that direction.

there's one point i want to re-iterate.  i'd prefer to see
EXPERIMENTAL stop being a dependency, as in:

  depends on SNAFU && FUBAR && EXPERIMENTAL

"EXPERIMENTAL" is not a dependency in the true sense of the word -- it
is more of an attribute, and i think it would far more sense to see
entries like:

  depends on SNAFU && FUBAR
  maturity EXPERIMENTAL

sure, it's more work, but i think the cost is worth it in terms of
flexibility (particularly if *i'm* not the one doing the work. :-)

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Randy Dunlap]

Jeff Garzik wrote:
> Randy Dunlap wrote:
>> On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:
>>> there's no point adding all that redundant content when it can all be
>>> done automatically.
>>
>> I like it.  Are there any kconfig patches to support this plan?
> 
> 
> Speaking specifically to adding 'EXPERIMENTAL', I distinctly remember at 
> some point in the past the config system was smart enough to print " 
> (EXPERIMENTAL)" if that entry depended on CONFIG_EXPERIMENTAL.
> 
> We should head in that direction.
> 
> I strongly NAK the original patch from Gabriel C in this thread -- it 
> just adds too much redundant info.  Better to add it -once-, somewhere 
> inside Kconfig system.
> 
>     Jeff
> 
> 

Yes, that's what Robert & I are referring to as well (AFAIK).

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Adrian Bunk]

On Wed, Jul 18, 2007 at 04:51:33PM -0400, Robert P. J. Day wrote:
> On Wed, 18 Jul 2007, Jeff Garzik wrote:
> 
> > Randy Dunlap wrote:
> > > On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:
> > > > there's no point adding all that redundant content when it can all be
> > > > done automatically.
> > >
> > > I like it.  Are there any kconfig patches to support this plan?
> >
> > Speaking specifically to adding 'EXPERIMENTAL', I distinctly
> > remember at some point in the past the config system was smart
> > enough to print " (EXPERIMENTAL)" if that entry depended on
> > CONFIG_EXPERIMENTAL.
> >
> > We should head in that direction.
> 
> there's one point i want to re-iterate.  i'd prefer to see
> EXPERIMENTAL stop being a dependency, as in:
> 
>   depends on SNAFU && FUBAR && EXPERIMENTAL
> 
> "EXPERIMENTAL" is not a dependency in the true sense of the word -- it
> is more of an attribute, and i think it would far more sense to see
> entries like:
> 
>   depends on SNAFU && FUBAR
>   maturity EXPERIMENTAL

Plus some special case in the kconfig code that you can somewhere select 
the maturity levels you want to use (currently it's a normal option 
kconfig doesn't have to know anything about).

Remind me, would there be any big advantage after such a change besides
being able to automatically print " (EXPERIMENTAL)" at the end of 
the prompt?

> sure, it's more work, but i think the cost is worth it in terms of
> flexibility (particularly if *i'm* not the one doing the work. :-)

If you are not doing it, noone might do it.
And discusing improvements noone will implement is somehow pointless...

> rday

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Wed, 18 Jul 2007, Adrian Bunk wrote:

> On Wed, Jul 18, 2007 at 04:51:33PM -0400, Robert P. J. Day wrote:
> > On Wed, 18 Jul 2007, Jeff Garzik wrote:
> >
> > > Randy Dunlap wrote:
> > > > On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:
> > > > > there's no point adding all that redundant content when it can all be
> > > > > done automatically.
> > > >
> > > > I like it.  Are there any kconfig patches to support this plan?
> > >
> > > Speaking specifically to adding 'EXPERIMENTAL', I distinctly
> > > remember at some point in the past the config system was smart
> > > enough to print " (EXPERIMENTAL)" if that entry depended on
> > > CONFIG_EXPERIMENTAL.
> > >
> > > We should head in that direction.
> >
> > there's one point i want to re-iterate.  i'd prefer to see
> > EXPERIMENTAL stop being a dependency, as in:
> >
> >   depends on SNAFU && FUBAR && EXPERIMENTAL
> >
> > "EXPERIMENTAL" is not a dependency in the true sense of the word
> > -- it is more of an attribute, and i think it would far more sense
> > to see entries like:
> >
> >   depends on SNAFU && FUBAR
> >   maturity EXPERIMENTAL
>
> Plus some special case in the kconfig code that you can somewhere
> select the maturity levels you want to use (currently it's a normal
> option kconfig doesn't have to know anything about).

i already described that here:

http://readlist.com/lists/vger.kernel.org/linux-kernel/66/334172.html

where the top-level config would look something like:

[*] Activate maturity attributes
  [*] EXPERIMENTAL
  [*] DEPRECATED
  [*] OBSOLETE
  [*] BROKEN

whereupon you could select any combination of the attributes you want
displayed *beyond the regular ones* during the config process.

> Remind me, would there be any big advantage after such a change
> besides being able to automatically print " (EXPERIMENTAL)" at the
> end of the prompt?

defining a new Kconfig attribute means you can process it differently
from regular dependencies.  and if it's added as a general feature, it
can be used for other possible attributes beyond just a maturity
level.

if you leave these maturity levels as regular dependencies, you're
going to have to brute force and manually process them, and why make
it that ugly?

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Wed, 18 Jul 2007, Adrian Bunk wrote:

> If you are not doing it, noone might do it. And discusing
> improvements noone will implement is somehow pointless...

sure, i'm willing to help, but i don't think doing *nothing* about it
is an option.  you may not like gabriel's proposed patch, but you have
to admit that he has a valid objection that should be addressed.  so
you can address it the manual and brute force way, or you can invest a
little more time and do it right.

but, either way, i think you have to deal with it.  now it's just time
to make a choice.

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Adrian Bunk]

On Wed, Jul 18, 2007 at 05:18:20PM -0400, Robert P. J. Day wrote:
> On Wed, 18 Jul 2007, Adrian Bunk wrote:
> 
> > On Wed, Jul 18, 2007 at 04:51:33PM -0400, Robert P. J. Day wrote:
> > > On Wed, 18 Jul 2007, Jeff Garzik wrote:
> > >
> > > > Randy Dunlap wrote:
> > > > > On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:
> > > > > > there's no point adding all that redundant content when it can all be
> > > > > > done automatically.
> > > > >
> > > > > I like it.  Are there any kconfig patches to support this plan?
> > > >
> > > > Speaking specifically to adding 'EXPERIMENTAL', I distinctly
> > > > remember at some point in the past the config system was smart
> > > > enough to print " (EXPERIMENTAL)" if that entry depended on
> > > > CONFIG_EXPERIMENTAL.
> > > >
> > > > We should head in that direction.
> > >
> > > there's one point i want to re-iterate.  i'd prefer to see
> > > EXPERIMENTAL stop being a dependency, as in:
> > >
> > >   depends on SNAFU && FUBAR && EXPERIMENTAL
> > >
> > > "EXPERIMENTAL" is not a dependency in the true sense of the word
> > > -- it is more of an attribute, and i think it would far more sense
> > > to see entries like:
> > >
> > >   depends on SNAFU && FUBAR
> > >   maturity EXPERIMENTAL
> >
> > Plus some special case in the kconfig code that you can somewhere
> > select the maturity levels you want to use (currently it's a normal
> > option kconfig doesn't have to know anything about).
> 
> i already described that here:
> 
> http://readlist.com/lists/vger.kernel.org/linux-kernel/66/334172.html
> 
> where the top-level config would look something like:
> 
> [*] Activate maturity attributes
>   [*] EXPERIMENTAL
>   [*] DEPRECATED
>   [*] OBSOLETE
>   [*] BROKEN

We already made the mistake of offering BROKEN as an option in the past, 
and the result was that people enabled it instead of reporting that a 
dependency on BROKEN was wrong.

> whereupon you could select any combination of the attributes you want
> displayed *beyond the regular ones* during the config process.
> 
> > Remind me, would there be any big advantage after such a change
> > besides being able to automatically print " (EXPERIMENTAL)" at the
> > end of the prompt?
> 
> defining a new Kconfig attribute means you can process it differently
> from regular dependencies.  and if it's added as a general feature, it
> can be used for other possible attributes beyond just a maturity
> level.
> 
> if you leave these maturity levels as regular dependencies, you're
> going to have to brute force and manually process them, and why make
> it that ugly?

I would consider it more ugly to special case this and that in the 
kconfig code when plain dependencies already offer exactly the same 
functionality...

> rday

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Thu, 19 Jul 2007, Adrian Bunk wrote:

...
> I would consider it more ugly to special case this and that in the
> kconfig code when plain dependencies already offer exactly the same
> functionality...

well, this is the *third* time i've proposed adding this kind of
feature so, at this point, i've really given up caring about it.  if
someone wants to do this, have at it.  i have better things to do than
to keep suggesting it and getting nowhere with it.

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Stefan Richter]

Robert P. J. Day wrote:
> On Thu, 19 Jul 2007, Adrian Bunk wrote:
> 
> ...
>> I would consider it more ugly to special case this and that in the
>> kconfig code when plain dependencies already offer exactly the same
>> functionality...
> 
> well, this is the *third* time i've proposed adding this kind of
> feature so, at this point, i've really given up caring about it.  if
> someone wants to do this, have at it.  i have better things to do than
> to keep suggesting it and getting nowhere with it.

For better or worse, it can often be observed that feature requests
don't set anything in motion until a first patch is sent.  Even a patch
that is far from perfect can get things going really quickly.  (If the
requested feature makes sense to other people.)
-- 
Stefan Richter
-=====-=-=== -=== =--==
http://arcgraph.de/sr/

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Thu, 19 Jul 2007, Stefan Richter wrote:

> Robert P. J. Day wrote:
> > On Thu, 19 Jul 2007, Adrian Bunk wrote:
> >
> > ...
> >> I would consider it more ugly to special case this and that in the
> >> kconfig code when plain dependencies already offer exactly the same
> >> functionality...
> >
> > well, this is the *third* time i've proposed adding this kind of
> > feature so, at this point, i've really given up caring about it.  if
> > someone wants to do this, have at it.  i have better things to do than
> > to keep suggesting it and getting nowhere with it.
>
> For better or worse, it can often be observed that feature requests
> don't set anything in motion until a first patch is sent.  Even a
> patch that is far from perfect can get things going really quickly.
> (If the requested feature makes sense to other people.)

i *did* submit a preliminary patch once upon a time, and it
(predictably) went nowhere.  so, if someone else wants to pick this up
and do something with it, you have my blessing.  life's too short to
keep wasting time on this.

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Stefan Richter]

Robert P. J. Day wrote:
> i *did* submit a preliminary patch once upon a time, and it
> (predictably) went nowhere.

A patch which pulls the word "experimental" into prompts or adds a
dedicated directive for tagging of options?  Can't find it in archives.
-- 
Stefan Richter
-=====-=-=== -=== =--==
http://arcgraph.de/sr/

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Randy Dunlap]

On Thu, 19 Jul 2007 05:25:30 -0400 (EDT) Robert P. J. Day wrote:

> On Thu, 19 Jul 2007, Stefan Richter wrote:
> 
> > Robert P. J. Day wrote:
> > > On Thu, 19 Jul 2007, Adrian Bunk wrote:
> > >
> > > ...
> > >> I would consider it more ugly to special case this and that in the
> > >> kconfig code when plain dependencies already offer exactly the same
> > >> functionality...
> > >
> > > well, this is the *third* time i've proposed adding this kind of
> > > feature so, at this point, i've really given up caring about it.  if
> > > someone wants to do this, have at it.  i have better things to do than
> > > to keep suggesting it and getting nowhere with it.
> >
> > For better or worse, it can often be observed that feature requests
> > don't set anything in motion until a first patch is sent.  Even a
> > patch that is far from perfect can get things going really quickly.
> > (If the requested feature makes sense to other people.)
> 
> i *did* submit a preliminary patch once upon a time, and it
> (predictably) went nowhere.  so, if someone else wants to pick this up
> and do something with it, you have my blessing.  life's too short to
> keep wasting time on this.

I think that Stefan means a patch to the kconfig source code,
not the the Kconfig files.  Good luck.  I'd still like to see it.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Thu, 19 Jul 2007, Randy Dunlap wrote:

> On Thu, 19 Jul 2007 05:25:30 -0400 (EDT) Robert P. J. Day wrote:
>
> > On Thu, 19 Jul 2007, Stefan Richter wrote:
> >
> > > Robert P. J. Day wrote:
> > > > On Thu, 19 Jul 2007, Adrian Bunk wrote:
> > > >
> > > > ...
> > > >> I would consider it more ugly to special case this and that in the
> > > >> kconfig code when plain dependencies already offer exactly the same
> > > >> functionality...
> > > >
> > > > well, this is the *third* time i've proposed adding this kind of
> > > > feature so, at this point, i've really given up caring about it.  if
> > > > someone wants to do this, have at it.  i have better things to do than
> > > > to keep suggesting it and getting nowhere with it.
> > >
> > > For better or worse, it can often be observed that feature requests
> > > don't set anything in motion until a first patch is sent.  Even a
> > > patch that is far from perfect can get things going really quickly.
> > > (If the requested feature makes sense to other people.)
> >
> > i *did* submit a preliminary patch once upon a time, and it
> > (predictably) went nowhere.  so, if someone else wants to pick this up
> > and do something with it, you have my blessing.  life's too short to
> > keep wasting time on this.
>
> I think that Stefan means a patch to the kconfig source code,
> not the the Kconfig files.  Good luck.  I'd still like to see it.

yes, i understand what he wanted now.  as a first step (that
theoretically shouldn't change any behaviour), i'd patch the Kconfig
structure to add a new attribute ("maturity") which would be allowed
to be set to *exactly one* of a pre-defined set of values (say,
OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING).  and that's
it, nothing more.

don't try to do anything with any of that just yet, just add the
infrastructure to support the (optional) association of a maturity
level with a config option.  that's step one.

rday

p.s.  and, yes, i really meant it when i said that an option could
have one, and *only* one, maturity level.  if you start arguing
this point, i swear, i will hunt you down and give you *such* a
wedgie.

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Simon Arlott]

On 19/07/07 17:19, Robert P. J. Day wrote:
> On Thu, 19 Jul 2007, Randy Dunlap wrote:
>> I think that Stefan means a patch to the kconfig source code,
>> not the the Kconfig files.  Good luck.  I'd still like to see it.
> 
> yes, i understand what he wanted now.  as a first step (that
> theoretically shouldn't change any behaviour), i'd patch the Kconfig
> structure to add a new attribute ("maturity") which would be allowed
> to be set to *exactly one* of a pre-defined set of values (say,
> OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING).  and that's
> it, nothing more.
> 
> don't try to do anything with any of that just yet, just add the
> infrastructure to support the (optional) association of a maturity
> level with a config option.  that's step one.

What about something like this? I'm not sure if the addition to sym_init
is desirable... I also had to prefix _ to the name for now otherwise it
conflicts badly with the current symbols. It probably should stop
"depends on _BROKEN" etc. too.

---
diff --git a/init/Kconfig b/init/Kconfig
diff --git a/net/Kconfig b/net/Kconfig
index cdba08c..5e2f4db 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -6,6 +6,7 @@ menu "Networking"

 config NET
 	bool "Networking support"
+	maturity _BROKEN
 	---help---
 	  Unless you really know what you are doing, you should say Y here.
 	  The reason is that some programs need kernel networking support even
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index fb2bb30..1dea08e 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -256,7 +256,7 @@ $(obj)/lkc_defs.h: $(src)/lkc_proto.h
 # The following requires flex/bison/gperf
 # By default we use the _shipped versions, uncomment the following line if
 # you are modifying the flex/bison src.
-# LKC_GENPARSER := 1
+LKC_GENPARSER := 1

 ifdef LKC_GENPARSER

diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 1199baf..cc9be0e 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -211,6 +211,22 @@ static int conf_sym(struct menu *menu)

 	while (1) {
 		printf("%*s%s ", indent - 1, "", menu->prompt->text);
+		switch (sym->maturity) {
+		case M_EXPERIMENTAL:
+			printf("(EXPERIMENTAL) ");
+			break;
+		case M_DEPRECATED:
+			printf("(DEPRECATED) ");
+			break;
+		case M_OBSOLETE:
+			printf("(OBSOLETE) ");
+			break;
+		case M_BROKEN:
+			printf("(BROKEN) ");
+			break;
+		default:
+			break;
+		}
 		if (sym->name)
 			printf("(%s) ", sym->name);
 		type = sym_get_type(sym);
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index 6084525..a22b6c1 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -60,7 +60,11 @@ struct symbol_value {
 };

 enum symbol_type {
-	S_UNKNOWN, S_BOOLEAN, S_TRISTATE, S_INT, S_HEX, S_STRING, S_OTHER
+	S_UNKNOWN, S_BOOLEAN, S_TRISTATE, S_INT, S_HEX, S_STRING, S_MATURITY,
S_OTHER
+};
+
+enum maturity_level {
+	M_NONE, M_EXPERIMENTAL, M_DEPRECATED, M_OBSOLETE, M_BROKEN
 };

 enum {
@@ -72,6 +76,7 @@ struct symbol {
 	struct symbol *next;
 	char *name;
 	char *help;
+	enum maturity_level maturity;
 	enum symbol_type type;
 	struct symbol_value curr;
 	struct symbol_value def[4];
diff --git a/scripts/kconfig/lex.zconf.c_shipped
b/scripts/kconfig/lex.zconf.c_shipped
diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index 8a07ee4..9add1cd 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -79,6 +79,7 @@ void menu_end_menu(void);
 void menu_add_entry(struct symbol *sym);
 void menu_end_entry(void);
 void menu_add_dep(struct expr *dep);
+void menu_set_maturity(struct symbol *sym);
 struct property *menu_add_prop(enum prop_type type, char *prompt,
struct expr *expr, struct expr *dep);
 struct property *menu_add_prompt(enum prop_type type, char *prompt,
struct expr *dep);
 void menu_add_expr(enum prop_type type, struct expr *expr, struct expr
*dep);
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index d0e4fa5..eaf199b 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -238,6 +238,7 @@ search_help[] = N_(
 	"Result:\n"
 	"-----------------------------------------------------------------\n"
 	"Symbol: FOO [=m]\n"
+	"Maturity: FOO\n"
 	"Prompt: Foo bus is used to drive the bar HW\n"
 	"Defined at drivers/pci/Kconfig:47\n"
 	"Depends on: X86_LOCAL_APIC && X86_IO_APIC || IA64\n"
@@ -359,6 +360,27 @@ static void get_symbol_str(struct gstr *r, struct
symbol *sym)

 	str_printf(r, "Symbol: %s [=%s]\n", sym->name,
 	                               sym_get_string_value(sym));
+
+	if (sym->maturity != M_NONE) {
+		str_append(r, "Maturity: ");
+		switch (sym->maturity) {
+		case M_EXPERIMENTAL:
+			str_append(r, "EXPERIMENTAL\n");
+			break;
+		case M_DEPRECATED:
+			str_append(r, "DEPRECATED\n");
+			break;
+		case M_OBSOLETE:
+			str_append(r, "OBSOLETE\n");
+			break;
+		case M_BROKEN:
+			str_append(r, "BROKEN\n");
+			break;
+		default:
+			break;
+		}
+	}
+
 	for_all_prompts(sym, prop)
 		get_prompt_str(r, prop);
 	hit = false;
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index f14aeac..3e37e5b 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -104,6 +104,15 @@ void menu_add_dep(struct expr *dep)
 	current_entry->dep = expr_alloc_and(current_entry->dep,
menu_check_dep(dep));
 }

+void menu_set_maturity(struct symbol *sym)
+{
+	if (sym->type != S_MATURITY) {
+		zconf_error("'%s' is an invalid maturity level", sym->name);
+	} else {
+		current_entry->sym->maturity = sym->maturity;
+	}
+}
+
 void menu_set_type(int type)
 {
 	struct symbol *sym = current_entry->sym;
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index c35dcc5..280ee8f 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -72,6 +72,22 @@ void sym_init(void)
 	sym->type = S_STRING;
 	sym->flags |= SYMBOL_AUTO;
 	sym_add_default(sym, uts.release);
+
+	sym = sym_lookup("_EXPERIMENTAL", 0);
+	sym->type = S_MATURITY;
+	sym->maturity = M_EXPERIMENTAL;
+
+	sym = sym_lookup("_DEPRECATED", 0);
+	sym->type = S_MATURITY;
+	sym->maturity = M_DEPRECATED;
+
+	sym = sym_lookup("_OBSOLETE", 0);
+	sym->type = S_MATURITY;
+	sym->maturity = M_OBSOLETE;
+
+	sym = sym_lookup("_BROKEN", 0);
+	sym->type = S_MATURITY;
+	sym->maturity = M_BROKEN;
 }

 enum symbol_type sym_get_type(struct symbol *sym)
@@ -100,6 +116,8 @@ const char *sym_type_name(enum symbol_type type)
 		return "hex";
 	case S_STRING:
 		return "string";
+	case S_MATURITY:
+		return "maturity";
 	case S_UNKNOWN:
 		return "unknown";
 	case S_OTHER:
@@ -679,6 +697,7 @@ struct symbol *sym_lookup(const char *name, int isconst)
 	memset(symbol, 0, sizeof(*symbol));
 	symbol->name = new_name;
 	symbol->type = S_UNKNOWN;
+	symbol->maturity = M_NONE;
 	if (isconst)
 		symbol->flags |= SYMBOL_CONST;

diff --git a/scripts/kconfig/zconf.gperf b/scripts/kconfig/zconf.gperf
index 9b44c80..756d559 100644
--- a/scripts/kconfig/zconf.gperf
+++ b/scripts/kconfig/zconf.gperf
@@ -25,6 +25,7 @@ endif,		T_ENDIF,	TF_COMMAND
 depends,	T_DEPENDS,	TF_COMMAND
 requires,	T_REQUIRES,	TF_COMMAND
 optional,	T_OPTIONAL,	TF_COMMAND
+maturity,	T_MATURITY,	TF_COMMAND
 default,	T_DEFAULT,	TF_COMMAND, S_UNKNOWN
 prompt,		T_PROMPT,	TF_COMMAND
 tristate,	T_TYPE,		TF_COMMAND, S_TRISTATE
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 92eb02b..1b47966 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -66,6 +66,7 @@ static struct menu *current_menu, *current_entry;
 %token <id>T_DEPENDS
 %token <id>T_REQUIRES
 %token <id>T_OPTIONAL
+%token <id>T_MATURITY
 %token <id>T_PROMPT
 %token <id>T_TYPE
 %token <id>T_DEFAULT
@@ -120,7 +121,7 @@ stmt_list:
 ;

 option_name:
-	T_DEPENDS | T_PROMPT | T_TYPE | T_SELECT | T_OPTIONAL | T_RANGE |
T_DEFAULT
+	T_DEPENDS | T_MATURITY | T_PROMPT | T_TYPE | T_SELECT | T_OPTIONAL |
T_RANGE | T_DEFAULT
 ;

 common_stmt:
@@ -177,6 +178,7 @@ config_option_list:
 	| config_option_list config_option
 	| config_option_list symbol_option
 	| config_option_list depends
+	| config_option_list maturity
 	| config_option_list help
 	| config_option_list option_error
 	| config_option_list T_EOL
@@ -269,6 +271,7 @@ choice_option_list:
 	  /* empty */
 	| choice_option_list choice_option
 	| choice_option_list depends
+	| choice_option_list maturity
 	| choice_option_list help
 	| choice_option_list T_EOL
 	| choice_option_list option_error
@@ -349,7 +352,7 @@ menu: T_MENU prompt T_EOL
 	printd(DEBUG_PARSE, "%s:%d:menu\n", zconf_curname(), zconf_lineno());
 };

-menu_entry: menu depends_list
+menu_entry: menu maturity_set_opt depends_list
 {
 	$$ = menu_add_menu();
 };
@@ -430,6 +433,19 @@ depends: T_DEPENDS T_ON expr T_EOL
 	printd(DEBUG_PARSE, "%s:%d:requires\n", zconf_curname(), zconf_lineno());
 };

+/* maturity setting */
+
+maturity_set_opt:
+	  /* empty */
+	| maturity
+;
+
+maturity: T_MATURITY symbol T_EOL
+{
+	menu_set_maturity($2);
+	printd(DEBUG_PARSE, "%s:%d:maturity\n", zconf_curname(), zconf_lineno());
+};
+
 /* prompt statement */

 prompt_stmt_opt:
@@ -519,6 +535,7 @@ const char *zconf_tokenname(int token)
 	case T_IF:		return "if";
 	case T_ENDIF:		return "endif";
 	case T_DEPENDS:		return "depends";
+	case T_MATURITY:	return "maturity";
 	}
 	return "<token>";
 }
@@ -615,6 +632,9 @@ void print_symbol(FILE *out, struct menu *menu)
 	case S_HEX:
 		fputs("  hex\n", out);
 		break;
+	case S_MATURITY:
+		fputs("  maturity\n", out);
+		break;
 	default:
 		fputs("  ???\n", out);
 		break;


-- 
Simon Arlott

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Thu, 19 Jul 2007, Simon Arlott wrote:

> On 19/07/07 17:19, Robert P. J. Day wrote:
> > On Thu, 19 Jul 2007, Randy Dunlap wrote:
> >> I think that Stefan means a patch to the kconfig source code,
> >> not the the Kconfig files.  Good luck.  I'd still like to see it.
> >
> > yes, i understand what he wanted now.  as a first step (that
> > theoretically shouldn't change any behaviour), i'd patch the Kconfig
> > structure to add a new attribute ("maturity") which would be allowed
> > to be set to *exactly one* of a pre-defined set of values (say,
> > OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING).  and that's
> > it, nothing more.
> >
> > don't try to do anything with any of that just yet, just add the
> > infrastructure to support the (optional) association of a maturity
> > level with a config option.  that's step one.
>
> What about something like this? I'm not sure if the addition to sym_init
> is desirable... I also had to prefix _ to the name for now otherwise it
> conflicts badly with the current symbols. It probably should stop
> "depends on _BROKEN" etc. too.
>
> ---
> diff --git a/init/Kconfig b/init/Kconfig
> diff --git a/net/Kconfig b/net/Kconfig
> index cdba08c..5e2f4db 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -6,6 +6,7 @@ menu "Networking"
>
>  config NET
>  	bool "Networking support"
> +	maturity _BROKEN

just as a bit of a digression, "BROKEN" is not what i would call a
maturity level, and i would explicitly *not* allow that as a possible
maturity because that just makes a mess of the design.

i specifically wanted to define a maturity level so that any feature
could be categorized as belonging to *at most* one maturity level.
that is, you can't be both EXPERIMENTAL and DEPRECATED at the same
time -- that just makes no sense.

once you tag some features with a maturity level, then part of the
build would involve selecting which subset of maturity levels you
wanted to see.  by default, you'd get to see those features that
weren't tagged at all, but you might also make a selection like this:

  [*] EXPERIMENTAL
  [*] DEPRECATED
  [ ] OBSOLETE

in other words, you wanted the choice of stuff in the first two
categories, but not the third.  (you would, of course, always get to
choose from non-tagged stuff, which would be your *normal* content,
exactly as it is now).

so what about BROKEN?  i would invent a whole new attribute for that,
called maybe "status":

config FUBAR
	depends on ...
	maturity DEPRECATED
	status BROKEN
	...

"status" is a totally orthogonal attribute to maturity.  status might
be one of BROKEN, BROKEN_ON_SMP, FLAKEY_AS HELL, etc.  and, once
again, any feature can fall into *at most* one status category.  once
you have the infrastructure to support a single attribute like
maturity, you get any additional ones for free.  and rather than
defining all those things as simple dependencies, by creating new
objects called "attributes", you can play all sorts of interesting new
games, and the attribute infrastructure can enforce that you're using
it properly.

now i'll go away and read the rest of your post.  :-)

rday

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

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Fri, 31 Aug 2007, Randy Dunlap wrote:

> On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:
>
> > On 19/07/07 17:19, Robert P. J. Day wrote:
> > > On Thu, 19 Jul 2007, Randy Dunlap wrote:
> > >> I think that Stefan means a patch to the kconfig source code,
> > >> not the the Kconfig files.  Good luck.  I'd still like to see it.
> > >
> > > yes, i understand what he wanted now.  as a first step (that
> > > theoretically shouldn't change any behaviour), i'd patch the Kconfig
> > > structure to add a new attribute ("maturity") which would be allowed
> > > to be set to *exactly one* of a pre-defined set of values (say,
> > > OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING).  and that's
> > > it, nothing more.
> > >
> > > don't try to do anything with any of that just yet, just add the
> > > infrastructure to support the (optional) association of a maturity
> > > level with a config option.  that's step one.
> >
> > What about something like this? I'm not sure if the addition to sym_init
> > is desirable... I also had to prefix _ to the name for now otherwise it
> > conflicts badly with the current symbols. It probably should stop
> > "depends on _BROKEN" etc. too.

i'm sure i'm going to get shouted down here, but i really disagree
with "BROKEN" being considered a "maturity level".  IMHO, things like
EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for
what i think are obvious reasons.

something like BROKEN, though, has *nothing* to do with maturity.  a
feature can be any of those maturity levels, and simultaneously be
BROKEN.  i consider BROKEN to be what i call a "status", and different
status levels might be the default of normal, or KIND_OF_FLAKY or
TOTALLY_BORKED -- that's where BROKEN would fit in.

*please* don't start mixing these different attributes.  it's just
going to make an irreversible mess of things.  leave BROKEN out of
this for the time being.

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

http://crashcourse.ca
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Randy Dunlap]

On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:

> On 19/07/07 17:19, Robert P. J. Day wrote:
> > On Thu, 19 Jul 2007, Randy Dunlap wrote:
> >> I think that Stefan means a patch to the kconfig source code,
> >> not the the Kconfig files.  Good luck.  I'd still like to see it.
> > 
> > yes, i understand what he wanted now.  as a first step (that
> > theoretically shouldn't change any behaviour), i'd patch the Kconfig
> > structure to add a new attribute ("maturity") which would be allowed
> > to be set to *exactly one* of a pre-defined set of values (say,
> > OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING).  and that's
> > it, nothing more.
> > 
> > don't try to do anything with any of that just yet, just add the
> > infrastructure to support the (optional) association of a maturity
> > level with a config option.  that's step one.
> 
> What about something like this? I'm not sure if the addition to sym_init
> is desirable... I also had to prefix _ to the name for now otherwise it
> conflicts badly with the current symbols. It probably should stop
> "depends on _BROKEN" etc. too.

Hi Simon,

(sorry for the delay)

I like this patch very much... I just can't get it to build (on
2.6.23-rc4).

Thanks.

> ---
> diff --git a/init/Kconfig b/init/Kconfig
> diff --git a/net/Kconfig b/net/Kconfig
> index cdba08c..5e2f4db 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -6,6 +6,7 @@ menu "Networking"
> 
>  config NET
>  	bool "Networking support"
> +	maturity _BROKEN
>  	---help---
>  	  Unless you really know what you are doing, you should say Y here.
>  	  The reason is that some programs need kernel networking support even
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index fb2bb30..1dea08e 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -256,7 +256,7 @@ $(obj)/lkc_defs.h: $(src)/lkc_proto.h
>  # The following requires flex/bison/gperf
>  # By default we use the _shipped versions, uncomment the following line if
>  # you are modifying the flex/bison src.
> -# LKC_GENPARSER := 1
> +LKC_GENPARSER := 1
> 
>  ifdef LKC_GENPARSER
> 
> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> index 1199baf..cc9be0e 100644
> --- a/scripts/kconfig/conf.c
> +++ b/scripts/kconfig/conf.c
> @@ -211,6 +211,22 @@ static int conf_sym(struct menu *menu)
> 
>  	while (1) {
>  		printf("%*s%s ", indent - 1, "", menu->prompt->text);
> +		switch (sym->maturity) {
> +		case M_EXPERIMENTAL:
> +			printf("(EXPERIMENTAL) ");
> +			break;
> +		case M_DEPRECATED:
> +			printf("(DEPRECATED) ");
> +			break;
> +		case M_OBSOLETE:
> +			printf("(OBSOLETE) ");
> +			break;
> +		case M_BROKEN:
> +			printf("(BROKEN) ");
> +			break;
> +		default:
> +			break;
> +		}
>  		if (sym->name)
>  			printf("(%s) ", sym->name);
>  		type = sym_get_type(sym);
> diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
> index 6084525..a22b6c1 100644
> --- a/scripts/kconfig/expr.h
> +++ b/scripts/kconfig/expr.h
> @@ -60,7 +60,11 @@ struct symbol_value {
>  };
> 
>  enum symbol_type {
> -	S_UNKNOWN, S_BOOLEAN, S_TRISTATE, S_INT, S_HEX, S_STRING, S_OTHER
> +	S_UNKNOWN, S_BOOLEAN, S_TRISTATE, S_INT, S_HEX, S_STRING, S_MATURITY,
> S_OTHER
> +};
> +
> +enum maturity_level {
> +	M_NONE, M_EXPERIMENTAL, M_DEPRECATED, M_OBSOLETE, M_BROKEN
>  };
> 
>  enum {
> @@ -72,6 +76,7 @@ struct symbol {
>  	struct symbol *next;
>  	char *name;
>  	char *help;
> +	enum maturity_level maturity;
>  	enum symbol_type type;
>  	struct symbol_value curr;
>  	struct symbol_value def[4];
> diff --git a/scripts/kconfig/lex.zconf.c_shipped
> b/scripts/kconfig/lex.zconf.c_shipped
> diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
> index 8a07ee4..9add1cd 100644
> --- a/scripts/kconfig/lkc.h
> +++ b/scripts/kconfig/lkc.h
> @@ -79,6 +79,7 @@ void menu_end_menu(void);
>  void menu_add_entry(struct symbol *sym);
>  void menu_end_entry(void);
>  void menu_add_dep(struct expr *dep);
> +void menu_set_maturity(struct symbol *sym);
>  struct property *menu_add_prop(enum prop_type type, char *prompt,
> struct expr *expr, struct expr *dep);
>  struct property *menu_add_prompt(enum prop_type type, char *prompt,
> struct expr *dep);
>  void menu_add_expr(enum prop_type type, struct expr *expr, struct expr
> *dep);
> diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
> index d0e4fa5..eaf199b 100644
> --- a/scripts/kconfig/mconf.c
> +++ b/scripts/kconfig/mconf.c
> @@ -238,6 +238,7 @@ search_help[] = N_(
>  	"Result:\n"
>  	"-----------------------------------------------------------------\n"
>  	"Symbol: FOO [=m]\n"
> +	"Maturity: FOO\n"
>  	"Prompt: Foo bus is used to drive the bar HW\n"
>  	"Defined at drivers/pci/Kconfig:47\n"
>  	"Depends on: X86_LOCAL_APIC && X86_IO_APIC || IA64\n"
> @@ -359,6 +360,27 @@ static void get_symbol_str(struct gstr *r, struct
> symbol *sym)
> 
>  	str_printf(r, "Symbol: %s [=%s]\n", sym->name,
>  	                               sym_get_string_value(sym));
> +
> +	if (sym->maturity != M_NONE) {
> +		str_append(r, "Maturity: ");
> +		switch (sym->maturity) {
> +		case M_EXPERIMENTAL:
> +			str_append(r, "EXPERIMENTAL\n");
> +			break;
> +		case M_DEPRECATED:
> +			str_append(r, "DEPRECATED\n");
> +			break;
> +		case M_OBSOLETE:
> +			str_append(r, "OBSOLETE\n");
> +			break;
> +		case M_BROKEN:
> +			str_append(r, "BROKEN\n");
> +			break;
> +		default:
> +			break;
> +		}
> +	}
> +
>  	for_all_prompts(sym, prop)
>  		get_prompt_str(r, prop);
>  	hit = false;
> diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
> index f14aeac..3e37e5b 100644
> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
> @@ -104,6 +104,15 @@ void menu_add_dep(struct expr *dep)
>  	current_entry->dep = expr_alloc_and(current_entry->dep,
> menu_check_dep(dep));
>  }
> 
> +void menu_set_maturity(struct symbol *sym)
> +{
> +	if (sym->type != S_MATURITY) {
> +		zconf_error("'%s' is an invalid maturity level", sym->name);
> +	} else {
> +		current_entry->sym->maturity = sym->maturity;
> +	}
> +}
> +
>  void menu_set_type(int type)
>  {
>  	struct symbol *sym = current_entry->sym;
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index c35dcc5..280ee8f 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -72,6 +72,22 @@ void sym_init(void)
>  	sym->type = S_STRING;
>  	sym->flags |= SYMBOL_AUTO;
>  	sym_add_default(sym, uts.release);
> +
> +	sym = sym_lookup("_EXPERIMENTAL", 0);
> +	sym->type = S_MATURITY;
> +	sym->maturity = M_EXPERIMENTAL;
> +
> +	sym = sym_lookup("_DEPRECATED", 0);
> +	sym->type = S_MATURITY;
> +	sym->maturity = M_DEPRECATED;
> +
> +	sym = sym_lookup("_OBSOLETE", 0);
> +	sym->type = S_MATURITY;
> +	sym->maturity = M_OBSOLETE;
> +
> +	sym = sym_lookup("_BROKEN", 0);
> +	sym->type = S_MATURITY;
> +	sym->maturity = M_BROKEN;
>  }
> 
>  enum symbol_type sym_get_type(struct symbol *sym)
> @@ -100,6 +116,8 @@ const char *sym_type_name(enum symbol_type type)
>  		return "hex";
>  	case S_STRING:
>  		return "string";
> +	case S_MATURITY:
> +		return "maturity";
>  	case S_UNKNOWN:
>  		return "unknown";
>  	case S_OTHER:
> @@ -679,6 +697,7 @@ struct symbol *sym_lookup(const char *name, int isconst)
>  	memset(symbol, 0, sizeof(*symbol));
>  	symbol->name = new_name;
>  	symbol->type = S_UNKNOWN;
> +	symbol->maturity = M_NONE;
>  	if (isconst)
>  		symbol->flags |= SYMBOL_CONST;
> 
> diff --git a/scripts/kconfig/zconf.gperf b/scripts/kconfig/zconf.gperf
> index 9b44c80..756d559 100644
> --- a/scripts/kconfig/zconf.gperf
> +++ b/scripts/kconfig/zconf.gperf
> @@ -25,6 +25,7 @@ endif,		T_ENDIF,	TF_COMMAND
>  depends,	T_DEPENDS,	TF_COMMAND
>  requires,	T_REQUIRES,	TF_COMMAND
>  optional,	T_OPTIONAL,	TF_COMMAND
> +maturity,	T_MATURITY,	TF_COMMAND
>  default,	T_DEFAULT,	TF_COMMAND, S_UNKNOWN
>  prompt,		T_PROMPT,	TF_COMMAND
>  tristate,	T_TYPE,		TF_COMMAND, S_TRISTATE
> diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
> index 92eb02b..1b47966 100644
> --- a/scripts/kconfig/zconf.y
> +++ b/scripts/kconfig/zconf.y
> @@ -66,6 +66,7 @@ static struct menu *current_menu, *current_entry;
>  %token <id>T_DEPENDS
>  %token <id>T_REQUIRES
>  %token <id>T_OPTIONAL
> +%token <id>T_MATURITY
>  %token <id>T_PROMPT
>  %token <id>T_TYPE
>  %token <id>T_DEFAULT
> @@ -120,7 +121,7 @@ stmt_list:
>  ;
> 
>  option_name:
> -	T_DEPENDS | T_PROMPT | T_TYPE | T_SELECT | T_OPTIONAL | T_RANGE |
> T_DEFAULT
> +	T_DEPENDS | T_MATURITY | T_PROMPT | T_TYPE | T_SELECT | T_OPTIONAL |
> T_RANGE | T_DEFAULT
>  ;
> 
>  common_stmt:
> @@ -177,6 +178,7 @@ config_option_list:
>  	| config_option_list config_option
>  	| config_option_list symbol_option
>  	| config_option_list depends
> +	| config_option_list maturity
>  	| config_option_list help
>  	| config_option_list option_error
>  	| config_option_list T_EOL
> @@ -269,6 +271,7 @@ choice_option_list:
>  	  /* empty */
>  	| choice_option_list choice_option
>  	| choice_option_list depends
> +	| choice_option_list maturity
>  	| choice_option_list help
>  	| choice_option_list T_EOL
>  	| choice_option_list option_error
> @@ -349,7 +352,7 @@ menu: T_MENU prompt T_EOL
>  	printd(DEBUG_PARSE, "%s:%d:menu\n", zconf_curname(), zconf_lineno());
>  };
> 
> -menu_entry: menu depends_list
> +menu_entry: menu maturity_set_opt depends_list
>  {
>  	$$ = menu_add_menu();
>  };
> @@ -430,6 +433,19 @@ depends: T_DEPENDS T_ON expr T_EOL
>  	printd(DEBUG_PARSE, "%s:%d:requires\n", zconf_curname(), zconf_lineno());
>  };
> 
> +/* maturity setting */
> +
> +maturity_set_opt:
> +	  /* empty */
> +	| maturity
> +;
> +
> +maturity: T_MATURITY symbol T_EOL
> +{
> +	menu_set_maturity($2);
> +	printd(DEBUG_PARSE, "%s:%d:maturity\n", zconf_curname(), zconf_lineno());
> +};
> +
>  /* prompt statement */
> 
>  prompt_stmt_opt:
> @@ -519,6 +535,7 @@ const char *zconf_tokenname(int token)
>  	case T_IF:		return "if";
>  	case T_ENDIF:		return "endif";
>  	case T_DEPENDS:		return "depends";
> +	case T_MATURITY:	return "maturity";
>  	}
>  	return "<token>";
>  }
> @@ -615,6 +632,9 @@ void print_symbol(FILE *out, struct menu *menu)
>  	case S_HEX:
>  		fputs("  hex\n", out);
>  		break;
> +	case S_MATURITY:
> +		fputs("  maturity\n", out);
> +		break;
>  	default:
>  		fputs("  ???\n", out);
>  		break;
> 
> 
> -- 

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Jeff Garzik]

Robert P. J. Day wrote:
> On Fri, 31 Aug 2007, Randy Dunlap wrote:
> 
>> On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:
>>
>>> On 19/07/07 17:19, Robert P. J. Day wrote:
>>>> On Thu, 19 Jul 2007, Randy Dunlap wrote:
>>>>> I think that Stefan means a patch to the kconfig source code,
>>>>> not the the Kconfig files.  Good luck.  I'd still like to see it.
>>>> yes, i understand what he wanted now.  as a first step (that
>>>> theoretically shouldn't change any behaviour), i'd patch the Kconfig
>>>> structure to add a new attribute ("maturity") which would be allowed
>>>> to be set to *exactly one* of a pre-defined set of values (say,
>>>> OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING).  and that's
>>>> it, nothing more.
>>>>
>>>> don't try to do anything with any of that just yet, just add the
>>>> infrastructure to support the (optional) association of a maturity
>>>> level with a config option.  that's step one.
>>> What about something like this? I'm not sure if the addition to sym_init
>>> is desirable... I also had to prefix _ to the name for now otherwise it
>>> conflicts badly with the current symbols. It probably should stop
>>> "depends on _BROKEN" etc. too.
> 
> i'm sure i'm going to get shouted down here, but i really disagree
> with "BROKEN" being considered a "maturity level".  IMHO, things like
> EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for
> what i think are obvious reasons.
> 
> something like BROKEN, though, has *nothing* to do with maturity.  a
> feature can be any of those maturity levels, and simultaneously be
> BROKEN.  i consider BROKEN to be what i call a "status", and different
> status levels might be the default of normal, or KIND_OF_FLAKY or
> TOTALLY_BORKED -- that's where BROKEN would fit in.

BROKEN is definitely a maturity level.  A more accurate description 
would be BITROTTING perhaps.  The code in question has passed through 
bleeding -> experimental -> stable, and come out the other side.

In contrast, OBSOLETE and DEPRECATED reflect high-level status not code 
quality/maturity.

	Jeff

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Jan Engelhardt]

On Aug 31 2007 14:06, Jeff Garzik wrote:
>> something like BROKEN, though, has *nothing* to do with maturity.  a
>> feature can be any of those maturity levels, and simultaneously be
>> BROKEN.  i consider BROKEN to be what i call a "status", and different
>> status levels might be the default of normal, or KIND_OF_FLAKY or
>> TOTALLY_BORKED -- that's where BROKEN would fit in.
>
> BROKEN is definitely a maturity level.  A more accurate description would be
> BITROTTING perhaps.  The code in question has passed through bleeding ->
> experimental -> stable, and come out the other side.

Software is quite unlike the art of medicine. There, you would go from
'stable' to 'broken', then someone 'experiments' with you, and if
it's a bad day, you bleed out. :)


	Jan
-- 

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Randy Dunlap]

On Fri, 31 Aug 2007 14:06:33 -0400 Jeff Garzik wrote:

> Robert P. J. Day wrote:
> > On Fri, 31 Aug 2007, Randy Dunlap wrote:
> > 
> >> On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:
> >>
> >>> On 19/07/07 17:19, Robert P. J. Day wrote:
> >>>> On Thu, 19 Jul 2007, Randy Dunlap wrote:
> >>>>> I think that Stefan means a patch to the kconfig source code,
> >>>>> not the the Kconfig files.  Good luck.  I'd still like to see it.
> >>>> yes, i understand what he wanted now.  as a first step (that
> >>>> theoretically shouldn't change any behaviour), i'd patch the Kconfig
> >>>> structure to add a new attribute ("maturity") which would be allowed
> >>>> to be set to *exactly one* of a pre-defined set of values (say,
> >>>> OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING).  and that's
> >>>> it, nothing more.
> >>>>
> >>>> don't try to do anything with any of that just yet, just add the
> >>>> infrastructure to support the (optional) association of a maturity
> >>>> level with a config option.  that's step one.
> >>> What about something like this? I'm not sure if the addition to sym_init
> >>> is desirable... I also had to prefix _ to the name for now otherwise it
> >>> conflicts badly with the current symbols. It probably should stop
> >>> "depends on _BROKEN" etc. too.
> > 
> > i'm sure i'm going to get shouted down here, but i really disagree
> > with "BROKEN" being considered a "maturity level".  IMHO, things like
> > EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for
> > what i think are obvious reasons.
> > 
> > something like BROKEN, though, has *nothing* to do with maturity.  a
> > feature can be any of those maturity levels, and simultaneously be
> > BROKEN.  i consider BROKEN to be what i call a "status", and different
> > status levels might be the default of normal, or KIND_OF_FLAKY or
> > TOTALLY_BORKED -- that's where BROKEN would fit in.
> 
> BROKEN is definitely a maturity level.  A more accurate description 
> would be BITROTTING perhaps.  The code in question has passed through 
> bleeding -> experimental -> stable, and come out the other side.
> 
> In contrast, OBSOLETE and DEPRECATED reflect high-level status not code 
> quality/maturity.

What I like about the patch is that it associates some kconfig symbol
with prompt strings, so that we don't have to edit "(EXPERIMENTAL)"
all the darn time (e.g.).

I'd be quite happy with calling it "status" rather than "maturity",
and with being able to use multiple of the status tags at one time,
such as

	config FOO
	depends on BAR
	status OBSOLETE BROKEN


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Fri, 31 Aug 2007, Jeff Garzik wrote:

> Robert P. J. Day wrote:

> > i'm sure i'm going to get shouted down here, but i really disagree
> > with "BROKEN" being considered a "maturity level".  IMHO, things
> > like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity
> > levels, for what i think are obvious reasons.
> >
> > something like BROKEN, though, has *nothing* to do with maturity.
> > a feature can be any of those maturity levels, and simultaneously
> > be BROKEN.  i consider BROKEN to be what i call a "status", and
> > different status levels might be the default of normal, or
> > KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit
> > in.
>
> BROKEN is definitely a maturity level.

no.  it's not.  end of discussion.  you're wrong.

the concept of "maturity level" reflects where in the life cycle some
feature is.  it will typically start as "bleeding edge" or
"experimental" or something like that, eventually stabilize to be
normal (which would be the obvious default), after which, when its
value starts to run out and it begins showing its age, it becomes
"deprecated" and eventually "obsolete"  it's a natural and obvious
progression.

on the other hand, a feature can be "broken" at *any* point in that
life cycle -- that's why it is absolutely *not* a maturity level.
please don't fight with me on this, jeff.  you're simply wrong.

> In contrast, OBSOLETE and DEPRECATED reflect high-level status not
> code quality/maturity.

you have this so backwards, i can't begin to think how to explain it
to you.

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

http://crashcourse.ca
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Fri, 31 Aug 2007, Randy Dunlap wrote:

> What I like about the patch is that it associates some kconfig
> symbol with prompt strings, so that we don't have to edit
> "(EXPERIMENTAL)" all the darn time (e.g.).
>
> I'd be quite happy with calling it "status" rather than "maturity",
> and with being able to use multiple of the status tags at one time,
> such as
>
> 	config FOO
> 	depends on BAR
> 	status OBSOLETE BROKEN

grrrrrrrr ... i already made my point in my earlier post.  i'd
really, really like it if *this* attribute remained as "maturity".  an
entirely *separate* attribute could be defined as a feature "status",
which would be entirely orthogonal to maturity level, so that the
above would be written as

	maturity OBSOLETE
	status BROKEN

there's a reason for this -- any feature should have exactly *one*
value for any attribute.  that is, in terms of maturity, a feature
could be EXPERIMENTAL *or* DEPRECATED *or* OBSOLETE.  it ***can't***
be more than one, as in both DEPRECATED *and* OBSOLETE.  to allow that
flexibility is to descend into absurdity.

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

http://crashcourse.ca
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Randy Dunlap]

On Fri, 31 Aug 2007 17:00:57 -0400 (EDT) Robert P. J. Day wrote:

> On Fri, 31 Aug 2007, Randy Dunlap wrote:
> 
> > What I like about the patch is that it associates some kconfig
> > symbol with prompt strings, so that we don't have to edit
> > "(EXPERIMENTAL)" all the darn time (e.g.).
> >
> > I'd be quite happy with calling it "status" rather than "maturity",
> > and with being able to use multiple of the status tags at one time,
> > such as
> >
> > 	config FOO
> > 	depends on BAR
> > 	status OBSOLETE BROKEN
> 
> grrrrrrrr ... i already made my point in my earlier post.  i'd
> really, really like it if *this* attribute remained as "maturity".  an
> entirely *separate* attribute could be defined as a feature "status",
> which would be entirely orthogonal to maturity level, so that the
> above would be written as
> 
> 	maturity OBSOLETE
> 	status BROKEN
> 
> there's a reason for this -- any feature should have exactly *one*
> value for any attribute.  that is, in terms of maturity, a feature
> could be EXPERIMENTAL *or* DEPRECATED *or* OBSOLETE.  it ***can't***
> be more than one, as in both DEPRECATED *and* OBSOLETE.  to allow that
> flexibility is to descend into absurdity.


If Simon (or anyone else) continues to work on it, I'll leave this
decision up to them...


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Jeff Garzik]

Robert P. J. Day wrote:
> On Fri, 31 Aug 2007, Jeff Garzik wrote:
> 
>> Robert P. J. Day wrote:
> 
>>> i'm sure i'm going to get shouted down here, but i really disagree
>>> with "BROKEN" being considered a "maturity level".  IMHO, things
>>> like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity
>>> levels, for what i think are obvious reasons.
>>>
>>> something like BROKEN, though, has *nothing* to do with maturity.
>>> a feature can be any of those maturity levels, and simultaneously
>>> be BROKEN.  i consider BROKEN to be what i call a "status", and
>>> different status levels might be the default of normal, or
>>> KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit
>>> in.
>> BROKEN is definitely a maturity level.
> 
> no.  it's not.  end of discussion.  you're wrong.
> 
> the concept of "maturity level" reflects where in the life cycle some
> feature is.  it will typically start as "bleeding edge" or
> "experimental" or something like that, eventually stabilize to be
> normal (which would be the obvious default), after which, when its
> value starts to run out and it begins showing its age, it becomes
> "deprecated" and eventually "obsolete"  it's a natural and obvious
> progression.
> 
> on the other hand, a feature can be "broken" at *any* point in that
> life cycle -- that's why it is absolutely *not* a maturity level.
> please don't fight with me on this, jeff.  you're simply wrong.

Get off your high horse and actually look at the patches that mark 
things BROKEN.

'deprecrated' and 'obsolete' are matters of discussed opinion, 
describing the utility of the code in question.  'broken' describes the 
state of the code itself.

Clear difference.

	Jeff, one who actually marks this stuff as such

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Fri, 31 Aug 2007, Jeff Garzik wrote:

> 'deprecrated' and 'obsolete' are matters of discussed opinion,
> describing the utility of the code in question.  'broken' describes
> the state of the code itself.
>
> Clear difference.

precisely.  thank you for making my point for me.

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

http://crashcourse.ca
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Fri, 31 Aug 2007, Randy Dunlap wrote:

> On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:

> > What about something like this? I'm not sure if the addition to
> > sym_init is desirable... I also had to prefix _ to the name for
> > now otherwise it conflicts badly with the current symbols. It
> > probably should stop "depends on _BROKEN" etc. too.
>
> Hi Simon,
>
> (sorry for the delay)
>
> I like this patch very much... I just can't get it to build (on
> 2.6.23-rc4).

i got a patch from simon a while back, and it failed with
"shift/reduce" conflicts.  is that what you're seeing?

> >  	while (1) {
> >  		printf("%*s%s ", indent - 1, "", menu->prompt->text);
> > +		switch (sym->maturity) {
> > +		case M_EXPERIMENTAL:
> > +			printf("(EXPERIMENTAL) ");
> > +			break;
> > +		case M_DEPRECATED:
> > +			printf("(DEPRECATED) ");
> > +			break;
> > +		case M_OBSOLETE:
> > +			printf("(OBSOLETE) ");
> > +			break;
> > +		case M_BROKEN:
> > +			printf("(BROKEN) ");
> > +			break;
> > +		default:
> > +			break;
> > +		}
> >  		if (sym->name)
> >  			printf("(%s) ", sym->name);
> >  		type = sym_get_type(sym);

for now, simon, why not just reduce this to supporting only DEPRECATED
and OBSOLETE so that it can be at least tested as "proof of concept?"

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

http://crashcourse.ca
========================================================================

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Sam Ravnborg]

On Sat, Sep 01, 2007 at 06:44:06AM -0400, Robert P. J. Day wrote:
> 
> > >  	while (1) {
> > >  		printf("%*s%s ", indent - 1, "", menu->prompt->text);
> > > +		switch (sym->maturity) {
> > > +		case M_EXPERIMENTAL:
> > > +			printf("(EXPERIMENTAL) ");
> > > +			break;
> > > +		case M_DEPRECATED:
> > > +			printf("(DEPRECATED) ");
> > > +			break;
> > > +		case M_OBSOLETE:
> > > +			printf("(OBSOLETE) ");
> > > +			break;
> > > +		case M_BROKEN:
> > > +			printf("(BROKEN) ");
> > > +			break;
> > > +		default:
> > > +			break;
> > > +		}
> > >  		if (sym->name)
> > >  			printf("(%s) ", sym->name);
> > >  		type = sym_get_type(sym);
> 
> for now, simon, why not just reduce this to supporting only DEPRECATED
> and OBSOLETE so that it can be at least tested as "proof of concept?"

The principle with letting a dependency add text to the promts are good.
But the implementation done by Simon with a language extension is not good.
A simple and better approach would be to use the newly added option
support for this and let the backend generate the promtps.

I have not yet tried to cook up a patch for it, but it should be
quite generaic and doable.

config EXPERIMENTAL
	option appendprompt=" (EXPERIMENTAL)

config DEPRECATED
	option appendprompt=" (DEPRECATED)

Then the dependency added will automatically append to the prompt.

It would probarly have be done in two steps. One that introduce a helper
function to retreive the prompt text and introduce it. And next a patch to
add a text if a symbol has a dependency on a symbol with a specific option
assigned.

	Sam

Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Robert P. J. Day]

On Sat, 1 Sep 2007, Sam Ravnborg wrote:

> On Sat, Sep 01, 2007 at 06:44:06AM -0400, Robert P. J. Day wrote:
> >
> > > >  	while (1) {
> > > >  		printf("%*s%s ", indent - 1, "", menu->prompt->text);
> > > > +		switch (sym->maturity) {
> > > > +		case M_EXPERIMENTAL:
> > > > +			printf("(EXPERIMENTAL) ");
> > > > +			break;
> > > > +		case M_DEPRECATED:
> > > > +			printf("(DEPRECATED) ");
> > > > +			break;
> > > > +		case M_OBSOLETE:
> > > > +			printf("(OBSOLETE) ");
> > > > +			break;
> > > > +		case M_BROKEN:
> > > > +			printf("(BROKEN) ");
> > > > +			break;
> > > > +		default:
> > > > +			break;
> > > > +		}
> > > >  		if (sym->name)
> > > >  			printf("(%s) ", sym->name);
> > > >  		type = sym_get_type(sym);
> >
> > for now, simon, why not just reduce this to supporting only DEPRECATED
> > and OBSOLETE so that it can be at least tested as "proof of concept?"
>
> The principle with letting a dependency add text to the promts are good.
> But the implementation done by Simon with a language extension is not good.
> A simple and better approach would be to use the newly added option
> support for this and let the backend generate the promtps.
>
> I have not yet tried to cook up a patch for it, but it should be
> quite generaic and doable.
>
> config EXPERIMENTAL
> 	option appendprompt=" (EXPERIMENTAL)
>
> config DEPRECATED
> 	option appendprompt=" (DEPRECATED)


but this is deviating from the basic principle that these things are
not regular Kconfig "config" settings -- they are a new beast
entirely, and need a new infrastructure to support them.

put another way, they are not a normal kernel feature to be selected
or deselected.  they are, rather, *attributes* that can be *applied*
to kernel features, in the same way as is done with "bool" or
"string".  making these things regular config directives defeats the
whole purpose.

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

http://crashcourse.ca
========================================================================