Mike Westerhof wrote: > As we embark on this discussion, can somone please define "intrusive" > for me?
Hmm, I guess a definition would go along these lines: - changes a lot of code - changes unrelated code - changes the logic of existing code In this case, it's mainly the introduction of platform-specific code in a general driver that's ugly. I also find the use of "unused" and the logic leading there quite scary. to aim too high and too low at the same time. Too high, because it tries to provide the abstraction of two independent UARTs (which seems to be ambitious beyond what we actually need), but too low, because it doesn't implement this generalization in a truly general way. > It strikes me as a completely relative term, which makes the evaluation > of solutions for this problem largely subjective It is :-) Anyway, don't you think just keeping the serial console from getting permanently stuck would solve the issue for all practical purposes ? The algorithm I proposed would let the console resume operation as soon as the misconfiguration is cleared. So you'd only lose messages if your setup/bringdown sequence is buggy and your kernel crashes at the same time. As we all know, juggling two types of brokenness at the same time it bad anyway, so this shouldn't be much of an issue :-) > (The correct, although *impractical* solution, is to put the missing > pullups or pulldowns on the mux so that the console flow-control lines > are in the correct state to make this entire problem a total non-problem.) Yeah, I wish someone would have thought of putting that pull-down :-( Pull-up would be easy - the 2410 has that, but alas, no pull-down. - Werner
