Date: Mon, 24 Jul 2000 14:14:48 -0500 (EST) From: "Jason T. Miller" <jasomill@shaffstall.com> To: freebsd-scsi@freebsd.org Subject: Re: CAM layer Message-ID: <Pine.LNX.4.10.10007241336450.13788-100000@guildenstern.shaffstall.com> In-Reply-To: <Pine.BSF.4.10.10007231349310.54040-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Jul 2000, Matthew Jacob wrote: > platform support being solid. But whether or not there is a net benefit to > merged support such that da && sa && cd drive ATAPI devices is open to > question, and not just on a purely technical level. I don't see much benefit there, except not having to maintain separate drivers. What I want to do, personally, is shoot random CDBs at ATAPI devices; that is, an ATAPI passthrough device. Linux does it with the IDE-SCSI emulation layer; this allows one to use cdrecord, cdrdao, etc, on supported IDE devices, amongst other neat things. Yes, I know, ATAPI CD-R support is present in the kernel, but it doesn't work with all drives (with the proliferation of weird CD-R command sets, SCSI-3 MMC or no, it probably never will); in all honesty, I'd rather see kernel bloat from a clean architectural model than from application-specific stuff like CD burning; this process does not (and will never) fit the UNIX device model, and is therefore hopelessly tied to IOCTLs (or a so-called "funky character device interface" with command packets etc); most of these IOCTLs are more-or-less directly tied to SCSI (or ATAPI) commands (and to support most older, pre-MMC drives, vendor-unique commands; even with MMC, we have different media types and drive capabilities). Furthermore, if we're talking anything more complicated than "one-off" CD mastering, we more or less need full control of the bus, to deal with things such as drives that fail to disconnect from the bus for a few ms when the write process is beginning (that is, after the buffer is full but before the write laser "gets its groove"), etc. Again, I don't want to deal with this in the kernel. Now that I think about it, I don't want to do multi-CD duplication over an ATA bus; this, however, is not my point. Support for packet-written CD-Rs and CD-RWs, multisession support, R-W subchannel control, ISRCs, etc. would be nice; again, this would add significant kernel bloat with little gain. Also, in its current incarnation, the CD driver will never support block sizes that aren't a multiple of 512; therefore, reading CD-ROM XA form 2 discs and non-XA mode 2 discs (although such discs are rare outside of CD-I; I'm not sure about Photo CD -- do we handle these?) is impossible through the device driver. ATAPI tape drives would also benefit from a CAM interface: how, through the tape device driver, could one set mode pages or retrieve diagnostic information via LOG SENSE? Very nice features indeed in a high-end system; it's nice to be able to control the drive's error-handling and get retry counts and such. Finally, a passthrough device is always nice when prototyping new device code. ATAPI (but not ATA), like 1394 or fibre channel, can be thought of as just another SCSI command transport (that is, a physical layer in the SCSI-3 architecture model), therefore, support for it can and should be worked into CAM. All this from someone who would use SCSI for all of the above, though I do admit to owning one old 2x ATAPI CD-R (which doesn't work with the 4.0 kernel-level CD-R code). -jtm 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?Pine.LNX.4.10.10007241336450.13788-100000>