From owner-freebsd-stable Tue Nov 19 18:26:59 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 4632F37B401 for ; Tue, 19 Nov 2002 18:26:58 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id BC87F43E42 for ; Tue, 19 Nov 2002 18:26:57 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 62048 invoked by uid 1000); 20 Nov 2002 02:26:59 -0000 Date: Tue, 19 Nov 2002 18:26:59 -0800 (PST) From: Nate Lawson To: Kris Kennaway Cc: ports@freebsd.org, stable@freebsd.org Subject: Re: HEADSUP - change in CDRIOC.*SPEED ioctl units In-Reply-To: <20021120014718.GA7632@rot13.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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