Windows XP下usbport
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调用的关键。
原文转自：https://blog.csdn.net/killcpp/article/details/7287110
