From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: David Lang <david.lang@digitalinsight.com>
Cc: andersen@codepoet.org, Roman Zippel <zippel@linux-m68k.org>,
linux-kernel@vger.kernel.org
Subject: Re: linux kernel config converter
Date: Thu, 21 Feb 2002 10:05:51 -0500 [thread overview]
Message-ID: <3C750CCF.989B1FDD@mandrakesoft.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0202210636020.8696-100000@dlang.diginsite.com>
David Lang wrote:
>
> On Thu, 21 Feb 2002, Jeff Garzik wrote:
>
> > David Lang wrote:
> > > 1. does this handle the cross directory dependancies?
> >
> > I presume you are talking about Roman's tool, so I'll let him answer. I
> > think he just implemented a converter to a new language, so new language
> > tools to parse the language don't exist yet, I think.
>
> I am so I'll wait for his answer
>
> > > 2. does it handle the 'I want this feature, turn on everything I need for
> > > it'?
> >
> > This is fundamentally impossible for anything beyond the most simple
> > features. Although you can do a lot with config.in info, "everything I
> > need" is something a human needs to define in many cases.
> >
>
> unless I am missing something this is one of the features that CML2
> implements. Agreed that 'everything I need' needs to be defined by a
> human, that's what Eric has done in his ruleset, define the dependancies.
Even within the constraints of CML1, you can do stuff like "I want
CONFIG_USB_HID, which implies that CONFIG_INPUT is needed"
That simple stuff. For anything beyond that, like "create me an
ipv6-netlink configuration with adequate support for 3rd party modules"
it's not gonna cut it, nor will any reasonable config system.
> > > 3. if it handles #2 what does it do if you turn off that feature again
> > > (CML2 turns off anything it turned on to support that feature, assuming
> > > nothing else needs it)
> >
> > This is a policy decision. I'm not sure one -wants- to do this...
> > Doing something like this blindly can have unintended side effects, i.e.
> > violate the Principle of Least Surprise.
>
> I'll argue that _not_ doing this violated the principle of lease surprise,
> if you turn a feature on and immediatly back off why should anything in
> your config be any different then it was before you turned it on?
It sounds like you want an implementation detail -- undo last [n]
choice[s].
Imagine this case:
make xconfig # select CONFIG_USB_HID, which auto-selects CONFIG_INPUT
{ time passes }
make xconfig # de-select CONFIG_USB_HID
On the second 'make xconfig', should CONFIG_INPUT be automatically
de-selected? No. Because that is making the assumption that the person
does not want to continue to make the input API available.
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
next prev parent reply other threads:[~2002-02-21 15:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-21 10:48 linux kernel config converter Roman Zippel
2002-02-21 11:40 ` Jeff Garzik
2002-02-21 12:21 ` Roman Zippel
2002-02-21 12:32 ` Jeff Garzik
2002-02-21 12:54 ` Erik Andersen
2002-02-21 13:21 ` Jeff Garzik
2002-02-21 14:28 ` David Lang
2002-02-21 14:36 ` Jeff Garzik
2002-02-21 14:40 ` David Lang
2002-02-21 15:05 ` Jeff Garzik [this message]
2002-02-21 15:41 ` Jason Lunz
2002-02-21 15:54 ` Jeff Garzik
2002-02-21 15:18 ` Alan Cox
2002-02-21 15:08 ` Jeff Garzik
2002-02-21 15:22 ` Gerd Knorr
2002-02-21 15:33 ` Roman Zippel
2002-02-21 18:53 ` Andreas Dilger
[not found] <fa.gq2s5iv.1s4in@ifi.uio.no>
2002-02-21 13:28 ` Giacomo Catenazzi
2002-02-21 14:11 ` Roman Zippel
2002-02-21 14:32 ` Giacomo Catenazzi
2002-02-21 15:19 ` Roman Zippel
[not found] <fa.fsgrt4v.1bngh9t@ifi.uio.no>
[not found] ` <fa.hp69onv.i7qtq3@ifi.uio.no>
2002-02-21 14:06 ` Giacomo Catenazzi
2002-02-21 14:26 ` Jeff Garzik
2002-02-21 14:39 ` Giacomo Catenazzi
2002-02-21 15:11 ` Jeff Garzik
2002-02-21 16:00 ` Randy.Dunlap
[not found] ` <fa.lqt3hav.190o1i9@ifi.uio.no>
2002-02-21 14:50 ` Giacomo Catenazzi
2002-02-21 14:56 ` David Lang
2002-02-21 15:05 ` Giacomo Catenazzi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C750CCF.989B1FDD@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=andersen@codepoet.org \
--cc=david.lang@digitalinsight.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.