Windows XP下usbport.sys驱动内部实现解析（三）

_USBPORT_MapTransfer是个比较复杂的函数了，他涉及到transfer的切割、sgList结构的填写，少安毋躁。。。哈哈

struct SG_LIST
{
    ULONG Flags;
    PVOID CurrentVa;
    PVOID MappedSysAddress;
    ULONG EntriesCount;
    SG_ENTRY Entries[1]; // var size
};
struct SG_ENTRY
{
    ULARGE_INTEGER PhysicalAddr;
    PVOID VirtualAddr;
    ULONG Length;
    ULONG Offset;
    ULONG field_14; // unknown
};
_USBPORT_MapTransfer(pFdo,pIrp,pMapRegisterBase,pTransfer)
{
    pFdoExt->DoMapping = FALSE
    // 1. build sgList
    ULONG ulMappedLength = pUrb->TransferBufferLength
    do
    {
        IoMapTransfer(...&ulMappedLength..);
        add physical:virtual to sgList
        ulMappedLength = pUrb->TransferBufferLength - ulMappedLength
    } while(ulMappedLength != 0);
    // 2. split transfer
    if this is an iso transfer
    init some field for iso transfer only
    LIST_ENTRY listHeader;
    call _USBPORT_SplitTransfer(..pTransfer,&listHeader);
    while(listHeader is not empty)
    {
        get transfer from list header
        insert to endpoint\'s ActiveTransfer
    }
    // 3. endpoint worker
    call _USBPORT_CoreEndpointWorker
    if return != 0
    call _USBPORT_InvalidateEndpoint
    }
    看到这里我想你也能大致CoreEndpointWorker跟InvalidateEndpoint的大致作用，很明显是用来处理active transfer list的。先不管他，来看split：
    USBPORT_SplitTransfer(pFdoExt,pEndpoint,pTransfer,pListHead)
    {
        init pTransfer->ChildTransferListHead
        if(pTransfer->TransferBufferLength <= pEndpoint->MaxTransferLength)
            insert pTransfer to pListHead
        else
        {
            ASSERT(pTransfer->Type == interrupt || pTransfer->Type == bulk)
            call _USBPORT_SplitBulkInterruptTransfer
        }
}

很简单的逻辑：只有在transfer length 大于endpoint的最大传输大小，并且是interrupt或者bulk的时候，才split。最多传输长度并不是MaxPacketSize，这个长度要大得多。

_USBPORT_SplitBulkInterruptTransfer(pFdo,pEndpoint,pTransfer,pListHead)
{
    ULONG ulChildrenCount = pEndpoint->MaxTransferLen / pTransfer->TransferBufferLength
    ExAllocatePool(sizeof(TRANSFER) * ulChildrenCount)
    copy from pTransfer to all the new allocated structs
    reinit all the children transfer\'s list entry
    ULONG ulLeftTransferLen = pTransfer->TransferBufferLength
    pChildTransfer = FirstChildTransfer
    pOrgSgList = &pTransfer->sgList
    curSgEntryIndex = 0
    curOffsetInEntry = 0
    OffsetInTotalBuffer = 0
    while(leftTransferLen != 0)
    {
        call _USBPORT_MakeSplitTransfer( pFdo, pOrgSgList, pChildTransfer, MaxTransferLength, MaxPacketLength, &curSgEntryIndex, &curOffsetInEntry, leftTransferLength, OffsetInTotalBuffer )
        leftTransferLen = return value
        link pChildTransfer to pListHead
        OffsetInTotalBuffer += pChildTransfer->TransferBufferLength
        pChildTransfer = NextChildTransfer
    }
}

这个过程有些复杂。简单的讲，这个函数首先计算需要多少个children transfer，然后分配这么多个结构，然后把原来结构的内容copy到新的每个结构里面，但是那些list必须要重新初始化成正确的值，不能指向原来的transfer。然后调用一个辅助函数切割原来transfer的sgList，每个小的transfer的大小最多是 pEndpoint->MaxTransfer 这么大。

