Date: Mon, 21 Aug 2000 22:38:11 -0500 (CDT) From: Mike Meyer <mwm@mired.org> To: "Kenneth D. Merry" <ken@kdm.org> Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <14753.62883.183839.508028@guru.mired.org> In-Reply-To: <20000821212517.B73232@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <14753.50849.16035.805395@guru.mired.org> <20000821212517.B73232@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kenneth D. Merry writes: > > Does this extend to the point of supporting things that happen to > > share a physical connector with SCSI, but otherwise aren't SCSI? > > Because that's what supporting non-MMC CD-R drives would amount to. > Not really. Non-MMC CD-Rs not only use the same connectors and cables, > they also comply with the SCSI standard. They use the same bus protocol, > respond to inquiries and test unit ready commands just like everything else. > They also act like standard CDROM drives when you're reading data. They > primarily differ in the mechanisms and quirks needed to do writes. No, they comply with *part* of the SCSI standard - the part needed to do reads. But drives with the same connectors comply with *part* of the standard - the part that defines the connector. > > Of course that isn't the entire picture - that's why I asked. Again, > > arguing about this solution being "halfway" when you're ignoring half > > the functionality of the standard seems hypocritical. > Not really. We've had a solution for supporting the other (writing) half > of the standard from the beginning -- cdrecord. That solution has also > covered non-MMC drives from the beginning. I've been told (repeatedly) that ports are *not* part of FreeBSD. Therefore, we don't have a solution. We have a pointer to one provided by someone else. > > > If doing burncd support for MMC drives were a step on the way for getting > > > support for the various other types of drives that cdrecord supports, it > > > would be a different story. (We'd also want to see what features were > > > available in cdrecord but not burncd and look into adding those as well.) > > In other words, supporting the standard would only be reasonable if > > it's a start towards embedding cdrecord in the kernel, which we have > > already agreed is unreasonable. > Yes. That sounds like "I don't want to do it for religious reasons" to me. > > > As it is, importing cdrecord into the tree would solve what seem to be > > > your major objections -- that cdrecord gets out of sync with the OS because > > > it isn't built with the OS, and that we don't ship a way of burning SCSI > > > CDs with the OS. > > Your doing that would certainly be a step in the right direction. > Well, I didn't say I wanted to be the one to do it. :) I really know very > little about vendor branch imports, etc. Well, you have someone willing to fix the problem - but you object to the fix for religious reasons. The fix you're willing to accept you're not willing to implement. Sounds like a bureaucracy to me. Do you claim ownership of all the drivers in cam/scsi, or can someone with more tolerant religious convictions add a driver that's a clone of the CD driver + MMC extensions that gets first crack at CDROM drives, and recognizes MMC drives, but not others? <mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14753.62883.183839.508028>