Date: Thu, 21 Nov 2002 06:02:51 +0100 From: Matthias Andree <ma@dt.e-technik.uni-dortmund.de> 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: <m3fztvy0p0.fsf@merlin.emma.line.org> In-Reply-To: <Pine.BSF.4.21.0211191820020.61933-100000@root.org> (Nate Lawson's message of "Tue, 19 Nov 2002 18:26:59 -0800 (PST)") References: <Pine.BSF.4.21.0211191820020.61933-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson <nate@root.org> writes: > 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. You must be kidding. Let the kernel figure 0xffff is magic and be done, one line of code. No need to make dozens of maintainers change their applications. Why does the application have to deal with raw kB/s rates at all? -- Matthias Andree 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?m3fztvy0p0.fsf>