Re: Why recovering from broken configs is too hard

From: Alexander Viro (viro@math.psu.edu)
Date: Thu May 03 2001 - 05:00:08 EST


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/



This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:16 EST