From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 10:33:01 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B490916A4B3 for ; Thu, 18 Sep 2003 10:33:01 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8FEE43FBD for ; Thu, 18 Sep 2003 10:33:00 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 5313A653DF; Thu, 18 Sep 2003 18:32:59 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26564-01-3; Thu, 18 Sep 2003 18:32:58 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 31EC3652D3; Thu, 18 Sep 2003 18:32:53 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 84D5D36; Thu, 18 Sep 2003 18:32:51 +0100 (BST) Date: Thu, 18 Sep 2003 18:32:51 +0100 From: Bruce M Simpson To: Soren Schmidt Message-ID: <20030918173251.GH786@saboteur.dek.spc.org> References: <20030917234058.E58771@kushnir1.kiev.ua> <200309180617.h8I6HHSi020253@spider.deepcore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309180617.h8I6HHSi020253@spider.deepcore.dk> Organization: SPC cc: Vladimir Kushnir cc: current@FreeBSD.ORG Subject: Re: What's happened to CDIOCREADAUDIO & friends? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2003 17:33:01 -0000 On Thu, Sep 18, 2003 at 08:17:16AM +0200, Soren Schmidt wrote: > The right way of doing audio graps has been to set the wanted blocksize > with CDRIOCSETBLOCKSIZE (not needed if all tracks on the CD is of > the same size), then just read from the device. Ioctl's was newer meant > to be used to read/write data, its also faster to use the R/W path... I'm sure users will see it as a functional regression, though. It might not be the 'right' API for it, I agree, but it would save our user base screaming if the functionality were preserved (or at least emulated). BMS