public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Mansfield <lkml@dm.ultramaster.com>
To: esr@thyrsus.com
Cc: Alexander Viro <viro@math.psu.edu>,
	Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>,
	CML2 <linux-kernel@vger.kernel.org>,
	kbuild-devel@lists.sourceforge.net
Subject: Re: Why recovering from broken configs is too hard
Date: Thu, 03 May 2001 10:54:45 -0400	[thread overview]
Message-ID: <3AF17135.F52C889D@dm.ultramaster.com> (raw)
In-Reply-To: <20010503104511.C754@nightmaster.csn.tu-chemnitz.de> <Pine.GSO.4.21.0105030452310.15957-100000@weyl.math.psu.edu> <20010503054349.C28728@thyrsus.com>

"Eric S. Raymond" wrote:
> 
> Alexander Viro <viro@math.psu.edu>:
> > Assertion: you can split the set of variables into disjoint union of
> > small subsets X, Y_1,...,Y_m such that each constraint is concerned
> > only with variables from X and at most one of Y_i.
> >
> > IOW, there is a small "core" and for fixed values of core variables
> > constraints fall into groups, each dealing with its own _small_
> > set of variables.
> >
> > If that assertion is true the complexity is nowhere near 3^N.
> >
> > Eric, you probably have the most accurate information about the
> > existing constraints. Care to verify the assertion above? I'm
> > serious - the set of constraints is very far from generic and
> > if nothing else, such preprocessing (splitting variables into
> > core and peripherial groups) can make life easier in other
> > parts of the thing.
> 
> You're almost right.  If you counted only explicit constraints,
> created by require statements, you get a bunch of cliques that
> aren't that large.
> 
> Unfortunately....there are a huge bunch of implicit constraints
> created by dependency relationships in the menu tree.  For example,
> all SCSI cards are dependents of the SCSI symbol.  Set SCSI to N
> and all the card symbols get turned off; set any card symbol to Y or M
> and the value of SCSI goes to Y or M correspondingly.
> 


Are the dependencies for each disjoint union kept hierarchically?  Such
as:

setting C = 'y' requires B = 'y'
setting B = 'y' requires A = 'y' 

etc.

If so, given the above ruleset involving symbols A, B and C, and given
that such a ruleset is violated for some reason (you don't even care
why), use the following approach:

set C to 'n' -> are we ok?
set B to 'n' -> are we ok?
set A to 'n' -> are we ok?

Inform the user of each change.  In a massively broken configuration you
could end up with a lot of stuff set to 'n' ultimately, but I think that
this generally would just end up shutting off troublesome configuration
settings, and requiring that the user then reset them manually.

In my example above I've idealized your idealized world of tristates
into a world of bistates.  How do you like that :-)

Instead of trying all possible combinations, instead for 2000 symbols
you only need (worst case) to check 2000 - each iteration you will have
changed one setting from y to n, so the most you can do is 2000 checks.

David

-- 
David Mansfield                                           (718) 963-2020
david@ultramaster.com
Ultramaster Group, LLC                               www.ultramaster.com

  parent reply	other threads:[~2001-05-03 14:55 UTC|newest]

Thread overview: 29+ 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 [this message]
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
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

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=3AF17135.F52C889D@dm.ultramaster.com \
    --to=lkml@dm.ultramaster.com \
    --cc=esr@thyrsus.com \
    --cc=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=kbuild-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@math.psu.edu \
    /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