评论

#rmingming 发表于2007-11-04 16:53:02  IP: 202.113.29.*

请问合集的pdf在哪里下载？
在blog里找到了u盘的pdf下载，google到了hub部分的pdf下载。
usb core部分的pdf没有找到。
可不可以置顶相关的下载呢？谢谢！

#fudan_abc 发表于2007-11-04 23:08:42  IP: 121.207.129.*

整理好了自会传上来，稍等

#eric 发表于2007-11-21 18:20:17  IP: 116.24.41.*

多几个楼猪这样的人，中国的IT行业或许还有的救

那些个出版社估计就要哭了

支持楼猪

支持楼猪

#pegasus_sqq 发表于2007-12-04 13:35:19  IP: 221.219.1.*

很喜欢看这样看着不累的技术文章，期待新作^_^

#albcamus 发表于2007-12-21 11:20:16  IP: 61.148.56.*

景仰一个。

#bass339 发表于2008-01-18 13:53:19  IP: 61.177.149.*

只能说佩服！

#ilyh 发表于2008-01-26 15:11:13  IP: 61.141.190.*

牛人！潜心拜读您的大作。

#augustusqing 发表于2008-02-25 10:48:38  IP: 202.38.254.*

叹为观止！

#zhangj 发表于2008-02-25 14:58:42  IP: 10.1.16.*

上来踩踩哈～ 顶一下！

#startear 发表于2008-02-27 21:52:45  IP: 58.213.113.*

我下载了作者的文章 并且整理了一些PDF。可以上传吗？

#fudan_abc 发表于2008-02-27 22:03:14  IP: 63.82.71.*

汗,难得您这么热情.
csdn本身应该有上传的地方,您可以上传,然后告诉大家link就可以了.
其实我们也打算整理,不过目前由于写的东西比较散,很多部分还不完整,所以不太好整理,就UHCI和EHCI来说,因为之间很多代码是共用的,又有很多相似点,所以打算两个都写完了之后,做一个对比,然后再统一整理.
而scsi那边由于涉及的东西太多,很难系统的写,只是尝试着写了一点点,目前没有时间深入详细的写,还是打算主要把usb部分写的完整详细专业一点.所以在未来的几个月里,usb部分还将是主要的写作目标.

与此同时写的是kdb,这是一个冷门话题,的确是因为工作原因要学习一点,所以不得不花时间纪录下来,这个的写作时间可能会持续很长.

PCI部分,作者近来比较忙,所以一直没写,等有空了应该会继续写.

在可以预见的一段时间内,scsi/block那部分可能不太会更新了.也许会等到明年.

#hu200298 发表于2008-02-28 12:26:59  IP: 58.213.113.*

这里有我整理的fudan_abc的专栏中已经完结的文章，pdf格式。需要可以到下面网址下载：
http://download.csdn.net/source/362984
再次感谢fudan_abc给我们提供这么优秀的文章^_^

#zsx2005 发表于2008-02-29 11:50:38  IP: 124.207.229.*

路过拜一下～写得太好了！

#di74yang 发表于2008-03-03 16:18:58  IP: 202.46.23.*

谢谢楼主和hu200298，我刚把 uhci拷贝下来，早看到就好了，拜读中。ehci连载完了吗？

#marshma 发表于2008-03-07 20:06:26  IP: 210.83.229.*

我得快点存下来，这么好的文章，万一哪一天突然让不了这个网站，岂不可惜。

望楼主早日出书（电子书）。。。。。。

#wangrenjun12 发表于2008-03-13 10:14:55  IP: 60.55.113.*

太好了，多年没见过这么好的文章，我下载过来去打印电打印去，再床上慢慢看。中国IT业的振兴就靠你们这些才子了

#自由点点 发表于2008-03-14 15:36:52  IP: 59.42.158.*

最近刚开始调试usb,来这里启蒙.
我碰到一个问题,插上u盘后,从usb(debug)信息来看,
是读status的时候,又判断出not connect的change,
返回的错误是-22.
老兄能否给点建议?硬件,软件故障?
联系方式:gongfen at gmail.com

#蛐蛐 发表于2008-03-25 15:04:39  IP: 125.83.21.*

我有个疑惑，各位高手，拜托解答下。

使用DMA传输数据时，提交URB结构后，控制器来操作，DMA又是如何开始传输的呢？DMA有时在何时初始化的呢？

#albcamus 发表于2008-04-09 14:50:42  IP: 61.148.56.*

> PCI部分,作者近来比较忙,所以一直没写,等有空了应该会继续写.

请问《我是PCI》的作者是不是 复旦人甲？ 这是今年最期待的文章了，很盼望能早日更新。 ^_^

#fudan_abc 发表于2008-04-09 21:47:21  IP: 58.60.186.*

to albcamus:
最近这几个月赶个项目，忙的如痴如醉的，呵呵，抽不出啥时间来写，过了这段时间肯定会继续写的了。

#linuxjackaroo 发表于2008-04-10 14:11:56  IP: 222.92.90.*

楼主乃一神人也。吾等当学习之，景仰之。

