Date: Mon, 21 Aug 2000 17:56:57 -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: <20000821175657.A71753@panzer.kdm.org> In-Reply-To: <14753.47379.141329.994631@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 06:19:47PM -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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
It might not be that bad, though, since cdrecord would still be available
and still work.
> > > 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?
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.)
> 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.
> > 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.
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.
> 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.
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.
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.)
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.
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?20000821175657.A71753>