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