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-stable" 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>