Hi Michael, it seems that there is no way to pass arbitrary buffers You can, certainly, but not with this technique. I believe the IOConnectMethod*() variable-sized structures are limited to a maximum of 4 kB. These structures are copied after all. You would just pass the buffer address and buffer length down to your user client. The user client can then temporarily map the memory to read its contents. { IOMemoryDescriptor * buffer; buffer = IOMemoryDescriptor::withAddress( aUserBufferAddress, aUserBufferLength, kIODirectionOut, fUserTask ); if ( buffer ) { if ( buffer->prepare() == kIOReturnSuccess ) { /* * Use buffer->readBytes() or buffer->map() here. */ buffer->complete(); } buffer->release(); } } Dan On Friday, December 13, 2002, at 03:35 PM, Michael George wrote: On Thursday, December 12, 2002, at 04:57 PM, Amanda Walker wrote: On 12/12/02 4:06 PM, Michael George <george@auroravideosys.com> wrote: This is what I was thinking of doing as a fallback. However, using "IOConnectMethod*()" I can pass scalars and structures. However, the data I want to pass in will be of arbitrary length, so I can't define that length in the getTargetAndMethodForIndex() data table. Set the length to 0xffffffff in the table. IOConnectMethod() can handle variable length buffers just fine. I don't think this is the case anymore. I tried it and I got some wild-high IOReturn value. I did some other tests and it seems that: If the size of the struct as defined in getTargetAndMethodForIndex() is too large (somewhere between 1Kb (which succeeded) and 512Kb (which failed)) I get 0xfffffecd as the result. It doesn't matter what size I really pass when I make the IOConnectMethod*() call. Needless to say, 0xffffffff is much bigger than .5Mb... It also seems that if the size for a structure I send in the IOConnectMethod*() calls isn't the same as the size declared in getTargetAndMethodForIndex(), then I get 0xe00002c2 (bad argument) back. Together, it seems that there is no way to pass arbitrary buffers through IOConnectMethod*() calls... Can anyone else confirm or correct this? -Michael _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Dan Markarian