Correct, but it will be set to kIOReturnInvalid (0xe0000001).
--scott
> On Jan 7, 2017, at 6:51 PM, Guy Harris <g...@alum.mit.edu> wrote:
>
>> On Dec 12, 2016, at 6:11 PM, Scott Deandrea <sdeand...@apple.com> wrote:
>>
>> I decided to implement isochronous transfers today and changed the structure
>> slightly:
>> struct
>> {
>> // Control information
>> uint32_t frameHeaderLength; // 28
>>
>> // Frame information
>> uint32_t frameLength; // Amount of data sent/received this frame
>> uint32_t frameStatus; // IOReturn result of the I/O this frame
>> uint64_t frameNumber; // Frame number on which this was scheduled/executed
>> by the controller
>> uint64_t ioTimestamp; // Time in which the frame completed
>> } __attribute__((packed, aligned (sizeof(uint32_t))));
>>
>> Therefore, the isochronous format for a request with type
>> kAppleUSBHostPacketFilterRequestComplete is as follows:
>> Link Header
>> padding, if required to force 4-byte alignment
>> Isochronous Frame[0] Header (frameHeaderLength bytes in length)
>> Isochronous Frame[0] Data (frameLength bytes)
>> …
>> padding, if required to force 4-byte alignment
>> Isochronous Frame[linkHeader.ioFrameCount - 1] Header (aligned to 4 bytes,
>> frameHeaderLength bytes in length)
>> Isochronous Frame[linkHeader.ioFrameCount - 1] Data (frameLength bytes)
>>
>> The isochronous format for a request with type
>> kAppleUSBHostPacketFilterRequestSubmit is similar (no data following the
>> isochronous frame header):
>> Link Header
>> padding, if required to force 4-byte alignment
>> Isochronous Frame[0] Header (frameHeaderLength bytes in length)
>> …
>> padding, if required to force 4-byte alignment
>> Isochronous Frame[linkHeader.ioFrameCount - 1] Header (aligned to 4 bytes,
>> frameHeaderLength bytes in length)
>
> So, for a "submit" request, the frameStatus fields are presumably not
> meaningful, as they reports the status of the completed transfer, right?
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
