这个源代码要想能够编译成功，要针对几个问题进行修订（共涉及 4 个文件）：
1、增加小度 Wifi 的识别；
2、对 64 位系统兼容。

首先是增加小度 Wifi 的识别。这个需要对 common/rtusb_dev_id.c 进行改动，在 {USB_DEVICE(0x148f,0x7601)}, /* MT 6370 */ 这一行下新增以下三行代码：
{USB_DEVICE(0x2955,0x0001)}, /* XiaoDu Wifi */
{USB_DEVICE(0x2955,0x1001)}, /* XiaoDu Wifi */
{USB_DEVICE(0x148f,0x760b)}, /* 360 Wifi */
能看出来，支持的小度 Wifi 有两个版本，最后一行是对 360 Wifi 进行支持的（未测试）。

对 common/mlme.c 作一个小修订，找到 MlmeResetRalinkCounters 函数，把原来的 (UINT32)&pAd->RalinkCounters.OneSecEnd – (UINT32)&pAd->RalinkCounters.OneSecStart) 语句修改为 (UINT32)(&pAd->RalinkCounters.OneSecEnd – &pAd->RalinkCounters.OneSecStart) 即可，这是一个指针差的计算，原来的前强转后相减，在 32 位系统上问题不大，在 64 位系统上则会产生错误。

接下来要修改 include/os/rt_linux.h，主要涉及到对数据包的数据结构进行访问的几个操作宏，把：
#define GET_OS_PKT_DATATAIL(_pkt) \
(RTPKT_TO_OSPKT(_pkt)->tail)
#define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \
((RTPKT_TO_OSPKT(_pkt))->tail) = (PUCHAR)((_start) + (_len))
改为
#define GET_OS_PKT_DATATAIL(_pkt) \
(skb_tail_pointer(RTPKT_TO_OSPKT(_pkt)))
#define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \
(skb_set_tail_pointer(RTPKT_TO_OSPKT(_pkt), \
(int)((_start) – GET_OS_PKT_DATAPTR(_pkt)) + (_len)))
，再把：
#define GET_OS_PKT_END(_pkt) \
(RTPKT_TO_OSPKT(_pkt)->end)
改为
#define GET_OS_PKT_END(_pkt) \
(skb_end_pointer(RTPKT_TO_OSPKT(_pkt)))
，即可。

最后修改 os/linux/rt_linux.c。定位到函数 duplicate_pkt，把其中的两处 skb->tail 改为 GET_OS_PKT_DATATAIL(skb)。定位到函数 ClonePacket，把：
pClonedPkt->dev = pRxPkt->dev;
pClonedPkt->data = pData;
pClonedPkt->len = DataSize;
pClonedPkt->tail = pClonedPkt->data + pClonedPkt->len;
改为
SET_OS_PKT_NETDEV(pClonedPkt, pRxPkt->dev);
SET_OS_PKT_DATAPTR(pClonedPkt, pData);
SET_OS_PKT_LEN(pClonedPkt, DataSize);
SET_OS_PKT_DATATAIL(pClonedPkt, pData, DataSize);
。定位到函数 wlan_802_11_to_802_3_packet，把：
pOSPkt->dev = pNetDev;
pOSPkt->data = pData;
pOSPkt->len = DataSize;
pOSPkt->tail = pOSPkt->data + pOSPkt->len;
改为
SET_OS_PKT_NETDEV(pOSPkt, pNetDev);
SET_OS_PKT_DATAPTR(pOSPkt, pData);
SET_OS_PKT_LEN(pOSPkt, DataSize);
SET_OS_PKT_DATATAIL(pOSPkt, pData, DataSize);
。定位到函数 RtmpOsSetPacket，把：
pOSPkt->dev = pNetDev;
pOSPkt->data = pData;
pOSPkt->len = DataSize;
pOSPkt->tail = pOSPkt->data + pOSPkt->len;
改为
SET_OS_PKT_NETDEV(pOSPkt, pNetDev);
SET_OS_PKT_DATAPTR(pOSPkt, pData);
SET_OS_PKT_LEN(pOSPkt, DataSize);
SET_OS_PKT_DATATAIL(pOSPkt, pData, DataSize);
。定位到函数 send_monitor_packets，把：
skb_put(pOSPkt, (pData – pOSPkt->data));
skb_pull(pOSPkt, (pData – pOSPkt->data));
改为
skb_put(pOSPkt, (pData – GET_OS_PKT_DATAPTR(pOSPkt)));
skb_pull(pOSPkt, (pData – GET_OS_PKT_DATAPTR(pOSPkt)));
。定位到函数 __RtmpOSFSInfoChange，把：
pOSFSInfo->fsuid = current_fsuid();
pOSFSInfo->fsgid = current_fsgid();
改为
pOSFSInfo->fsuid = current_fsuid().val;
pOSFSInfo->fsgid = current_fsgid().val;
。至此，所有修改完毕。

