Date: Mon, 21 Aug 2000 19:17:37 -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.50849.16035.805395@guru.mired.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
<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.50849.16035.805395>