#wangr198 发表于2008-05-24 09:26:00  IP: 218.94.136.*

楼主太牛了！！敬仰之！学习之！

#hall919 发表于2008-06-06 10:21:59  IP: 222.66.38.*

已下pdf来观摩了

#guoxin0110 发表于2008-06-23 10:34:39  IP: 124.42.2.*

一个健康，幽默，还能耐得住寂寞，沉得下心来的博士，佩服佩服。USB那块讲的太好了。谢谢啊。呵呵

#kamingli 发表于2008-06-23 15:46:46  IP: 221.221.156.*

博主的blog已被我珍藏了。

#hongmy525 发表于2008-07-17 10:18:06  IP: 218.108.51.*

纯支持，文章好强~~~~
你们忠实的读者很多，加油！！：）

#Felk2005 发表于2008-08-06 16:41:16  IP: 10.15.1.*

刚看了几眼你的文章就喜欢上了，很喜欢你的文风。现在的书要是文字都这么轻松该多好啊！感谢你对全人类做出的贡献！

#Felk2005 发表于2008-08-06 16:41:29  IP: 10.15.1.*

刚看了几眼你的文章就喜欢上了，很喜欢你的文风。现在的书要是文字都这么轻松该多好啊！感谢你对全人类做出的贡献！

#Felk2005 发表于2008-08-06 16:44:33  IP: 10.15.1.*

另外我在百度上搜“LINUX那些事儿”，找到的都是别的网站。建议你把BLOG的名称（现在是fudan_abc的专栏）改一下，改成“LINUX那些事儿”，相信搜索起来会更容易，毕竟只有这里才是最新最全的。

#黯凄然 发表于2008-09-18 12:37:54  IP: 172.18.214.*

Hi:
仔细看过了你们的写的关于USB的系列文章,受益非浅.思考之余,还有几个细节有点疑惑:
1:关于toggle修正的问题
如果是传输错误或者是短包错误的包,都需要修正后面URB中TD的toggle值.为什么在驱动unlink或者是kill的时候,不需要修正后面URB中TD的toggle值呢?
相关操作在uhci_cleanup_queue()中.代码片段如下:
......
//如果不是QH中的第一个urb
if (qh->queue.next != &urbp->node) {
struct urb_priv *purbp;
struct uhci_td *ptd;

//urb的前一个urb
purbp = list_entry(urbp->node.prev, struct urb_priv, node);
WARN_ON(list_empty(&purbp->td_list));
//URB的前面urb中的最后一个TD
ptd = list_entry(purbp->td_list.prev, struct uhci_td,
list);
//URB的最后一个TD
td = list_entry(urbp->td_list.prev, struct uhci_td,
list);
//跳过urb的td项
ptd->link = td->link;
goto done;
}
......
如上代码所示,如果删除的urb不是qh中的第一个urb,是不会去修正toggle值的,为什么?例如,要删除的URB的前一个TD为DATA1,后一个TD也为DATA1,这样在接收方不是会报错么?


2:关于中断传输/实时传输的负载计算问题
Linux设计中,使用了uhci->load[MAX_PHASE]来统计各调度frame的负载情况,其中MAX_PHASE为32
在中断传输中,phase的计算方式为(qh->period / 2) & (MAX_PHASE - 1),int1~int128,它们的phase对应为:
0,1,2,4,8,16,0,0.它们代表的是在uhci->load[]数组中的起始位置.

0,1,2,4,8,16这几项倒还是好理解,就是对应int1,int2,int4...int32在uhci->frame[]中的起始位置.这几个间隔在前32项数组里呈一个周期重复的关系,用32项数组来表示他们的负载情况是可以的.

Int1所占的位置是0.任何间隔后面都可以跟int1.因此,在这里,起始位置0也可以被其它间隔重用

int64,int128都是以0项来表示负载的.即uhci->load[0].如果有这样的情况,int64的中断传输已经处于饱和状态.那肯定会有: uhci->load[0]即将要大于900.那这时候,int128的中断传输是加不进来的.尽管

#黯凄然 发表于2008-09-18 12:39:35  IP: 172.18.214.*

尽管uhci->frame[]中,int128所占的frame项处于空闲状态.不知道我的思考有没有错误?



3:关于实时传输带宽的占用问题

在提交实时传输的urb的时候,如果QH中有待调度的urb,此时,只会将要增加的urb加到调度队列,而不会为新加的urb计算带宽值.

在UHCI的调度中,frame数组后连ISO TD,然后再连QH.如果在对应frmae上再提交的ISO URB的话,势必会增长ISO TD链表.那挂在ISO TD后的QH中的调度就会受到影响.

基于这点考虑,为什么在QH提交新加的URB不需要计算占用QH的带宽值呢?

对于中断传输,这点倒是正常的,因为中断传输的TD是挂在QH下,QH默认是广度搜索,即不管QH下挂了多少TD,每次调度到QH的时候,只能处理一个TD



这几个问题思考已久,但始终甚为不解,不知道大侠能否在万忙之中,抽空为我答疑否?

谢谢