Date: Tue, 19 Nov 2002 18:26:59 -0800 (PST) From: Nate Lawson <nate@root.org> To: Kris Kennaway <kris@obsecurity.org> Cc: ports@freebsd.org, stable@freebsd.org Subject: Re: HEADSUP - change in CDRIOC.*SPEED ioctl units Message-ID: <Pine.BSF.4.21.0211191820020.61933-100000@root.org> In-Reply-To: <20021120014718.GA7632@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0211191820020.61933-100000>