site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dear All, Developing a USB KEXT for my bulk USB device and wanted suggestions from this group. The device has two bulk endpoints I continously pass around 40KB data from the user level application - Write 40K data from OUT EP– Read single byte data. This is a continous process. Since the data amount is huge, I need a mechanism which takes minimum memory and time to pass this data to device. man 2 write Below are my thoughts for the same: 1. I cannot pass/copy the entire data from IOConnect methods since these methods cannot pass more than 512kb data. Please 2. Send the address of the buffer and buffer size from the user application. At kernel level, we will get this address and length, Then use copyin function to copy this buffer at kernel level and use further. status = copyin((user_addr_t)Bufferaddr, Buffer, Buflen); I am able to pass the data correctly using this procedure, but i suppose this is not the preffered way because (a) I am developing the buffer at user level (b) then again at kernel level , i copyin the entire buffer B/w is it required to get the entire memory buffer at kernel level and then pass to the driver? Can we use the user level address and size and use the user space itself? IF yes, please detail how it is possible? That's the write system call. 3. Can we use IOConnectMapMemory to map the user level buffer with the kernel memory ?? If yes, please detail. As per Apple documentation, we can only map the device registers to map with user level. Please refer -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jul 4, 2007, at 5:16 AM, rohit dhamija wrote: Well, there's always the write system call... is there any reason your device isn't supporting the write method? But since you are saying that you are writing a driver for a bulk device: Introduction to Mass Storage Device Driver Programming Guide <http://developer.apple.com/documentation/DeviceDrivers/Conceptual/MassStorag...

is probably most appropriate, unless you are merely taking to it with existing classes (i.e. the current system recognizes it, or can be made to recignize it, by adding your USB IDs into a plist for the appropriate driver. correct me if I am wrong 40 < 512 in all places, except the universe where Spock has a beard, so you should be fine with this method. 8^). So this process is much time and space consuming. Plus if your allocation for the buffer fails for the copyin(), you are stuck not being able to service the request, and about your only option is to return an EIO. Don't do this, please: the I/O abstractions exist for a reason. http://developer.apple.com/documentation/DeviceDrivers/Conceptual/AccessingH... Hardware registers include memory on board the card. In general, this is only useful for polled I/O devices for which you own the lowest lever driver (USB is not such a stack; do not use this method for USB, or you will prevent power management of USB devices). It also only works if there's RAM on the device for the user space application to access, not the other way around. This email sent to site_archiver@lists.apple.com