On Tue 22/01/08 8:28 AM , Werner Almesberger [EMAIL PROTECTED] sent: > 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.
Thanks; that does help me understand the objections a bit better. I can fix the "unused". I can clean up the conditionals. But I understand that won't help. The fundamental problem is that a hardware device was added that changed the fundamental behavior of the serial port so that it no longer behaves the way the standard SOC driver can handle. Therefore, a complete solution cannot be implemented without modifying the SOC driver code - it's that simple. If the requirement is that we cannot put platform-specific code in a general driver, then we must accept that the console needs to be disabled entirely. There is simply no other way around that issue. If we agree that there must be a code change to the standard driver, then the only discussion is subjective -- to what degree do we wish to modify things. > > It strikes me as a completely relative term, which > makes the evaluation> of solutions for this problem largely > subjective > It is :-) Thanks for being honest about it. I feel the issue got the run-around for the many months it's been left open in bugzilla, and it's refreshing to have some open discussion. :) > 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 :-) Yes, depending on the implementation. The danger that I see is that in *nix culture, silence is goodness. So you have no means of knowing if your kernel and drivers are running just fine, or if the reality is just that you messed up the bootup scripts and the console is merrily dropping valuable diagnostics into the bit bucket. Doesn't matter to the end user, I suppose, but I'd prefer to have the console shout at me if gsmd isn't running. If that's the desired direction, someone should go for it and propose a patch. It'll never get accepted upstream, but I can see that it would be simpler. Or someone could go one better -- if there's console output, and the hardware is flow-controlled, just clear the hardware flow control bits. Ugly, but at least no characters get dropped on the floor. > > (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 Mike (mwester)
