Date: Fri, 20 Apr 2001 23:34:53 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Chris Dillon <cdillon@wolves.k12.mo.us>, Domas Mituzas <midom@delfi.lt>, scsi@FreeBSD.ORG Subject: Re: mly driver does not work with SCA in up-to-date 4.3 Message-ID: <20010420233453.B69868@panzer.kdm.org> In-Reply-To: <200104202033.f3KKX1f02169@mass.dis.org>; from msmith@FreeBSD.ORG on Fri, Apr 20, 2001 at 01:33:01PM -0700 References: <Pine.BSF.4.32.0104201443390.86778-100000@mail.wolves.k12.mo.us> <200104202033.f3KKX1f02169@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 20, 2001 at 13:33:01 -0700, Mike Smith wrote: > > > Basically, CAM insists that things behave exactly like SCSI disks, > > > etc. And RAID arrays just don't; the driver has to fake up all > > > sorts of rubbish like whether the array supports disconnect, > > > tagged queueing, its transfer rate, etc. > > > > I gather this would also cause problems for putting the ATA stuff > > under the CAM umbrella? I thought the idea behind CAM was to be > > somewhat generic in nature, not SCSI-specific. > > It may well have been, and in some ways at least the transport layer > probably is fairly protocol-agnostic. However, the current > implementation is hopelessly SCSI-specific, and the peripheral drivers > are not good at dealing with odd situations. I wouldn't call it hopeless, but yes, the current implementation is definitely SCSI-specific. > > > I thought initially that because the array uses a subset of > > > SCSI-like commands, it'd make sense. Unfortunately, it doesn't > > > support enough of them to be useful. A wiser compromise would be > > > to have an optional CAM interface that can talk to non-disk > > > devices on the SCSI bus and just interface the disks directly to > > > the bio layer, as I used to do with other drivers. > > > > Would this help out the aforementioned ATA-under-CAM problems? > > I used to think that shimming ATA under CAM would make sense; I don't > anymore. Even shimming ATAPI devices under CAM would be a bad idea. > Whilst meaning no offense to Justin and the other CAM folks, I consider > CAM to basically be baggage best avoided unless one has to deal with real > SCSI peripherals. It should come as no surprise that I disagree. :) I think the queueing, resource allocation and probe code in the transport layer, as well as the passthrough facility, would work well for ATA. That was one of the design goals for the CAM spec in the first place. My guess is that if we did put ATA support into CAM, it probably wouldn't come as a translation layer under the transport layer to translate SCSI into ATA. Rather we would probably have a separate ad driver, and perhaps a merged cd(4) driver, since ATAPI and SCSI CDROM drives are fairly similar. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010420233453.B69868>