sgList是由一个一个的sgEntry组成的，这些sgEntry的长度却未必就是pEndpoint->MaxTransfer 这么大，所以必须由两变量来表示当前处理的是哪个entry，以及当前处理到了这个entry的哪个offset。也就是上面 curSgEntryIndex 和 curOffsetInEntry 的作用，USBPORT_MakeSplitTransfer辅助函数会修改这两个值。

最后注意，原来那个被切割的transfer并没有进入pListHeader，当然也就没有进入Endpoint的ActiveTransfer。

USBPORT_MakeSplitTransfer( pFdo, pOrgSgList, pChildTransfer, MaxTransferLen, MaxPacketLen, pCurEntryIndex, pCurOffsetInEntry, LeftTransferLen, OffsetInTotalBuffer)
{
    ASSERT(MaxTransferLen % MaxPacketLen == 0)
    length = MaxTransferLen
    left = pOrgSgList->sgEntry[*pCurEntryIndex].Length - *pCurOffsetInEntry
    pChildTransfer->sgList.Count = 0
    i = 0
    while(length > left)
    {
        pChildTransfer->sgList.Count ++
        pChildTransfer->sgList.sgEntry[ i ]. Length = left
        pChildTransfer->sgList.sgEntry[ i ].VirtualAddr = pOrgSgList->sgEntry[*pCurEntryIndex].VirtualAddr + *pCurOffsetInEntry
        pChildTransfer->sgList.sgEntry[ i ].PhysicalAddr = pOrgSgList->sgEntry[*pCurEntryIndex].PhysicalAddr + *pCurOffsetInEntry
        i ++
        *pCurEntryIndex ++
        *pCurOffsetInEntry = 0
        LeftTransferLen -= left
        length -= left
        left = pOrgSgList->sgEntry[*pCurEntryIndex].Length
    }
    if(length)
    {
        pChildTransfer->sgList.Count ++
        pChildTransfer->sgList.sgEntry[ i ].Length = length
        pChildTransfer->sgList.sgEntry[ i ].VirtualAddr = pOrgSgList->sgEntry[*pCurEntryIndex].VirtualAddr + *pCurOffsetInEntry;
        pChildTransfer->sgList.sgEntry[ i ].PhysicalAddr = pOrgSgList->sgEntry[*pCurEntryIndex].PhysicalAddr + *pCurOffsetInEntry;
        *pCurOffsetInEntry += length
        if(*pCurOffsetInEntry == pOrgSgList->sgEntry[*pCurEntryIndex].Length)
        {
            *pCurOffsetInEntry = 0
            *pCurEntryIndex ++
        }
    }
    return LeftTransferLen - length
}

逻辑很简单，按照MaxTransferLen划分切割就行了。

接下来就是要真正处理active transfer的部分了：

_USBPORT_CoreEndpointWorker(pEndpoint,bRecursion)
{
    if(!bRecursion)
    {
        if(pEndpoint->Busy)
            return 1;
        else
            pEndpoint->Busy = 1
    }
    call _USBPORT_GetEndpointState(pEndpoint)
    state = return value
    if(state == closed)
    {
        pEndpoint->Busy = 0
        return 0;
    }
    call _USBPORT_PollEndpoint(pEndpoint)
    call _USBPORT_GetEndpointState(pEndpoint)
    state = return value
    if(state == removed)
    {
        pEndpoint->CurrentState = close
        pEndpoint->NextState = close
        insert the endpoint to fdo\'s ClosedEndpointListHead
        pEndpoint->Busy = 0
        return 0
    }
    if(pEndpoint->ActiveTransfer is empty &&
    pEndpoint->PendingTransfer is empty &&
    pEndpoint->CancelTransfer is empty)
    {
        pEndpoint->Busy = 0
        call _USBPORT_FlushAbortList(pEndpoint)
        return 0
    }
    call _USBPORT_GetEndpointState(pEndpoint)
    state = return value
    if(state != pEndpoint->NextState)
    {
        pEndpoint->Busy = 0
        return 1
    }
    call pEndpoint->WorkRoutine(pEndpoint)
    call _USBPORT_FlushAbortList(pEndpoint)
    pEndpoint->Busy = 0
    return 0;
}

