From owner-freebsd-current Mon Aug 13 2:35:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id B7BA237B401 for ; Mon, 13 Aug 2001 02:35:38 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.143.29.Dial1.SanJose1.Level3.net [209.245.143.29]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA20382; Mon, 13 Aug 2001 02:35:36 -0700 (PDT) Message-ID: <3B779F92.4172DD27@mindspring.com> Date: Mon, 13 Aug 2001 02:36:18 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joe Kelsey Cc: current@FreeBSD.ORG Subject: Re: FreeBSD's aggressive keyboard probe/attach 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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