It seems Theo van Klaveren wrote:
| 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 ;)
That would be
On Wed, Aug 09, 2000 at 23:08:12 +0200, Theo van Klaveren wrote:
Soren Schmidt wrote:
-long story snipped-
| 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
On Thu, Aug 10, 2000 at 08:48:50 +0200, Soren Schmidt wrote:
It seems Theo van Klaveren wrote:
| 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
On Wed, 9 Aug 2000, Theo van Klaveren wrote:
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
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
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
Soren Schmidt wrote:
-long story snipped-
| 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
7 matches
Mail list logo
