Warner Losh writes:
 > In message <[EMAIL PROTECTED]> 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

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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to