From owner-cvs-src@FreeBSD.ORG Sat Apr 12 17:19:04 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F71A37B405 for ; Sat, 12 Apr 2003 17:19:04 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 2A0BE43FBF for ; Sat, 12 Apr 2003 17:19:03 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 38908 invoked by uid 1000); 13 Apr 2003 00:19:04 -0000 Date: Sat, 12 Apr 2003 17:19:04 -0700 (PDT) From: Nate Lawson To: Poul-Henning Kamp In-Reply-To: <25540.1050174072@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2003 00:19:04 -0000 On Sat, 12 Apr 2003, Poul-Henning Kamp wrote: > While attacking on unproven assumptions is all the rage these days > it is still rather embarrasing when people point out that you are > wrong in all aspects of your attack: > > The ioctl function in scsi_da is not called, libcam opens > /dev/xpt and uses an ioctl there to find the correct pass > device. The call path to the function has been disabled > for a period with not a single complaint that I have been > able to discover. However, up until your commit, I could still open /dev/da0 and ioctl it to get its associated passthrough device. You have now removed that capability, which is an API change. Your commit left it in all the other CAM periphs (sa, cd, etc.) I saw zero discussion of this on any list or any "reviewed by" message in the commit. I did incorrectly believe that camcontrol depended on this behavior and I stand corrected. There are a lot of unanswered questions: Do you plan to remove this from other devices? If this is part of a larger API change, where is the public discussion? If not, why did you only change da(4)? > Second, I have discussed this particular change with ken@, > who as you correctly point out is the maintainer, and he > agreed that the function was unused. It's great to see that you got review. Notice of this in the commit message would have saved both of us the wasted time of talking about it. > So I really don't know why or what compelled you to attack me here, > whatever it was: please try to control it better in the future. It's pretty simple: 1. API removal 2. Apparent lack of review and/or public discussion -Nate