From owner-cvs-src@FreeBSD.ORG Tue Oct 7 13:09:12 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 B87DA16A4B3; Tue, 7 Oct 2003 13:09:12 -0700 (PDT) Received: from list.adaptec.com (list.adaptec.com [216.52.22.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79B3A43FB1; Tue, 7 Oct 2003 13:09:11 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by list.adaptec.com (8.12.8/8.12.8) with ESMTP id h97K9A3d017477; Tue, 7 Oct 2003 13:09:10 -0700 Received: from [10.100.253.70] (aslan.btc.adaptec.com [10.100.253.70]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id NAA20772; Tue, 7 Oct 2003 13:09:04 -0700 (PDT) Date: Tue, 07 Oct 2003 14:12:40 -0600 From: "Justin T. Gibbs" To: Poul-Henning Kamp Message-ID: <74510000.1065557560@aslan.btc.adaptec.com> In-Reply-To: <41878.1065554918@critter.freebsd.dk> References: <41878.1065554918@critter.freebsd.dk> X-Mailer: Mulberry/3.1.0b8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_cd.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 20:09:12 -0000 > No, the problem is that an inadequate programming model were > implemented where the distinction between "the drive mechanism" > and "the media" was not realized. I can't parse that. > My patch doesn't implement that either, it is merely meant as > a stop-gap until such time where somebody will implement this > correctly. If the device takes X amount of time to tell you that it is not ready for whatever reason, then you have to wait X amount of time. Your patch means that a transient error - one that will resolve once the device finds its media or whatever, will return an immediate error instead of blocking waiting for the device to become ready. That's a pretty drastic change in the established behavior or this driver. > It is only very reluctantly that I have ventured into this device > driver in the first place, but so far I have seen zero activity on > the part of the scsi soviet, despite this being on the table for > several years, and therefore I had to do something to be able to > move forward in other areas of the kernel. Hmm. The CD driver probed asynchronously just fine until about two weeks ago. I don't see how this particular issue has been sitting around for several years. > I know full well that you have all been waylaid by the real world, > that's life, and I don't want to add to the stress you are under, > but after some reasonable timeout, the "thats not the way, please > wait for me to do it" has got to stop. I'm not asking for you to wait for me to fix it. The correct fix is in GEOM and I have no intention of touching your code. > If you guys don't have time to update CAM and the peripheral drivers > to follow the rest of FreeBSD, in particular with respect to SMPng > and GEOM, then you should accept that, say so, and instead encourage > other people to move into the area. I'm all for others to come in and work on the code, but puting a hack for a GEOM deficiency into code outside of GEOM has absolutely nothing to do with encouraging people to work on CAM. -- Justin