lkml.org 
[lkml]   [2001]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Why recovering from broken configs is too hard


On Thu, 3 May 2001, Eric S. Raymond wrote:

> 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.

Errrmmm... _That_ is not too horrible - e.g. SCSI definitely belongs
to core. Individual drivers, OTOH, do not and there's a lot of them.

I'm not talking about connectedness of the thing. However, I suspect that
graph has a small subset such that removing it makes it fall apart.

IOW, you have a small well-connected backbone and a lot of small groups
around it, such that each path from one group to another hits the
backbone. ACK? Picture you've described doesn't contradict that - there's
a relatively small number of symbols that correspond to subsystems and
tons of stuff hanging from that subset.

Look at it as a network. How many sites do you need to nuke to break it
into tiny bits?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:17    [W:0.066 / U:16.380 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site