From owner-freebsd-stable Tue Nov 19 18:43:55 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8754E37B401; Tue, 19 Nov 2002 18:43:53 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4F7043E88; Tue, 19 Nov 2002 18:43:52 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gAK2hkvg003885; Tue, 19 Nov 2002 21:43:46 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gAK2hkYF003884; Tue, 19 Nov 2002 21:43:46 -0500 (EST) Date: Tue, 19 Nov 2002 21:43:46 -0500 From: Barney Wolff To: Nate Lawson Cc: Kris Kennaway , ports@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: HEADSUP - change in CDRIOC.*SPEED ioctl units Message-ID: <20021120024346.GA3857@tp.databus.com> References: <20021120014718.GA7632@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.25 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Oh for heaven's sake, can't we afford one line of code to say if the value is <177 to multiply it by that? On Tue, Nov 19, 2002 at 06:26:59PM -0800, Nate Lawson wrote: > On Tue, 19 Nov 2002, Kris Kennaway wrote: > > On Tue, Nov 19, 2002 at 04:39:29PM -0800, Nate Lawson wrote: > > > I just MFCd code that was committed to current a month ago that changes > > > the semantics of CDRIOC{READ,WRITE}SPEED ioctls to take the raw value (in > > > KB/sec). Before, the units were multiples of CDROM 1X speed (i.e. 1x = > > > 177 K/s, 2x = 354 K/s, ...) Also, it is now possible to tell the drive to > > > select its maximum possible speed by sending 0xffff as the ioctl argument. > > > > > > Maintainers of CD player, ripper, and burner packages should make sure > > > they've tracked the change correctly. If you don't use the CDRIOC > > > interface, you don't need to change anything. If you do, multiply all > > > values by 177 before passing them to ioctl(). For examples on how to do > > > this, see usr.sbin/cdcontrol or usr.sbin/burncd. > > > > This is not acceptable, IMO. We don't break ABI or API compatibility > > in the -STABLE branch without very good reason. > > I have examined many common ports including cdrecord, tosha, dagrab and am > reasonably certain no one is using the CDRIOC*SPEED ioctls outside of > cdcontrol and burncd. Since they are only found in FreeBSD, the only > problem may be a 3rd-party commercial application (if there is one). A > possible workaround would be to specify speed as 177 for 1x, etc. > > The reason this was MFCd is that it is impossible to tell the drive to use > the max speed by sending 0xffff since the kernel was multiplying by 177. > See the PR referenced in the original commit. This limited functionality > in the MMC command set. There are still limitations (only one of READ, > WRITE speed may be set and the other is automatically set to max) but that > would break the API to change. > > The commit was available in -current with a 1 month MFC window and was > reviewed by sos@ and ken@ (atapi cd + scsi cd maintainers). I also > believe I sent a headsup after committing the changes to -current as well > as this one for stable. > > Anyway, please let me know if there are any problems. > > -Nate > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message