Messages in this thread |  | | Date | Thu, 3 May 2001 06:00:08 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: 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/
|  |