From owner-freebsd-current Mon Aug 21 23:40:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-172.telepath.com [216.14.0.172]) by hub.freebsd.org (Postfix) with SMTP id C641A37B422 for ; Mon, 21 Aug 2000 23:40:34 -0700 (PDT) Received: (qmail 64298 invoked by uid 100); 22 Aug 2000 06:39:57 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14754.8253.80322.822607@guru.mired.org> Date: Tue, 22 Aug 2000 01:39:57 -0500 (CDT) To: Warner Losh Cc: Mike Meyer , "Kenneth D. Merry" , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <200008220607.AAA01652@harmony.village.org> References: <14753.62883.183839.508028@guru.mired.org> <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> <14753.50849.16035.805395@guru.mired.org> <20000821212517.B73232@panzer.kdm.org> <200008220607.AAA01652@harmony.village.org> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > Having said this, if you can come up with a foolproof way to get the > ioctls right on all the drives that do support them, even the whacked > out ones that need all kinds of quirky entries, and do it in a way > that doesn't needlessly bloat the kernel for little gain (few people, > in the scheme of things, have cd-r or cd-rw on their machines and use > them to burn disks), then he might reconsider his views. However, > much of your posts have had an "airchair quarterback" feel to them and > unless and until you have working code, nobody's opinions are going to > change. You may well be right, and there are good technical reasons for not doing this. The only real reason that's been presented for not doing MMC is that all the non-MMC drives might cause a support headache. There are sound technical reasons for *not* doing non-MMC drives, and Ken and I agree on that. If the answer from the person who would have to approve the code had come back "Ok, provide the code and we'll see how well it works in practice", I'd do the code. But when it appears the code would never make it into the tree to be used, why waste my time?