正常 make，sudo make install，然后再 sudo modprobe mt7601Usta 即可。

试用的感觉，这个驱动的效率应该很低。难道是我没有生成 release 的版本？

一、环境及前提
1、Windows 7/Mac OS X 10.9；
2、Eclipse 4.4.1（Luna）；
3、ADT 23.0.3；
4、Android Support Library 已经用 Android SDK Manager 下载完毕。

二、创建可引用的工程 android-support-v7-appcompat
1、打开 eclipse，从 File 菜单选择 Import…；
2、在想到中选择 Android 下的 Existing Android Code Into Workspace，点击 Next；
3、点击 Root Directory 行尾的 Browse 按钮，选中 \extra\android\compatibility\v7\appcompat，确定；
4、在向导中点击 Finish，则一个名为 android-support-v7-appcompat 的工程会出现在 Package Explorer 中；
5、在工程名上右击，打开关联菜单，选择 Properties；
6、在 Properties 对话框左侧点选 Android 条目，此时右侧的 Project Build Target 列表中将列出 SDK 目录下所有已安装的条目，找到列表框下的 Is Library 的复选框（如果安装了很多版本的 SDK，则可能需要拖动滚动条才能看见此复选框）；
7、将 Is Library 复选框点选为选中状态；
8、点击 OK 确定。

三、配置要引用的工程
1、在此工程名上，执行上面的 5、6 两个步骤；
2、点击 Is Library 复选框下一行尾的 Add… 按钮，在弹出的 Project Selection 对话框中选中 android-support-v7-appcompat 并点击 OK 确认；
3、点击 OK 关闭 Properties 对话框；
4、至此，android-support-v7-appcompat.jar 应该出现在工程中的 Android Dependencies 文件夹下；
5、而 Android Private Libraries 文件夹下则会出现 android-support-v7-appcompat.jar 和 android-support-v4.jar；
6、请确保工程中没有以其他的形式对 5 中提到的两个 jar 进行引用设置；
7、如果 eclipse 的 console 视图中出现类似于 styles_base.xml:24: error: Error retrieving parent for item: No resource found that matches the given name ‘android:Widget.Holo.ActionBar’ 这样的错误，请将 AndroidManifest.xml 中的 minSdkVersion 和 targetSdkVersion 值调整为 7。

四、释疑和备注
之所以要创建一个新的工程以供引用，主要原因在于 SDK 中提供的 jar 需要额外的资源文件，这些资源文件会被新工程包含进来，这样才能被引用工程使用到。

开始一直失败，主要在于 三.2 的步骤没有正确执行，而是一直在 Java Build Path 中配置；而没有正确执行的主要原因就在于三太爷的 SDK 版本太全，以至于 Project Build Target 列表把 Is Library 撑到了可视范围之外。基于此，还一度怀疑被引用的工程创建的有问题，在 Import 环节上做了很多次尝试，例如选择 General 下的 Archive 模式或者 Existing Projects Into Workspace，由此更是走到了邪路上。

要验证在引用的工程中配置是否正确非常简单，查看 三.4 和 三.5 中的三个文件的路径即可。对于 Android Dependencies 文件夹下的 android-support-v7-appcompat.jar，它是被引用的工程的输出，因此鼠标指针悬停于其上时，补全显示的全路径最后应该是 bin；而 Android Private Libraries 文件夹下的 android-support-v7-appcompat.jar 和 android-support-v4.jar，是被引用工程的引用，因此其显示的全路径最后应该是 libs，位于 SDK 目录之下。当然，更简单的验证方法就是工程是否能够编译成功。