> You want brutality and heuristics? I'll give you brutality and heuristics...
> I could just treat a config as a sequence of assignments, as though
> the user had typed them in sequence, rejecting any later ones that
> throw constraint violations. That way we can avoid ever accepting or
> having to deal with an invalid configuration. The invariant that every
> symbol assignment either augments a valid configuration or is rejected
> would be conserved.
Which is pretty much what make oldconfig does. Go from the top asking users
about new symbols and just killing stuff that would break the rules.
> This isn't "recovery", it's more like high-handedly throwing away
> assignments that don't happen to fit stuff bound earlier in the tree
> traverse that defines symbol print order. And it's going to give odd,
> "brutal" results in some cases because guard symbols are ordered
> before their dependents.
Thats the mathematician speaking again
> But if all you want is brutality and heuristics, it might do.
Its worked well enough for the past five years. On odd occasions you do find
you've inadventantly unconfigured something but normally the conflict vanishes
with almost no ripples.
I'm quite happy for oldconfig to continue to do what it did before. I'm quite
happy to accept its mathematically imperfect, because it hasnt gone far wrong
yet
Alan
-
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:18 EST