Date: Sun, 12 Aug 2001 18:15:40 -0700 From: Joe Kelsey <joe@zircon.seattle.wa.us> To: current@FreeBSD.ORG Subject: Re: FreeBSD's aggressive keyboard probe/attach Message-ID: <15223.10812.286362.192448@zircon.zircon.seattle.wa.us> In-Reply-To: <200108130044.f7D0igW03766@harmony.village.org> References: <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
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? 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. 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. /Joe 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?15223.10812.286362.192448>