Date: Sun, 12 Aug 2001 20:11:28 -0600 From: Warner Losh <imp@harmony.village.org> To: Joe Kelsey <joe@zircon.seattle.wa.us> Cc: current@FreeBSD.ORG Subject: Re: FreeBSD's aggressive keyboard probe/attach Message-ID: <200108130211.f7D2BSW04119@harmony.village.org> In-Reply-To: Your message of "Sun, 12 Aug 2001 18:15:40 PDT." <15223.10812.286362.192448@zircon.zircon.seattle.wa.us> References: <15223.10812.286362.192448@zircon.zircon.seattle.wa.us> <15222.50892.75406.972475@zircon.zircon.seattle.wa.us> <200108120813.RAA26578@zodiac.mech.utsunomiya-u.ac.jp> <200108130044.f7D0igW03766@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <15223.10812.286362.192448@zircon.zircon.seattle.wa.us> Joe Kelsey writes: : Warner Losh writes: : > In message <15222.50892.75406.972475@zircon.zircon.seattle.wa.us> Joe Kelsey writes: : > : I also second Terry's comment about 0x800. There is no reason to add : > : yet more driver flags in order to "do the right thing". The "do the : > : right thing" case should always be default and a flag (sysctl variable, : > : etc) should be used for those who want "the wrong thing". : > : > The main reason that it wasn't added at the time was that it was : > expensive in terms of CPU utilization, so it shouldn't be on by : > default. There may be other reasons as well... : : Please explain the reference to "expensive in terms of CPU : utilization". I have currently turned this code on by default (simply : removed the if blocking and the hack comment) so that it always does the : log message followed by the disable/enable calls. So far, where I used : to see thousands of "out of sync" messages, I now have seen exactly one : "out of sync" message followed by the "re-enable" message. I cannot see : how a single disable/enable call at the first mouse motion can cause : massive CPU utilization problems. But then again, maybe I am thinking : wrong? That's what I was told when I asked to make it default. The enable/disable routines were, at least at the time, somewhat expensive because they did things to the mouse port at 1uS per transaction and there were lots of transactions. : Please explain this. Do you expect to be resetting the mouse thousands : of times per second? It is an error condition. The default must be to : fix the errors. As soon as someone reports that the fix is being : executed thousands of times per second on their broken hardware, then we : can implement the opposite flag to disable the fix in those pathological : cases where it causes a problem. It is possible, i believe, to have patholigical cases where resetting the mouse would cause another out of sync, which would cause another reset, which would cause another out of sync, etc. This would result in a hung system, for all intents and purposes. That's why it isn't enabled by default. At least that's my dim recollection of the mail I had with yokota-san, that may have been private. : Again, all I am asking is for someone to explain why they make a design : decision. The comment in the psm.c file about a "hack" is extremely : unhelpful. Why did the coder think it was a "hack" solution? What were : the pros and cons that went into that decision. Was there a discussion : on -current about it that I missed? If there was a discussion and a : conclusion was reached, the proper thing to do is to insert : documentation into the code to explain the design decisions that were : made. If you don't document the design in the code, it will be : forgotton, as there is no other place to document it in FreeBSD. Sometimes things don't get documented. That's the nature of the beast. A word about tone. If you were to get as in my face about, say, pccard, as you about the psm driver, I'd certainly be ill inclined to provide you with what you want. Good Tone: Say Warner, why do you bother turning off the power after you suspend a socket. Shouldn't the power routines take care of that? Is there something subtle that's going on? Maybe a comment is in order? Bad Tone: Please explain the pros and cons for turning the power off after suspending a socket. I really want to know. Why did they do this? Didn't the coder trust the power routines? The least he could have done was include a comment. Was there some long discussion that I missed? See the difference? The first tone is friendly, suggesting that something in the code might be unclear. The second seems to imply that I'm a moron for not documenting every trivial solution with a 20 page thesis on why it is good or bad to do. Also, sometimes you have to know when to give a point a rest. Hammering this again so soon after yakota-san sent out his long, very well written message that said he was going on a business trip and would be out of touch isn't going to have the results you expected. He'll get back from his trip and will likely be swamped. That's the worst time to hit someone with a "hey, can you document this more" message. Warner P.S. The answer is that we don't power off before that point and if we fail to power it off, the card will continue to draw power while suspended and can cause machine hangs when the machine is resumed. A careful tracing of the code shows that no power down commands are issued in the disable path. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108130211.f7D2BSW04119>