From owner-freebsd-current Mon Aug 21 15:35: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1826837B616 for ; Mon, 21 Aug 2000 15:35:01 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA71092; Mon, 21 Aug 2000 16:34:58 -0600 (MDT) (envelope-from ken) Date: Mon, 21 Aug 2000 16:34:58 -0600 From: "Kenneth D. Merry" To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14753.42672.286077.409965@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 05:01:20PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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