[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0709010853040.6031@localhost.localdomain>
Date: Sat, 1 Sep 2007 08:56:30 -0400 (EDT)
From: "Robert P. J. Day" <rpjday@...dspring.com>
To: Sam Ravnborg <sam@...nborg.org>
cc: Randy Dunlap <rdunlap@...otime.net>,
Simon Arlott <simon@...e.lp0.eu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Stefan Richter <stefanr@...6.in-berlin.de>,
Adrian Bunk <bunk@...sta.de>, Jeff Garzik <jeff@...zik.org>,
Gabriel C <crazy@...pmylinux.org>, netdev@...r.kernel.org
Subject: Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
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
========================================================================
-
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