眼见函数就要分析完了，这个家伙马上又引出来若干个函数。。哈哈

其中USBPORT_FlushAbortList函数在讲到cancel的时候再说，他其实是一个无关紧要的函数。

而_USBPORT_PollEndpoint函数则是调用miniport对应的Poll函数，在这个函数里面，miniport driver总是检查自己的transfer有没有完成了的，如果有就告诉usbport自己完成了某个transfer。

至于USBPORT_GetEndpointState更是简单，如果pEndpoint->CurrentState == pEndpoint->NextState，则返回CurrentState，否则返回一个特殊的值 ENDPOINT_STATE_TRANSITION，这个值从来不会被设置到CurrentState 跟 NextState成员上面。

至于这个state的用法这里先大致的说说，state表征了endpoint的当前状态，能够设置的值有active, pause, remove, close，后两种是在特别的情况下才设置的。当你关闭一个endpoint的时候 (select configuration却填一个0的config desc)，endpoint进入remove状态，上面已经看到他马上就转换成了close状态而进入了fdo的closed enpoint list，作lazy close。而active状态就是正常状态，在这个状态下，endpoint把自己的active list里面的transfer一一提交给miniport driver。而pause的状态是为了处理cancel跟abort的情况的。如果active list里面的transfer有某个被标记成了canceled或者aborted.endpoint就从active状态进入pause状态。进入 pause状态以后一一完成那些标记成canceled和aborted的transfer，直到全部都处理完了，就转入active状态。

那上面这些操作都是由谁来完成的呢？当然不用说也是pEndpoint->WorkRoutine要作的事情了。

当然，状态的转换并不是这么简单的事情。一个最主要的原因是要同步endpoint的FrameNumber32Bit成员到当前usb host controller的Frame Number，这个主要是用于Iso传输的，所以状态转换的过程是个迂回的。

endpoint 首先进入fdo的state change list，然后fdo让miniport driver在下一个start of frame的时候引发一个中断，在isr的dpc里面同步endpoint的Frame Number，然后把endpoint从state change list里面取出来，这样endpoint才算是进入了新的状态，也就是让endpoint的CurrentState跟NextState相同。

然后要注意的是，这个函数如果返回值是1的话，紧接着调用的就是_USBPORT_InvalidateEndpoint函数。这个函数告诉一个辅助线程 (通过设置一个Event)，调用一次_USBPORT_CoreEndpointWorker。miniport driver也会在比如某个传输完成的时候调用这个函数来排队CoreEndpointWorker的调用，使得usbport能继续向其提交新的传输，而不是停下来。

上面这段话是什么意思呢？看这个流程：进入pending -> flush pending -> 进入map ->flush map->MapTransfer进入 active->CoreWorker 提交一些但不是全部的transfer给硬件。

这里就层层返回了..并没有连续的提交。那要提交下一个怎么办呢？必须要再次进入CoreWorker才可以，这就是通过InvalidateEndpoint函数来完成的。

Invalidate 这个函数把你要Invalidate的Endpoint收集到一个list里面链接到fdo的AttendListHead上，然后唤醒work thread。work thread从fdo的AttendListHead上一一取出每个endpoint，然后调用CoreWorker，如果返回还是1,则保存到另外一个 list上面。当第一遍循环完了，再把那些还是返回1的endpoint重新链接到fdo的AttendListHead上面，再次排队下一个 CoreWorker调用，也就是再次设置Event，而不是直接循环再调用CoreWorker。

希望能明白这种排队poll调用的机制。记住一点：transfer的处理是要通过调用CoreWorker才会传递给miniport然后传递给硬件的，InvalidateEndpoint正是引发一次CoreWorker调用的关键。