Date: Tue, 07 Oct 2003 14:12:40 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/cam/scsi scsi_cd.c Message-ID: <74510000.1065557560@aslan.btc.adaptec.com> In-Reply-To: <41878.1065554918@critter.freebsd.dk> References: <41878.1065554918@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?74510000.1065557560>