It seems Theo van Klaveren wrote:
>
> I think I've finally figured out why AudioFS isn't working (aside from an
> endianess error in v0.1), but I can't think of a solution. The problem I've
> found is as follows: The code in atapi-cd.c (from Soren's ATA driver)
> assumes the passed buffer (in the ioctl struct) is in user-space. The
> following is the offending piece of code from the CDIOCREADAUDIO ioctl call:
>
> --- snip ---
> if ((error = atapi_queue_cmd(cdp->atp, ccb, buffer, size,
> ATPR_F_READ, 30, NULL,NULL)))
> break;
>
> if ((error = copyout(buffer, ubuf, size)))
> break;
> --- snip ---
>
> The first statement issues the read command to the device, I presume. It
> copies the data to an internal (kernel-space) buffer. Next, the internal
> buffer is copyout()ed to ubuf (which is my ioctl buffer), which fails
> because in the case of AudioFS it's in kernel space.
>
> Boing, break, abort, no data for you. Bad boy.
>
> This, of course, caused the buffer's data not to be initialized, causing
> noise and crackles. And AudioFS didn't know the ioctl call failed, because
> the driver didn't return an error.
>
> Am I just doing it wrong, or should atapi-cd.c be patched to verify if the
> buffer is in user space or in kernel space? If so, what function checks if
> an address is in kernel space or in user space? If not, what am I doing
> wrong?
Here's another idea, the ata driver can read/write 2352 sector size
blocks directly, no need to use that ugly ioctl. You just have to
set the right blocksize, I could provide you with a function for
that, no more ioctl mess ;)
-S�ren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
