Date: Tue, 19 Nov 2002 21:43:46 -0500 From: Barney Wolff <barney@tp.databus.com> To: Nate Lawson <nate@root.org> Cc: Kris Kennaway <kris@obsecurity.org>, ports@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: HEADSUP - change in CDRIOC.*SPEED ioctl units Message-ID: <20021120024346.GA3857@tp.databus.com> In-Reply-To: <Pine.BSF.4.21.0211191820020.61933-100000@root.org> References: <20021120014718.GA7632@rot13.obsecurity.org> <Pine.BSF.4.21.0211191820020.61933-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021120024346.GA3857>