Kazutaka YOKOTA wrote:
> >o You may want to implement a rate throttling mechanism;
> > init will stop respawning a getty on a port, if it is
> > exiting too rapidly, while inetd will rate limit the
> > number of connection attempts a second, as well. I
> > guess you probably don't want to disable it, ala init,
> > but limiting the number of reinitialize/resets per
> > interval would address the "too expensive" and "reset
> > causes additional resync errors" cases.
> We are not running getty on the mouse port. So, we don't need
> to worry about this.
I wasn't clear, I guess.
What I meant was that you might want to rate throttle the
mouse resets, in case the mouse driver ends up getting into
one of those loops that people are afraid it might.
If the moust can only reset once a second, you can't get
stuck in a tight loop resetting the mouse. If it can only
do it 10 times before it backs off a minute, then this will
prevent someone grabbing the mouse and wiggling it to make
it work breaking it forever.
In other words, you control the rate at which you reset the
mouse. This keeps it from being a problem, even if the new
code breaks horribly. The worst that can happen is that you
reset once a second (or whatever you tune the timer for), and
then only do that 10 times every two minutes (or whatever you
set the second timer for).
So the idea is to make it behave like init behaves with getty:
init -> getty
psm0 -> mouse reset
Does this make more sense?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message