00000001.htm

一份很好的linux入门资料

&nbsp;<BR>
本章末也介绍了一些被提出来的演算法,比较有趣的是three-level&nbsp;scheduler.&nbsp;<BR>
要同时满足任意的time-sharing和real-time的需求是不太可能,&nbsp;因为资&nbsp;<BR>
源有限.three-level&nbsp;scheduler引进了节制的观念,&nbsp;real-time&nbsp;process要先注册,&nbsp;<BR>
kernel能够reserve足够的resource才允许执行.而kernel也会reserve适当的资源,&nbsp;<BR>
确保time-sharing&nbsp;processes不会动弹不得.&nbsp;<BR>
&nbsp;<BR>
在网路负荷过重的时候,kernel只要处理network&nbsp;activity就来不及了,&nbsp;<BR>
会导致receive&nbsp;livelock情形发生.&nbsp;3-level&nbsp;scheduler可以把network&nbsp;<BR>
的处理当成real-time&nbsp;task,给予适当的配额就好了.不够用就drop掉嘛.&nbsp;<BR>
这样子保证大家有饭吃,不会活当机!&nbsp;[&nbsp;real-time&nbsp;task有固定的priority,&nbsp;<BR>
和固定的resource配额&nbsp;--&nbsp;kernel保证他会有这些东西,就像有人保证每天&nbsp;<BR>
都会给你一颗面包一样,不会说放一堆面包给大家抢(time-sharing),一天&nbsp;<BR>
有时候可以抢好几颗,有时一颗也抢不到,要是有一个人很会抢,那其他的&nbsp;<BR>
人就要饿死了!]&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;6&nbsp;Interprocess&nbsp;Communications&nbsp;<BR>
&nbsp;<BR>
本章对IPC&nbsp;programming做了一些复习.&nbsp;<BR>
传统的Unix&nbsp;IPC机制只有pipe.&nbsp;System&nbsp;V引进了SYSV&nbsp;IPC,包含semaphore,&nbsp;<BR>
shared&nbsp;memory和message&nbsp;queue.&nbsp;System&nbsp;V的STREAMS架构也是Unix&nbsp;<BR>
重要的IPC机制之一.&nbsp;本书没有提到BSD&nbsp;socket介面,假设这个也是&nbsp;<BR>
IPC的话.&nbsp;Mach是一message&nbsp;passing为中心的kernel(message-passing&nbsp;<BR>
kernel),大部分的系统服务都是靠交换讯息达成的,所以本章也花了&nbsp;<BR>
不少篇幅介绍之.&nbsp;<BR>
&nbsp;<BR>
特别的有:&nbsp;<BR>
SVR4使用STREAMS来实作pipe,所以SVR4&nbsp;pipe是bi-directional.一个&nbsp;<BR>
pipe两端都可读又可写.其他的UNIX则要用一对pipe才可达到相同目的.□&nbsp;<BR>
&nbsp;<BR>
System&nbsp;V&nbsp;semaphore有一个缺点:&nbsp;allocation和initialization不是单一步骤,&nbsp;<BR>
可以导致race&nbsp;condition发生.&nbsp;<BR>
&nbsp;<BR>
在System&nbsp;V&nbsp;STREAMS下,&nbsp;IPC的message&nbsp;queue几乎可以淘汰了.&nbsp;STREAMS&nbsp;<BR>
功能强大(see最後一章)&nbsp;,可以取代掉所有message&nbsp;queue的功能.&nbsp;<BR>
&nbsp;<BR>
本章最深奥的就是介绍Mach&nbsp;IPC了.&nbsp;相信大家也最感兴趣.&nbsp;<BR>
message&nbsp;:=&nbsp;一些有型别的data.型别分为两类,&nbsp;simple&nbsp;data,即一般的&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;资料.&nbsp;complex&nbsp;data,可能为out-of-line&nbsp;memory或是port&nbsp;rights.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(後述)&nbsp;<BR>
&nbsp;<BR>
port&nbsp;:=&nbsp;a&nbsp;protected&nbsp;queue&nbsp;of&nbsp;messages.&nbsp;简单的说就是message&nbsp;queue的id.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;跟file&nbsp;descriptor差不多,为一个整数,代表一个message&nbsp;queue.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;message必须送到port(通信埠),而不是送给某个task或thread.&nbsp;<BR>
port&nbsp;rights&nbsp;:=&nbsp;一个port的存取权限,&nbsp;send&nbsp;rights和receive&nbsp;rights.这种&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;存取权是以task为控制对象,而不是thread.&nbsp;send&nbsp;rights允许&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;一个task(的所有threads)对某个port传送讯息.&nbsp;receive&nbsp;rights&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;类推.&nbsp;一个port可以把send&nbsp;rights给好几个tasks,但是只能有&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;一个task有receive&nbsp;rights&nbsp;--&nbsp;拥有该port的task.&nbsp;有receive&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;right的task,就自动有send&nbsp;right)&nbsp;<BR>
out-of-line&nbsp;memory&nbsp;:=&nbsp;传送大量的资料,&nbsp;message直接copy很没效率.&nbsp;透过&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;virtual&nbsp;memory系统改memory&nbsp;mapping,用copy-on-write的方式可&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;以改进.&nbsp;in-line&nbsp;memory传送是message从sender&nbsp;copy到kernel,&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;再由kernel&nbsp;copy-to&nbsp;receiver.&nbsp;out-of-line&nbsp;memory则是kernel&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;改一些virtual&nbsp;memory&nbsp;mapping,&nbsp;只有在sender/receiver&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;modify该资料时产生copy-on-write的page&nbsp;fault,&nbsp;只发生&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;了一次copy.&nbsp;<BR>
&nbsp;<BR>
complex&nbsp;data和simple&nbsp;data的不同是complex&nbsp;data需要kernel处理message的&nbsp;<BR>
内容,再翻译给receiver.&nbsp;simple&nbsp;data直接transfer就可以了.&nbsp;<BR>
&nbsp;<BR>
每个task拥有task_self&nbsp;port的send-right.&nbsp;task_self&nbsp;port是kernel&nbsp;<BR>
拥有的.&nbsp;task透过task_self&nbsp;port与kernel沟通.task另外有一个task_notify&nbsp;<BR>
port的receive&nbsp;rights,用来接收(kernel)来的message.&nbsp;thread有thread_self&nbsp;<BR>
port,用来送message给kernel,&nbsp;reply用来接收kernel传回来的reply&nbsp;<BR>
(比如system&nbsp;call,&nbsp;rpc...).&nbsp;thread用的port,其&nbsp;port&nbsp;rights为task所有.&nbsp;<BR>
另外还有exception&nbsp;port用来处理exception/signal/debug.前面讲过了.&nbsp;<BR>
&nbsp;<BR>
一个message内的资料结构有一栏为reply_port.&nbsp;如果sender需要reply就在&nbsp;<BR>
此栏填入自己拥有的port.(所以自己就有receive&nbsp;right).&nbsp;message&nbsp;passing之中,&nbsp;<BR>
kernel就会为receiver建立一个到reply_port的send&nbsp;right.&nbsp;<BR>
&nbsp;<BR>
Port&nbsp;Name&nbsp;Space&nbsp;<BR>
&nbsp;<BR>
port是一个整数,和file&nbsp;descriptor一样,&nbsp;每个task拥有独自的命名空间.&nbsp;<BR>
ie.不同task的port&nbsp;id如果一样,&nbsp;say,编号100,并不是指到相同的port.&nbsp;<BR>
&nbsp;<BR>
Port&nbsp;translations&nbsp;<BR>
&nbsp;<BR>
由於port&nbsp;name&nbsp;space是task间互相独立的.&nbsp;kernel必须建立一个translation&nbsp;<BR>
来记住谁是谁.&nbsp;(Unix是用global&nbsp;file&nbsp;descriptor&nbsp;table达成的).&nbsp;<BR>
&nbsp;<BR>
研读本章最令人感到不解的是port&nbsp;right.&nbsp;因为port的kernel&nbsp;data&nbsp;structure里面&nbsp;<BR>
没有port&nbsp;right的纪录.&nbsp;那到底mach把port&nbsp;right资料藏到哪里去呢?搞了老半天,&nbsp;<BR>
原来就是port&nbsp;translation.&nbsp;kernel的port&nbsp;translation就是port&nbsp;<BR>
right.大胆一点说,&nbsp;<BR>
就是mach&nbsp;kernel根本没有port&nbsp;right的观念.只要在port&nbsp;translation查的到的&nbsp;<BR>
port,就可以送message就对了.&nbsp;<BR>
&nbsp;<BR>
port&nbsp;translations的每个entry,代表的都是一个connection.&nbsp;<BR>
一个entry包含下列资料:&nbsp;&lt;task,&nbsp;local_name,&nbsp;kport,&nbsp;type&gt;,代表的意义是&nbsp;<BR>
一个task的id是local_name的port,&nbsp;拥有对kport&nbsp;(一个指向kernel的port&nbsp;data&nbsp;<BR>
structure的指标)的port&nbsp;right.&nbsp;port&nbsp;right是receive还是send呢?由type决定.&nbsp;<BR>
local_name就是所谓的port&nbsp;right的名字.&nbsp;<BR>
&nbsp;<BR>
msg_send()用&nbsp;&lt;task,&nbsp;local_name,*,*&gt;找到kport,再由&nbsp;<BR>
&lt;port.owner_task,*,port,*&gt;找到该port於task的local_name.&nbsp;<BR>
&nbsp;<BR>
task删掉一个port,&nbsp;kernel要找到kport,再除掉&lt;*,*,&nbsp;kport,&nbsp;*&gt;,并且&nbsp;<BR>
通知相关的task.&nbsp;<BR>
&nbsp;<BR>
task结束要清掉&lt;task,*,*,*&gt;的所有kports.&nbsp;<BR>
&nbsp;<BR>
Kernel用两个hash&nbsp;table来快速存取translation,&nbsp;TP_table&nbsp;(key=&lt;task,port&gt;)&nbsp;<BR>
TL_table(key=&lt;task,local_name&gt;)&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
Port&nbsp;Rights&nbsp;Transfer&nbsp;<BR>
&nbsp;<BR>
普通的port&nbsp;right&nbsp;transfer&nbsp;embed到message&nbsp;header里面,就是前面提&nbsp;<BR>
的reply&nbsp;port.这样子的port&nbsp;right&nbsp;transfer是把自己的port的send&nbsp;&nbsp;<BR>
right送给别人用的.比较复杂的就要用complex&nbsp;message.&nbsp;message里面,&nbsp;<BR>
告诉kernel要把他人的(send&nbsp;right)送给第三者.&nbsp;(本章没有提到详情).&nbsp;<BR>
这是mach&nbsp;name&nbsp;server的功能:除了之前提到的port之外,&nbsp;mach的每个&nbsp;<BR>
task还有一个bootstrap&nbsp;port,透过此port,&nbsp;task可以送message到mach&nbsp;<BR>
的name&nbsp;server.&nbsp;name&nbsp;server提供了存取其他server的机制.过程如下:&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;1.&nbsp;server向name&nbsp;server注册(透过bootstrap&nbsp;port)&nbsp;<BR>
&nbsp;&nbsp;2.&nbsp;client向name&nbsp;server询问如何与server沟通.&nbsp;<BR>
&nbsp;&nbsp;3.&nbsp;name&nbsp;server&nbsp;transfer一个到server的send&nbsp;right给client&nbsp;<BR>
&nbsp;&nbsp;4.&nbsp;client得到一个可以和server沟通的port,利用此port和server联系.&nbsp;<BR>
&nbsp;<BR>
Mach的理想是把许多Unix&nbsp;kernel的机制变成user&nbsp;level&nbsp;server.&nbsp;name&nbsp;server&nbsp;<BR>
是开启这个机制的钥匙.&nbsp;<BR>
&nbsp;<BR>
Port&nbsp;Interpolation&nbsp;<BR>
&nbsp;<BR>
Port&nbsp;interpolation可以让别人偷走某task的send/receive&nbsp;rights.&nbsp;<BR>
Mach提供task_extract_send(),&nbsp;task_insert_send(),&nbsp;task_extract_receive(),&nbsp;<BR>
task_insert_receive()来干这档事.&nbsp;debugger就是这样拦截ipc&nbsp;message的.&nbsp;<BR>
&nbsp;<BR>
netmsgserver&nbsp;<BR>
&nbsp;<BR>
另外一个和Port&nbsp;interpolation很像的机制,就是Mach的remote&nbsp;IPC.&nbsp;其实&nbsp;<BR>
说穿了,&nbsp;Mach&nbsp;remote&nbsp;IPC的达成只是靠netmsgserver作proxy而已.&nbsp;<BR>
Mach可以这样做的原因有二,&nbsp;第一个是send_msg()只要知道自己的&nbsp;<BR>
local_port_name就行了,他不需要知道这个port怎样连,连到哪里去.这是&nbsp;<BR>
port&nbsp;name&nbsp;server和netmsgserver的工作,&nbsp;task尽管往name&nbsp;server告诉他的&nbsp;<BR>
port送就可以了.第二点是senders是匿名的.&nbsp;receiver无法从message得知&nbsp;<BR>
sender是谁.所以netmsgserver可以提供完全透明的服务.&nbsp;<BR>
&nbsp;<BR>
Mach&nbsp;3.0对IPC的问题做了一些改进,自己看吧.&nbsp;这是Mach&nbsp;2.5&nbsp;IPC&nbsp;<BR>
会遇到的问题.&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;7&nbsp;Synchronization&nbsp;and&nbsp;Multiprocessors&nbsp;<BR>
&nbsp;<BR>
提到Kernel&nbsp;synchronization的演算法和资料结构.特别是multiprocessor&nbsp;<BR>
下的问题.&nbsp;multiprocessor最大的问题在virtual&nbsp;memory的cache/tlb&nbsp;<BR>
synchronize&nbsp;的问题.本章没有提到,&nbsp;延至virtual&nbsp;memory再讨论.&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;7讨论的内容颇为琐碎,&nbsp;不适合摘要.&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;8&nbsp;File&nbsp;System&nbsp;Interface&nbsp;and&nbsp;Framework&nbsp;<BR>
&nbsp;<BR>
本节前半段讨论(复习)跟filesystem有关的系统呼叫.&nbsp;後半段讨论mordern&nbsp;<BR>
Unix的VFS&nbsp;(vnode)架构,&nbsp;亦即,&nbsp;kernel处理file&nbsp;system的方法.&nbsp;下一个chapter&nbsp;<BR>
主要讨论file&nbsp;system在disk上的layout.&nbsp;<BR>
&nbsp;<BR>
s5fs是unix早期(System&nbsp;V&nbsp;r4以前)档案系统,特色是简单但功能尚可,最大&nbsp;<BR>
的缺点是有14个字的档名限制.&nbsp;4.2BSD设计了Fast&nbsp;File&nbsp;System,&nbsp;FFS,&nbsp;<BR>
提供了较优的performance和功能.&nbsp;FFS受到广大的欢迎,&nbsp;最後被SVR4&nbsp;<BR>
所采用.&nbsp;FFS又称为UFS&nbsp;(UNIX&nbsp;File&nbsp;System)&nbsp;<BR>
&nbsp;<BR>
早期的Unix&nbsp;kernel不能同时支援两种以上的档案系统.&nbsp;各家&nbsp;<BR>
都有解决之道.&nbsp;AT&amp;T用file&nbsp;system&nbsp;switch,&nbsp;DEC用gnode/gfs,&nbsp;Sun&nbsp;<BR>
所提出的vnode/vfs最广为接受,&nbsp;最後赢得胜利,成为SVR4的&nbsp;<BR>
一部份.&nbsp;<BR>
&nbsp;<BR>
inode&nbsp;是Unix特有的观念.&nbsp;Unix&nbsp;kernel利用inode来作为他对档案的介面.&nbsp;<BR>
一个inode代表一个档案,&nbsp;记录了kernel存取该档案所需要用到的资料,&nbsp;<BR>
以及该档案的属性等等.名叫inode的原因是因为本资料结构的大部份&nbsp;<BR>
内容皆由on-disk的inode而来.Unix&nbsp;file&nbsp;system&nbsp;在disk上的image不用档名&nbsp;<BR>
而用整数(i-number)来表示每一个档案.&nbsp;目录只是一个较为特别的档案,&nbsp;<BR>
记录i-number和档名的对照而已.有了i-number,kernel才找得到inode,&nbsp;<BR>
也就是记录档案存放位置与属性的地方.一般称在disk上的inode为on-disk&nbsp;<BR>
inode,被kernel读进记忆体,使用中的inode为in-core&nbsp;inode.&nbsp;<BR>
&nbsp;<BR>
vnode/vfs的概念是把原来in-core&nbsp;inode物件化成为&nbsp;virtual&nbsp;class.&nbsp;<BR>
vnode提供一个抽象化的介面.&nbsp;kernel要对档案的所有操作接&nbsp;<BR>