Joe Kelsey wrote:
[ ... 0x8000 ... ]
> 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.
Kazu stated that the reason he didn't enable this by default
is that he wanted it tested before he committed to making it
the default. It's a bit over the top conservative (since it
can't make a broken mouse any more broken), but I understand
his intent, if not his reasoning.
It's a hack solution, since it should "just work", but this
makes an intrinsic assumption that you won't put something
between you and the hardware to cause problems. It could be
that he just hadn't thought of that -- but I doubt it, since
the code came from him in the first place.
All in all, I agree with the sentiment on design documentation:
I'd like to see a lot more of it before code is thrown at a
problem, and I'd like to see more literate programming, and
most of all I'd like to see benchmarks froving that changes
are not gratuitous, or if they are, they at don't injure
performance (people have actually been much better about this
lately, for the most part, though I still fear for the tcptmpl
elimination, rather than merely a reduction in the allocation
size).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
