public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: esr@thyrsus.com
Cc: alan@lxorguk.ukuu.org.uk (Alan Cox),
	kaos@ocs.com.au (Keith Owens),
	linux-kernel@vger.kernel.org (CML2),
	kbuild-devel@lists.sourceforge.net
Subject: Re: [kbuild-devel] Why recovering from broken configs is too hard
Date: Thu, 3 May 2001 19:41:33 +0100 (BST)	[thread overview]
Message-ID: <E14vO2i-00060Y-00@the-village.bc.nu> (raw)
In-Reply-To: <20010503143037.A1822@thyrsus.com> from "Eric S. Raymond" at May 03, 2001 02:30:37 PM

> You want brutality and heuristics?  I'll give you brutality and heuristics...
> I could just treat a config as a sequence of assignments, as though
> the user had typed them in sequence, rejecting any later ones that
> throw constraint violations.  That way we can avoid ever accepting or
> having to deal with an invalid configuration.  The invariant that every
> symbol assignment either augments a valid configuration or is rejected
> would be conserved.

Which is pretty much what make oldconfig does. Go from the top asking users
about new symbols and just killing stuff that would break the rules.

> This isn't "recovery", it's more like high-handedly throwing away
> assignments that don't happen to fit stuff bound earlier in the tree
> traverse that defines symbol print order.  And it's going to give odd,
> "brutal" results in some cases because guard symbols are ordered
> before their dependents.

Thats the mathematician speaking again

> But if all you want is brutality and heuristics, it might do.

Its worked well enough for the past five years. On odd occasions you do find
you've inadventantly unconfigured something but normally the conflict vanishes
with almost no ripples.

I'm quite happy for oldconfig to continue to do what it did before. I'm quite
happy to accept its mathematically imperfect, because it hasnt gone far wrong
yet

Alan


  reply	other threads:[~2001-05-03 18:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-03  7:47 Why recovering from broken configs is too hard Eric S. Raymond
2001-05-03  8:03 ` Jeff Garzik
2001-05-03  8:09   ` Eric S. Raymond
2001-05-03  8:29 ` Alexander Viro
2001-05-03  8:42 ` [kbuild-devel] " Greg Banks
2001-05-03  8:52   ` Eric S. Raymond
2001-05-03  8:45 ` Ingo Oeser
2001-05-03  9:14   ` Alexander Viro
2001-05-03  9:43     ` Eric S. Raymond
2001-05-03  9:56       ` Alan Cox
2001-05-03 10:00       ` Alexander Viro
2001-05-03 15:55         ` Eric S. Raymond
2001-05-03 18:36           ` Alexander Viro
2001-05-03 14:54       ` David Mansfield
2001-05-03 15:58         ` Eric S. Raymond
2001-05-03 18:13           ` John Stoffel
2001-05-03  9:32   ` Eric S. Raymond
2001-05-03 10:15 ` [kbuild-devel] " Keith Owens
2001-05-03 16:59   ` Eric S. Raymond
2001-05-03 17:48     ` Alan Cox
2001-05-03 18:30       ` Eric S. Raymond
2001-05-03 18:41         ` Alan Cox [this message]
2001-05-03 19:03           ` Device driver from kernel2.2.x to kernel2.4 jalaja devi
2001-05-04  1:39             ` Andrew Morton
2001-05-03 22:58     ` [kbuild-devel] Why recovering from broken configs is too hard Keith Owens
2001-05-03 19:20 ` Michal Jaegermann
2001-05-03 23:58 ` Albert D. Cahalan
2001-05-03 22:55   ` David Lang
2001-05-04  7:47   ` [kbuild-devel] " Eric S. Raymond
  -- strict thread matches above, loose matches on Subject: below --
2001-05-03 19:30 [kbuild-devel] " Wayne.Brown

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=E14vO2i-00060Y-00@the-village.bc.nu \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=esr@thyrsus.com \
    --cc=kaos@ocs.com.au \
    --cc=kbuild-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox