Re: In-kernel ioctl calls
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 _greatly_ appreciated! The question is, would this be 'portable' to other drivers? In other words, how much trouble would it cost me to get AudioFS to work with SCSI? I dont think the SCSI/CAM system can cope with != % 512 byte blocks, so you are out of luck there, but then again SCSI/CAM doesnt support CDIOCREADAUDIO either, so you are not worse of than now :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: In-kernel ioctl calls
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 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 ;) That would be _greatly_ appreciated! The question is, would this be 'portable' to other drivers? In other words, how much trouble would it cost me to get AudioFS to work with SCSI? Getting AudioFS to work with SCSI drives is non-trivial, if you want it to work with a wide variety of drives. The reason is that different SCSI CDROM vendors had (have?) different ways of reading CD audio data off the drive. If you just want it to work with MMC-compliant drives, it might not be that hard to implement. If you want it to work with more than just MMC-compliant drives (and there are a lot of them out there), it'll take a fair number of quirk entries and device-specific code to do it. For an idea of the variety of different drives out there, take a look at tosha or cdda2wav (comes with cdrecord). They handle most of the drives on the market. (Thus the reason I didn't put all the code in the driver to do it.) If you decide you want to tackle it, let me know. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: In-kernel ioctl calls
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 function for | that, no more ioctl mess ;) That would be _greatly_ appreciated! The question is, would this be 'portable' to other drivers? In other words, how much trouble would it cost me to get AudioFS to work with SCSI? I dont think the SCSI/CAM system can cope with != % 512 byte blocks, so you are out of luck there, but then again SCSI/CAM doesnt support CDIOCREADAUDIO either, so you are not worse of than now :) True enough, the cd(4) driver uses whatever blocksize the drive returns in response to a read capacity command. (And that is generally either 2048 or 512 bytes.) As for the CDIOCREADAUDIO ioctl, as I mentioned to Theo in a previous message, there are a wide variety of methods that SCSI CDROM vendors have used to get CDDA data off the disks. Thus the reason I've left support for CDDA extraction to external programs like tosha and cdda2wav. :) Neither one of those obstacles is insurmountable, but they will make it more difficult to support something like AudioFS with the SCSI CD driver. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: In-kernel ioctl calls
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 it's in kernel space.
I've actually run into this problem in a number of places -- specifically,
aio support. I needed to generate aio requests in kernel, and the calls
were intended to be instantiated only from userland. The linux emulation
code presumably also jumps through hoops to deal with calls that require
data coming from userland. This has, I think, a lot to do with the design
of the syscall and implementation of the syscalls. As mentioned in
another forum a few weeks ago, it also makes authorization hard, as it
happens in many places.
I'd really rather see the calling of syscalls broken out into "service"
and "abi" layers, where the "service" layer implements the service, and
uses struct uio for all argument reads/writes, and the ABI layer is
responsible for setting all that up, but not much else. This would allow
then ABI layers such as FreeBSD, BSD/OS, Linux, to contain minimal service
implementation, moving all implementation into the service layer, which
would not have to be aware of much in terms of whether arguments came from
{user,sys}space, locking semantics, or authorization. Now, this is
somewhat far from the current implementation, but I think is a worthwhile
goal.
For ioctls, which are down a few layers in the implementation, maybe we
need to start passing down an explicit "this call is kernel or user
initiated". There are already situations in, for example, the quota and
extattr code, where a NULL struct cred indicates "authorize as kernel",
which is a somewhat similar issue. Maybe we need a USERSPACE/SYSSPACE
argument in kernel to calls that may or may not do their own
copyin/copyout.
Robert N M Watson
[EMAIL PROTECTED] http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In-kernel ioctl calls
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? Theo van Klaveren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: In-kernel ioctl calls
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
Re: In-kernel ioctl calls
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 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 _greatly_ appreciated! The question is, would this be 'portable' to other drivers? In other words, how much trouble would it cost me to get AudioFS to work with SCSI? (On a side note, I'll be getting a SCSI card and accompanying Plextor CDROM from a friend of mine soon, so I can work at getting AudioFS to work on SCSI CDROMs). Theo van Klaveren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
