Date: Mon, 21 Aug 2000 21:25:17 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Mike Meyer <mwm@mired.org> Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000821212517.B73232@panzer.kdm.org> In-Reply-To: <14753.50849.16035.805395@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 07:17:37PM -0500 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 21, 2000 at 19:17:37 -0500, Mike Meyer wrote: > 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. Hopefully not, but people have a tendency to make simple things complicated. :) > > 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? Well, DVD-RAM drives have a totally different read/write model than CD-R or CD-RW drives. They function pretty much like a MO disk, at least when there is a writable disk in them. Supporting them, at least minimally, is a one line change. (To add write support to the cdevsw in the driver. They really are that much like disks. There's really no additional detection required, since the drive will spit out the command if the media isn't writeable.) CD-R's don't fit within the normal Unix read/write semantics, thus the reason that we have to use userland programs and an ioctl mechanism (whether with burncd or cdrecord) in order to go through the different states required to get the data written. You can't just say "write" and be done. You have to fixate, etc. I'm not working on filesystems at all. Several other folks have talked about doing UDF support, and I'm not really up for tackling that anyway. You can put a UFS filesystem on a DVD-RAM, or you can put an ISO9660 filesystem on one, or whatever other filesystem you want. All I'm working on is the driver-level mechanism to enable write support. > > > 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. 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. > 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. You might want to talk to Joerg Schilling if you've got suggestions. He watches the cdwrite mailing list (cdwrite@other.debian.org) closely, or you can send mail to schilling@fokus.gmd.de. > > 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. I mentioned a solution below -- putting it in the contrib tree. > > > > 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. 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. The disagreement we're having here is about how that write functionality should be supplied. You want it as part of burncd, I think cdrecord does a good job. > > 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. > > 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. I would certainly be supportive if someone more knowledgeable wanted to import and maintain cdrecord. Ken -- Kenneth Merry ken@kdm.org 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?20000821212517.B73232>