From owner-freebsd-current Mon Aug 21 17:17:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-149.telepath.com [216.14.0.149]) by hub.freebsd.org (Postfix) with SMTP id 6B73937B422 for ; Mon, 21 Aug 2000 17:17:38 -0700 (PDT) Received: (qmail 58438 invoked by uid 100); 22 Aug 2000 00:17:37 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.50849.16035.805395@guru.mired.org> Date: Mon, 21 Aug 2000 19:17:37 -0500 (CDT) To: "Kenneth D. Merry" Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821175657.A71753@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> 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: > On Mon, Aug 21, 2000 at 18:19:47 -0500, Mike Meyer wrote: > > 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? > Prior experience. People get confused relatively easily, no matter how many > places something is documented and no matter how many times you explain > something on a mailing list. Um - that's not evidence, that's an argument. But prior experience shows that having two tools for burning cd's generates - in your own words - "very, very little" mail. By the same argument, including some drives in both sets of tools shouldn't raise the confusion level. > > > > 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. > You mean reading and not writing? Yes. > One piece of writing functionality I *do* intend to put in the kernel is > support for DVD-RAM drives. (It's mainly hung up with disklabel problems > at the moment.) Why those and not CD-R drives? Especially when, from what I can tell, the situation with those is even *more* confused than it is with CD-Rs, as there are multiple writable DVD formats, and they are changing. Or are you talking about support for the non-9660 file system that some of them use? > > 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. > You missed it. In the error recovery code. If a drive returns an error > code that we understand to mean "spin me up", we send a start unit command > to the disk. (No more than four start units may be oustanding at one time, > to avoid overloading power supplies.) > We also have various quirk tables for devices that do odd things. So yes, > I think we do need to support older and/or quirky hardware, to a certain > point. 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. Supporting quirky MMC drives should be done just like most other hardware, though. > > > 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. > I don't think you've made the case that the replacement is an improvement. > cdrecord at the moment has more features than burncd, and seems to work > well. Well, I don't agree on that assesment about how well cdrecord works. I've found it to be finicky and a PITA. > The only thing you've said about cdrecord is that the code is a mess > (below). I don't think it's that bad. I might do things differently, > but things are going to be more complicated when you try to support a large > number of OSes. You forgot the problems of it staying in sync with the OS. I've had both build breakages, and binaries that quit working after starting to write a blank (thus ruining it) after doing an OS upgrade. > > > 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. > What you're willing to support isn't the whole picture here. As the driver > author, I'd rather not support a solution that only goes halfway. 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. > 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. > 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.