Date: Mon, 21 Aug 2000 16:34:58 -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: <20000821163458.A70871@panzer.kdm.org> In-Reply-To: <14753.42672.286077.409965@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 05:01:20PM -0500 References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 21, 2000 at 17:01:20 -0500, Mike Meyer wrote:
> Kenneth D. Merry writes:
> > On Mon, Aug 21, 2000 at 10:54:49 -0500, Mike Meyer wrote:
> > We'd get a flood of mail saying things like "why isn't my froboz CD-R/WORM
> > supported with the cd(4) driver..."
>
> 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)
> > If we put all of cdrecord's functionality into the kernel and burncd, it
> > would be just as big, or bigger than cdrecord is now. (Plus we'd be stuck
> > with maintaining it.)
>
> 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...")
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?
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.
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?20000821163458.A70871>