All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eric S. Raymond" <esr@thyrsus.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: 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, 3 May 2001 05:43:49 -0400	[thread overview]
Message-ID: <20010503054349.C28728@thyrsus.com> (raw)
In-Reply-To: <20010503104511.C754@nightmaster.csn.tu-chemnitz.de> <Pine.GSO.4.21.0105030452310.15957-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0105030452310.15957-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Thu, May 03, 2001 at 05:14:45AM -0400

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.

So the way it actually works (I think; I've have to write code to do a
topological analysis to be sure) out is that there's sort of a light
dust of atoms (BSD quota is one of them) surrounding one huge gnarly
menu-tree-shaped clique.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Strict gun laws are about as effective as strict drug laws...It pains
me to say this, but the NRA seems to be right: The cities and states
that have the toughest gun laws have the most murder and mayhem.
        -- Mike Royko, Chicago Tribune

  reply	other threads:[~2001-05-03  9:43 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 [this message]
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
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=20010503054349.C28728@thyrsus.com \
    --to=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 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.