Date: Mon, 13 Aug 2001 02:36:18 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Joe Kelsey <joe@zircon.seattle.wa.us> Cc: current@FreeBSD.ORG Subject: Re: FreeBSD's aggressive keyboard probe/attach Message-ID: <3B779F92.4172DD27@mindspring.com> References: <15222.50892.75406.972475@zircon.zircon.seattle.wa.us> <200108120813.RAA26578@zodiac.mech.utsunomiya-u.ac.jp> <200108130044.f7D0igW03766@harmony.village.org> <15223.10812.286362.192448@zircon.zircon.seattle.wa.us>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?3B779F92.4172DD27>