From owner-freebsd-current Mon Aug 21 16:20:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom2-008.telepath.com [216.14.2.8]) by hub.freebsd.org (Postfix) with SMTP id E804837B616 for ; Mon, 21 Aug 2000 16:20:23 -0700 (PDT) Received: (qmail 56835 invoked by uid 100); 21 Aug 2000 23:19:47 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.47379.141329.994631@guru.mired.org> Date: Mon, 21 Aug 2000 18:19:47 -0500 (CDT) To: "Kenneth D. Merry" Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821163458.A70871@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> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth D. Merry writes: > > Which should actually be smaller than the flood of mail saying things > > like "why doesn't burncd support my nice, standard-compliant CD-R?" In > > fact, according to the documentation that comes with cdrecord, it > > would be *much* smaller, because all the SCSI CD-Rs released in the > > last few years have been MMC. > I think it would generate a fair amount of mail, certainly a lot more than > the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs. > (which is very, very little) What evidence do you have that it would generate a fair amount of mail? I agree that there's very little about burncd - probably because most people get dual pointers when they ask what to use to record cds. Improving what burncd works for shouldn't change that, especially if the kernel boot sequence said whether or not the drive supported MMC. > > Correct. I'm not asking why cdrecord's functionality isn't in the > > kernel, and wouldn't argue that it should be. I'm asking why there > > isn't support for a widely deployed standard interface to this > > functionality when there's already a kernel API for it. > > If it's a matter of not wanting to maintain that little bit of code, > > I'm willing to do that. > It's not there because I'd rather not do a halfway solution. Adding > support for only MMC drives will mean that users with non-MMC SCSI CD > burners will just get confused when burncd doesn't work. ("But it worked > for my friend Joe...") I'd say that you've *already* got a halfway solution, in that you only support half the functionality of the standard. Just curious - do you feel that you have to support old disk drives that don't properly adhere to the SCSI standard, or otherwise behave in strange ways? Say some of DEC's old drives that don't spin up on power on, but have to be told to do so by the OS? A quick check doesn't reveal any support for such things, but I may have missed it. > Just because the API is there doesn't mean we should go through the work > to support that API when we have something else that already works. > It would be a duplication of functionality. Why reinvent the wheel > when the wheel we have works very well? For the same reason that CAM replaced the old SCSI system - because the replacement is an improvement! Sure, it won't work with non-standard devices, but those should be a shrinking minority. This also solves the problem of keeping the two in sync. I've been bit more than once by the system and cdrecord being out of sync. > If you want standard burner support with the OS (isn't that what you're > really getting at here?), why not just import cdrecord into the contrib > tree and be done with it? It's GPLed, so it wouldn't be any more onerous > license-wise than many of the other tools we have in the tree. Well, that would certainly solve the sync problem - but I'm not willing to support cdrecord; it's an ugly mess. I'd rather support (including write) the MMC code. I just don't want to write it if it will never go in the distribution.