<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 403, comments - 310, trackbacks - 0, articles - 7
      BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

    2008年5月24日

    http://blog.yxwang.me/

    posted @ 2009-12-30 09:48 ZelluX 閱讀(470) | 評論 (0)編輯 收藏

    寫了好幾天的代碼因為還有bug沒de掉,沒commit到svn上

    然后不知怎么的在make的時候生成的kernel沒變化,于是直接make world,然后發(fā)現(xiàn)linux kernel目錄被清空了。。。

    只能明天靠記憶慢慢補(bǔ)了,皚皚。

    posted @ 2009-04-02 01:38 ZelluX 閱讀(893) | 評論 (3)編輯 收藏

    yifanw大牛半個月前發(fā)在c++版上的,怕以后忘了看先放在這備個忘吧

    白話入門
    http://www.newsmth.net/bbscon.php?bid=335&id=250203

    白話解決方案
    http://www.newsmth.net/bbscon.php?bid=335&id=250237

    白話參考文獻(xiàn)
    http://www.newsmth.net/bbscon.php?bid=335&id=250260

    posted @ 2009-03-25 22:14 ZelluX 閱讀(845) | 評論 (2)編輯 收藏

    最近有點(diǎn)忙,今天總算在某個課題deadline前把論文憋出來交上去了。跑這兒來推薦兩篇上個月看到的比較有意思的paper,都比較偏理論,也很老。

    今天寫介紹下第一篇,劍橋大學(xué)的A Logic of Authentication,中了SOSP '89,整理后發(fā)在1990年的ACM Transactions on Computer Systems上。
    http://www.csie.fju.edu.tw/~yeh/research/papers/os-reading-list/burrows-tocs90-logic.pdf

    (另一篇是Safe Kernel Extensions Without Run-Time Checking,改天再寫點(diǎn)介紹)

    這篇paper的主要工作是通過構(gòu)造一種多種類的模態(tài)邏輯(many-sorted model logic),來檢查網(wǎng)絡(luò)中驗證協(xié)議的安全性。

    基礎(chǔ)的邏輯分三部分:
    原語,如驗證雙方A和B,以及服務(wù)器S,下文用P Q R泛指
    密鑰,如K_ab代表a和b之間的通訊密鑰,K_a代表a的公鑰,{K_a}^{-1}代表對應(yīng)的私鑰,下文用K泛指
    公式(或者陳述),用N_a, N_b等表示,下文用X Y泛指

    接下來定義以下約定(constructs)
    P 信任 X: 原語P完全信任X
    P 看到 X: 有人發(fā)送了一條包含X的信息給P,P可以閱讀它或者重復(fù)它(當(dāng)然通常是在做了解密操作后)
    P 說了 X: 原語P發(fā)送過一條包含X的信息,同時也可以確定P是相信X的正確性的
    P 控制 X: P可以判定X的正確與否。例如生成密鑰的服務(wù)器通常被默認(rèn)為擁有對密鑰質(zhì)量的審核權(quán)。
    X 是新鮮的: 在此之前X沒有被發(fā)送過。這個事實可以通過綁定一個時間戳或者其他只會使用一次的標(biāo)記來證明。
    P <-K-> Q: P和Q可以通過共享密鑰K進(jìn)行通訊,且這個K是好的,即不會被P Q不信任的原語知道。
    K-> P: P擁有K這么一個公鑰,且它對應(yīng)的解密密鑰K^{-1}不會被其他不被P信任的原語知道。
    P <=X=> Q: X是一個只被P和Q或者P和Q共同信任的原語知道的陳述,只有P和Q可以通過X來相互證明它們各自的身份,X的一個例子就是密碼。
    {X}_K: X是一個被K加密了的陳述
    <X>_Y: 陳述X被Y所綁定,Y可以用來證明發(fā)送X的人的身份

    好了,總算把這些約定列完了,然后來看看通過這些約定能推出一些什么東東:
    如果 P 相信 (P <-K-> Q), 且 P 看到 {X}_K,那么 P 相信 Q 說了 X。
    這個例子很簡單,既然P Q有安全的密鑰K,那么P看到通過K加密后的X肯定認(rèn)為就是Q發(fā)出的。

    又比如,
    如果 P 相信 Q 控制 X,P 相信 (Q 相信 X),那么 P 相信 X
    也很容易理解,既然 P 相信 Q 的判斷,那么 Q 相信什么 P 自然也就相信了。

    再舉一個例子
    如果 P 相信 Y 是新鮮的,那么 P 相信 (X, Y) 也是新鮮的。
    這里(X, Y)表示 X 和 Y 的簡單拼接,也很容易理解,既然 Y 之前沒出現(xiàn)過,那么 X 和 Y 的組合自然也沒出現(xiàn)過。

    一個協(xié)議要被定義為安全,最起碼要滿足
    A 相信 A <-K->B,B 相信 A <-K->B
    即雙方要互相信任密鑰是安全的

    再健壯一點(diǎn)的協(xié)議,還要滿足
    A 相信 (B 相信 (A 相信 A <-K->B)),反之一樣
    即A B不僅相信密鑰,也相信對方相信自己對密鑰的信任。

    有了這些簡單卻強(qiáng)大的工具后,接下來這篇paper開始著手分析一些協(xié)議,包括Kerberos協(xié)議,Andrew Secure RPC 握手協(xié)議等,還指出了其中的一些問題和改進(jìn)措施,例如CCITT X.509 協(xié)議中可以通過重復(fù)發(fā)送一條老的信息來模仿成加密雙方中的一員。

    具體的分析不貼上來了,一方面對于我這個不熟悉TeX的人來說碼公式實在麻煩,另一方面我實在困死了 =_=

    建議有興趣的朋友好好看看這篇經(jīng)典paper

    posted @ 2009-03-18 03:10 ZelluX 閱讀(2513) | 評論 (0)編輯 收藏

    Some notes on lock-free and wait-free algorithms

    http://www.audiomulch.com/~rossb/code/lockfree/

    ?

    NOBLE - a library of non-blocking synchronization protocols

    http://www.cs.chalmers.se/~noble/

    ?

    An optimistic approach to lock-free FIFO queues (Distributed Computing 2008)

    http://people.csail.mit.edu/edya/publications/OptimisticFIFOQueue-journal.pdf

    ?

    High performance dynamic lock-free hash tables and list-based sets

    http://portal.acm.org/citation.cfm?id=564870.564881

    ?

    Concurrent Programming Without Locks

    http://www.cl.cam.ac.uk/research/srg/netos/papers/2007-cpwl.pdf

    ?

    Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms

    http://www.research.ibm.com/people/m/michael/podc-1996.pdf

    posted @ 2009-03-17 20:48 ZelluX 閱讀(2728) | 評論 (0)編輯 收藏

    抓抓大牛的博客(http://www.cnblogs.com/JeffreyZhao)上看到的鏈接,原文地址是
    http://blog.objectmentor.com/articles/2009/02/26/10-papers-every-programmer-should-read-at-least-twice

    貌似我只讀過那篇Reflections on Trusting Trust,水木的Programming版搜索作者為modico的帖子的前四篇就是介紹這篇paper的。

    先貼個列表,改天好好讀一讀
    1. On the criteria to be used in decomposing systems into modules – David Parnas
    2. A Note On Distributed Computing – Jim Waldo, Geoff Wyant, Ann Wollrath, Sam Kendall
    3. The Next 700 Programming Languages – P. J. Landin
    4. Can Programming Be Liberated from the von Neumann Style? – John Backus
    5. Reflections on Trusting Trust – Ken Thompson
    6. Lisp: Good News, Bad News, How to Win Big – Richard Gabriel
    7. An experimental evaluation of the assumption of independence in multiversion programming – John Knight and Nancy Leveson
    8. Arguments and Results – James Noble
    9. A Laboratory For Teaching Object-Oriented Thinking – Kent Beck, Ward Cunningham
    10. Programming as an Experience: the inspiration for Self – David Ungar, Randall B. Smith

    作者博客后面還新增了對它們的簡要評論

    posted @ 2009-03-02 18:24 ZelluX 閱讀(782) | 評論 (0)編輯 收藏

    2009-01-08

    以前碰到這個問題都得先重啟PieTTY然后用screen -x恢復(fù)到原來的工作界面,今天不知怎么的emacs里C-x C-s按了就掛起,只能google。

    傳說中,早期的終端會遇到顯示字符的速度慢于接收字符的速度,為了解決這個問題,C-s用于先掛起當(dāng)前終端,在數(shù)據(jù)傳輸之后用C-q恢復(fù)顯示。所以最簡單的解決方法就是在掛起后按C-q。

    不過我的WinXP中C-q已經(jīng)和快速啟動工具(寢室里是Turbo Launcher,實驗室的是Launchy)綁定了,也懶得為了這么個問題改操作習(xí)慣,于是再次google,終于找到一個一勞永逸的方法,以bash為例,在~/.bashrc中加入一行

    stty -ixoff -ixon

    即可。另外這樣設(shè)置后似乎恢復(fù)了C-s在bash中正向增量查找的功能。恩。


    posted @ 2009-02-17 12:12 ZelluX 閱讀(2145) | 評論 (0)編輯 收藏

    今年的ASPLOS '09上zhou yuanyuan也有一篇關(guān)于如何concurrent program中發(fā)現(xiàn)隱藏的atomicity violation bugs的paper,里面提到了這篇paper

    2008-11-30

    OSDI '08上MSR發(fā)的paper,針對并發(fā)編程中難以發(fā)現(xiàn)的bug問題。

    paper的內(nèi)容主要分兩大塊。

    一是如何在發(fā)現(xiàn)bug的時候記錄下線程的運(yùn)行先后(thread interleaving),途徑是在線程API和用戶程序多寫一層wrapper functions,這里還有一些其他的問題,比如只記錄下了thread interleaving的話出現(xiàn)data race怎么解決等。

    另外一塊內(nèi)容是如何遍歷出給定程序運(yùn)行后所能產(chǎn)生的結(jié)果的集合,加入這個能實現(xiàn)的話那就能把所有隱藏的bug都找出來了。但是這個搜索空間很大,是 指數(shù)級的,的一個結(jié)論就是:給定一個程序有n個的線程,所有線程共完成k條指令,那么c次占先調(diào)度后線程的排列情況數(shù)的復(fù)雜度是k^{c}的,所以在實現(xiàn)遍歷代碼的時候必須有效的降低k和c的值。

    posted @ 2009-02-17 11:30 ZelluX 閱讀(631) | 評論 (0)編輯 收藏

    問題現(xiàn)象:上校內(nèi)、一些國內(nèi)論壇時經(jīng)常出現(xiàn)連接重置(Connect reset)錯誤,而上google baidu等網(wǎng)站卻沒什么問題。ping那些有問題的網(wǎng)站的結(jié)果很正常。

    google了一堆關(guān)鍵詞后終于發(fā)現(xiàn)問題出在MTU上,至少在偶的本本上運(yùn)行
    sudo ifconfig eth1 mtu 1412
    就沒問題了(eth1是無線網(wǎng)卡)

    p.s 多謝萬熊? XD

    posted @ 2009-01-29 00:30 ZelluX 閱讀(883) | 評論 (2)編輯 收藏

         摘要: 發(fā)信人: linelf (水水), 信區(qū): Real_Estate
    標(biāo) 題: 蘇南經(jīng)濟(jì)模式興衰親歷記zz
    發(fā)信站: 日月光華 (2009年01月15日20:39:22 星期四)

      閱讀全文

    posted @ 2009-01-21 14:47 ZelluX 閱讀(900) | 評論 (0)編輯 收藏

    Bruce Eckel的一篇日志建議把self從方法的參數(shù)列表中移除,并把它作為一個關(guān)鍵字使用。
    http://www.artima.com/weblogs/viewpost.jsp?thread=239003

    Guido的這篇日志說明了self作為參數(shù)是必不可少的。
    http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

    第一個原因是保證foo.meth(arg)和C.meth(foo, arg)這兩種方法調(diào)用的等價(foo是C的一個實例),關(guān)于后者可以參見Python Reference Manual 3.4.2.3。這個原因理論上的意義比較大。

    第二個原因在于通過self參數(shù)我們可以動態(tài)修改一個類的行為:

    # ?Define?an?empty?class:
    class ?C:
    pass
    ?
    # ?Define?a?global?function:
    def ?meth(myself,?arg):
    myself.val?
    = ?arg
    return ?myself.val
    ?
    # ?Poke?the?method?into?the?class:
    C.meth? = ?meth

    這樣類C就新增了一個meth方法,并且所有C的實例都可以通過c.meth(newval)調(diào)用這個方法。

    前面兩個原因或許都可以通過一些workaround使得不使用self參數(shù)時實現(xiàn)同樣的效果,但是在存在decorator的代碼中Bruce的方法存在致命的缺陷。(關(guān)于decorator的介紹可以參見http://www.python.org/dev/peps/pep-0318/)

    根據(jù)修飾對象,decorator分兩種,類方法和靜態(tài)方法。兩者在語法上沒有什么區(qū)別,但前者需要self參數(shù),后者不需要。而Python在實 現(xiàn)上也沒有對這兩種方法加以區(qū)分。Bruce日志評論中有一些試圖解決decorator問題的方法,但這些方法都需要修改大量底層的實現(xiàn)。

    最后提到了另一種語法糖實現(xiàn),新增一個名為classmethod的decorator,為每個方法加上一個self參數(shù),當(dāng)然這種實現(xiàn)也沒必要把self作為關(guān)鍵字使用了。不過我覺得這么做還不如每次寫類方法時手工加個self =_=


    posted @ 2008-11-15 19:58 ZelluX 閱讀(2536) | 評論 (2)編輯 收藏

    2008年評出了1998年最具影響力的PLDI論文,獲獎?wù)撐牡淖髡邔⒎謹(jǐn)?000美元的獎金(還沒一等獎學(xué)金多 -_-b)

    2008 (for 1998): The Implementation of the Cilk-5 Multithreaded Language, Matteo Frigo, Charles E. Leiserson, and Keith H. Randall

    Citation

    “The 1998 PLDI paper “Implementation of the Cilk-5 Multithreaded Language” by Matteo Frigo, Charles E. Leiserson, and Keith H. Randall introduced an efficient form of thread-local deques to control scheduling of multithreaded programs. This innovation not only opened the way to faster and simpler runtimes for fine-grained parallelism, but also provided a basis for simpler parallel recursive programming techniques that elegantly extend those of sequential programming. The stack-like side of a deque acts just like a standard procedure stack, while the queue side enables breadth-first work-stealing by other threads. The work-stealing techniques introduced in this paper are beginning to influence common practice, such as the Intel Threading Building Blocks project, an upcoming standardized fork-join framework for Java, and a variety of projects at Microsoft.”

    另外前幾年的獲獎paper有:
    2007 (for 1997): Exploiting Hardware Performance Counters with Flow and Context Sensitive Profiling, Glenn Ammons, Thomas Ball, and James R. Larus

    2006 (for 1996): TIL: A Type-Directed Optimizing Compiler for ML, David Tarditi, Greg Morrisett, Perry Cheng, Christopher Stone, Robert Harper, and Peter Lee

    2005 (for 1995): Selective Specialization for Object-Oriented Languages, Jeffrey Dean, Craig Chambers, and David Grove

    2004 (for 1994): ATOM: a system for building customized program analysis tools, Amitabh Srivastava and Alan Eustace

    2003 (for 1993): Space Efficient Conservative Garbage Collection, Hans Boehm

    2002 (for 1992): Lazy Code Motion, Jens Knoop, Oliver Rüthing, Bernhard Steffen.

    2001 (for 1991): A data locality optimizing algorithm, Michael E. Wolf and Monica S. Lam.

    2000 (for 1990): Profile guided code positioning, Karl Pettis and Robert C. Hansen.

    posted @ 2008-10-17 20:08 ZelluX 閱讀(534) | 評論 (2)編輯 收藏

    兩者配合,更完美的知識管理方案

    http://hi.baidu.com/qq303520912/blog/item/de5cba082db83e36e924889e.html

    Endnote是目前國內(nèi)科研人員使用最多的文獻(xiàn)管理軟件,功能最完備,各數(shù)據(jù)庫或大學(xué)圖書館等和它的兼容也是最好。它的Filter和style 也最為豐富,而且可以自己創(chuàng)建修改。看看周圍的人,大部分都是Endnote的用戶。   Zotero作為一個新的文件管理系統(tǒng),與Endnote相比還是稚嫩了些,特別對于國內(nèi)數(shù)據(jù)庫的支持不佳,更是限制了它的應(yīng)用。

    不過,Zotero作為Firefox瀏覽器的插件,還是有一些特別之處。

    第一,便攜。Firefox是有Portable版本的,當(dāng)然Zotero也就是Portable了,也就是說可以把火狐和Zotero放到U盤里,在任何一臺電腦上都可以 使用。而Endnote就沒有這么方便了。

    第二,便利。使用電腦時,我們使用瀏覽器的時間要大大多于Endnote的時間,遇到有用的文獻(xiàn)、網(wǎng)頁或者需要做筆記,直接使用Zotero更加省時省力。而且它自動收集網(wǎng)頁中文獻(xiàn)信息的功能也大大方便了操作。

    第三, 分享。EndnoteX以后可以把一個library發(fā)送成一個檔案文件(.enlx),使得文獻(xiàn)交換更為方便。不過有時我們只需要幾條文獻(xiàn)時,這樣操作 就大動干戈了。當(dāng)然Endnote也支持所選部分文獻(xiàn)的導(dǎo)出,但這樣有不能夠?qū)С龈郊▓D片、PDF等(此處為個人經(jīng)驗,是否Endnote也能導(dǎo)出 附件來還望您不吝賜教)。而Zotero就可以實現(xiàn)某條文獻(xiàn)所有內(nèi)容(題錄、筆記、附件)的全部導(dǎo)出,而且可以為另一Zotero用戶所完整接受。

    第四,跟蹤文獻(xiàn)的收集。很多數(shù)據(jù)都支持檢索式或者引文的提醒,會隨時把新的內(nèi)容發(fā)送到郵箱或者以RSS的形式發(fā)布。一般來說,查看這些都需要瀏覽器。有了Zotero,我們可以在查看的同時收集下有用的文獻(xiàn)信息。

    Zotero更適合于在日常工作、學(xué)習(xí)甚至娛樂時使用,而Endnote更適合在有明確目的時使用。有人說Zotero更像“知識管理軟件”, 而 Endnote就是為文獻(xiàn)服務(wù)的。兩者可以實現(xiàn)互補(bǔ),在日常工作中使用Zotero收集零散的資料,積累一定量之后將文獻(xiàn)信息導(dǎo)入到Endnote中,使 用Endnote管理、引用文獻(xiàn)信息。至于PDF、圖片等附件的管理,我還是建議使用Zotero,方便且可以完整導(dǎo)出。

    下面談一下Zotero和Endnote中文獻(xiàn)的互相導(dǎo)入。

    Zotero導(dǎo)入Endnote:
    1 選定文獻(xiàn),右鍵點(diǎn)選”export selected items”;如果是導(dǎo)入整個Library或者cellection可在相應(yīng)圖標(biāo)上右鍵點(diǎn)選;
    2 在彈出的對話框中選擇導(dǎo)出的格式為”Refer/BibIX”, 選擇文件目錄,保存文件,格式為.txt;
    3 在Endnote中打開一個library,執(zhí)行“files-import”;
    4 在對話框中選擇剛才的.txt文件, Impott Option選Refer/BibIX,Text Translation選Unicode(UTF-8)。點(diǎn)確定后即可導(dǎo)入。

    Endnote導(dǎo)入Zotero:
    1 選擇文獻(xiàn)后,執(zhí)行“files-export”;
    2 選擇Output Style為Endnote Export,命名后導(dǎo)入,得到.txt文件。
    3 在Zotero中執(zhí)行“actions-import” ,選擇得到的文件,點(diǎn)確定即可導(dǎo)入。
    上述導(dǎo)入方式僅能實現(xiàn)文獻(xiàn)題錄的導(dǎo)入。

    posted @ 2008-10-17 20:07 ZelluX 閱讀(8777) | 評論 (0)編輯 收藏

    BBS上的一個帖子,問題是
    def?a():
    ????
    def?b():
    ????????x?
    +=?1
    ?
    ????x?
    =?1
    ????
    print?"a:?",?x
    ????b()
    ????
    print?"b:?",?x
    ?
    def?c():
    ????
    def?d():
    ????????x[0]?
    =?[4]
    ????x?
    =?[3]
    ????
    print?"c:?",?x[0]
    ????d()
    ????
    print?"d:?",?x[0]

    運(yùn)行a()會報UnboundLocalError: local variable ‘x’ referenced before assignment
    但是運(yùn)行c()會正確地顯示3和4。

    原因在于原因在于CPython實現(xiàn)closure的方式和常見的functional language不同,采用了flat closures實現(xiàn)。

    “If a name is bound anywhere within a code block, all uses of the name within the block are treated as references to the current block.”

    在第一個例子中,b函數(shù)x += 1對x進(jìn)行賦值,rebind了這個對象,于是Python查找x的時候只會在local environment中搜索,于是就有了UnboundLocalError。

    換句話說,如果沒有修改這個值,比如b中僅僅簡單的輸出了x,程序是可以正常運(yùn)行的,因為此時搜索的范圍是nearest enclosing function region。

    而d方法并沒有rebind x變量,只是修改了x指向的對象的值而已。如果把賦值語句改成x = [4],那么結(jié)果就和原來不一樣了,因為此時發(fā)生了x的rebind。

    所以Python中的closure可以理解為是只讀的。

    另外第二個例子也是這篇文章中提到的一種workaround:把要通過inner function修改的變量包裝到數(shù)組里,然后在inner function中訪問這個數(shù)組。

    至于為什么Python中enclosed function不能修改enclosing function的binding,文中提到了主要原因還是在于Guido反對這么做。因為這樣會導(dǎo)致本應(yīng)該作為類的實例保存的對象被聲明了本地變量。

    參考網(wǎng)站:http://www.python.org/dev/peps/pep-0227/


    posted @ 2008-10-17 20:06 ZelluX 閱讀(508) | 評論 (0)編輯 收藏

    acm queue 9月的雜志的主題是The Concurrency Problem,力推了Erlang這個語言,其中有篇文章簡單的介紹了下這個message-oriented語言。

    查了下這個名字的讀法,正確的讀法應(yīng)該是air-lang,這里元音a的發(fā)音和bang中的a一樣。

    文章中的第一個程序就有點(diǎn)令人費(fèi)解,主要原因在于Erlang的語法和一般的imperative language差別很大,和functional language比較類似,但是本質(zhì)上也有很大的不同。

    以Java的一個計數(shù)程序為例
    //?A?shared?counter.
    public?class?Sequence?{
    ????
    private?int?nextVal?=?0;
    ?
    ????
    //?Retrieve?counter?and?increment.
    ????public?synchronized?int?getNext()?{
    ????????
    return?nextVal++;
    ????}
    ?
    ????
    //?Re-initialize?counter?to?zero.
    ????public?synchronized?void?reset()?{
    ????????nextVal?
    =?0;
    ????}
    }

    這個程序的功能不用多說了,一個同步的計數(shù)程序。它的Erlang翻譯版的代碼為

    -module(sequence1).
    -export([make_sequence/0, get_next/1, reset/1]).
    ?
    % Create a new shared counter.
    make_sequence() ->
    spawn(fun() -> sequence_loop(0)end).
    ?
    sequence_loop(N) ->
    receive
    {From, get_next} ->
    From!{self(), N},
    sequence_loop(N + 1)<SEMI>
    reset ->
    sequence_loop(0)
    end.
    ?
    % Retrieve counter and increment.
    get_next(Sequence) ->
    Sequence!{self(), get_next},
    receive
    {Sequence, N} -> N
    end.
    ?
    % Re-initialize counter to zero.
    reset(Sequence) ->
    Sequence! reset.

    初看這個程序自然是一頭霧水,不過程序的函數(shù)式風(fēng)格味還是很濃的。

    前面提到,Erlang是基于message的,或者說message sending機(jī)制是包含在語言系統(tǒng)內(nèi)部的,語法就是 pid ! message

    接下來再來分析這個簡單的程序。開頭兩行是模塊和函數(shù)聲明,略去。make_sequence開始這個進(jìn)程,spawn/1內(nèi)置函數(shù)創(chuàng)建一個新的進(jìn)程,并返回pid到調(diào)用者。

    初始時運(yùn)行的函數(shù)是sequence_loop(0),這個函數(shù)接收兩種信息,用receive表達(dá)式聲明:如果收到形式是{From, get_next}的信息,就返回當(dāng)前的N并調(diào)用sequence_loop(N+1),這樣下一次收到同樣的信息時就能返回N+1了;reset則等價 于Java版本中的n=0語句。

    get_next/1則是發(fā)送給pid為Sequence的進(jìn)程 {self(), get_next} 這樣一個信息,上面解釋的sequence_loop/1函數(shù)收到這個信息后會返回一個 {self(), N} 的tuple給get_next/1,收到這個信息后get_next/1就能返回N這個值了。

    最后reset/1函數(shù)則是發(fā)送給Sequence一個reset信息。

    這個簡單的程序里能大致窺見一些Erlang的特點(diǎn),尤其是它基于信息發(fā)送的本質(zhì)。

    posted @ 2008-10-17 20:05 ZelluX 閱讀(1900) | 評論 (0)編輯 收藏

    09月 18, 2008
    第一個testkernel在Xen中的載入

    The Definitive Guide to Xen中第二章的例子,make成功后運(yùn)行xen create domain_config,報錯
    Error: (2, ‘Invalid kernel’, ‘xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n’)

    google之后發(fā)現(xiàn)是虛擬機(jī)類型設(shè)置的問題,運(yùn)行xm info可以看到
    xen_caps : xen-3.0-x86_32p
    末尾的p表示Xen內(nèi)核開啟了PAE模式,所以載入的kernel也必須開啟PAE,在bootstrap.x86_32.S中加入PAE=yes選項即可。

    09月 25, 2008
    DomainU中調(diào)用do_console_io

    The Definitive Guide to Xen第二章的Exercise,通過調(diào)用hypercall page中的console_io項輸出Hello World。

    void?start_kernel(start_info_t?*?start_info)
    {
    ????HYPERVISOR_console_io(CONSOLEIO_write,
    12,"Hello?World\n");
    ????
    while(1);
    }


    但是默認(rèn)選項編譯和啟動的Xen是不會保留DomainU中輸出的信息。參考drivers/char/console.c,可以看到主要有兩個選項控制了DomainU的do_console_io輸出:

    #ifndef?VERBOSE
    ????
    /*?Only?domain?0?may?access?the?emergency?console.?*/
    ????
    if?(?current-&gt;domain-&gt;domain_id?!=?0?)
    ????????
    return?-EPERM;
    #endif

    if?(?opt_console_to_ring?)
    {
    ????
    for?(?kptr?=?kbuf;?*kptr?!=?'\0';?kptr++?)
    ????????putchar_console_ring(
    *kptr);
    ????send_guest_global_virq(dom0,?VIRQ_CON_RING);
    }


    VERBOSE選項可以在編譯Xen的時候開啟debug選項,而opt_console_to_ring則是一個啟動選項,在grub的啟動選項中增加loglvl=all guest_loglvl=all console_to_ring即可。

    重啟Xen后就能通過xm dmesg看到Hello World了。

    09月 25, 2008
    Xen: Remove support for non-PAE 32-bit

    看來我還是用Xen 3.1吧 = =

    Subject: [Xen-devel] [PATCH] xen: remove support for non-PAE 32-bitLink to this message
    From: Jeremy Fitzhardinge (jer…@goop.org)
    Date: 05/09/2008 04:05:34 AM
    List: com.xensource.lists.xen-devel

    Non-PAE operation has been deprecated in Xen for a while, and is rarely tested or used. xen-unstable has now officially dropped non-PAE support. Since Xen/pvops’ non-PAE support has also been broken for a while, we may as well completely drop it altogether.

    10月 07, 2008
    IA-32 Memory Virtualization
    http://www.intel.com/technology/itj/2006/v10i3/3-xen/4-extending-with-intel-vt.htm
    o_figure_3.gif
    上圖為full virtulization的情況,即不修改Guest OS的行為時的解決方案。Xen為每個Guest OS維護(hù)了一張shadow page table,其中映射的地址為machine address。一種比較高效的方案是設(shè)置Guest OS的page table為只讀,當(dāng)Guest OS試圖修改這個虛擬頁表時,發(fā)生page fault被Xen截獲,Xen修改shadow page table中相應(yīng)的數(shù)據(jù)(把pseudo-physical address轉(zhuǎn)化成machine address)。另外一個優(yōu)化是guest page table被修改時不修改shadow page table,只是把它放到一個待更新列表中,等Guest OS執(zhí)行了刷新tlb的指令后再一次性更新。

    The Definitive Guide to Xen上還提到了另一種基于full paravirtulization和shadow page table之間的方案。Xen把Guest OS的page table置為只讀,當(dāng)Guest OS試圖修改page table時,Xen捕獲到page fault,把page directory中對應(yīng)的入口置為無效,再把page table改成可寫讓Guest OS修改。由于page directory中對應(yīng)的入口被設(shè)成無效了,下次訪問該地址時還是會發(fā)生page fault,這時候Xen再修改page directory和page table的對應(yīng)項就行了。

    這種方法意味著Guest OS中內(nèi)核管理模塊直接和machine address打交道,而其他部分則仍然使用pseudo-physical address。另外這種情況下page directory不能被Guest OS修改。

    另外Xen還用到了段機(jī)制,用來為Xen保留地址空間開始的64M內(nèi)存。

    posted @ 2008-10-17 20:01 ZelluX 閱讀(1436) | 評論 (6)編輯 收藏

    好不容易找到的一個php,直接貼這兒了,方便其他網(wǎng)友。
    wordpress的wp-syntax插件用的也是geshi,所以同樣也適用于wp-syntax

    <?php
    /*************************************************************************************
    ?*?erlang.php
    ?*?--------
    ?*?Author:?Uwe?Dauernheim?(uwe@dauernheim.net)
    ?*?Copyright:?(c)?2008?Uwe?Dauernheim?(http://www.kreisquadratur.de/)
    ?*?Release?Version:?1\.0\.0
    ?*?Date?Started:?2008-09-27
    ?*
    ?*?Erlang?language?file?for?GeSHi.
    ?*
    ?*?CHANGES
    ?*?-------
    ?*?2008-09-27?(1.0.0)
    ?*???[?]?First?Release
    ?*
    ?*?2008-09-28?(1.0.0.1)
    ?*???[!]?Bug?fixed?with?keyword?module.
    ?*???[+]?Added?more?function?names???
    ?*
    ?*?TODO?(updated?2008-09-27)
    ?*?-------------------------
    ?*???[!]?Stop?';'?from?being?transformed?to?'<SEMI>'
    ?*?
    ?***********************************************************************************
    */

    $language_data?=?array?(
    ????
    'LANG_NAME'?=>?'Erlang',
    ????
    'COMMENT_SINGLE'?=>?array(1?=>?'%'),
    ????
    'CASE_KEYWORDS'?=>?GESHI_CAPS_NO_CHANGE,
    ????
    'QUOTEMARKS'?=>?array('"'),
    ????
    'HARDQUOTE'?=>?array("'",?"'"),?
    ????
    'HARDESCAPE'?=>?array('\\\'',),?
    ????
    'ESCAPE_CHAR'?=>?'\\',
    ????
    'KEYWORDS'?=>?array(
    ????????1?=>?array(
    ????????????
    'module',?'export',?'import',?'author',?'behaviour'
    ????????????),
    ????????2?=>?array(
    ????????????
    'case',?'of',?'if',?'end',?'receive',?'after'
    ????????????),
    ????????3?=>?array(
    ????????????//?erlang
    ????????????
    'set_cookie',?'get_cookie',?
    ????????????//?io
    ????????????
    'format',?'fwrite',?'fread',?
    ????????????//?gen_tcp
    ????????????
    'listen',?'accept',?'close',?
    ????????????//?gen_server
    ????????????
    'call',?'start_link'
    ????????????)
    ????????),
    ????
    'SYMBOLS'?=>?array(
    ????????
    ':',?'=',?'!',?'|'
    ????????),
    ????
    'CASE_SENSITIVE'?=>?array(
    ????????GESHI_COMMENTS?=>?false,
    ????????1?=>?true,
    ????????2?=>?true,
    ????????3?=>?true
    ????????),
    ????
    'STYLES'?=>?array(
    ????????
    'KEYWORDS'?=>?array(
    ????????????1?=>?
    'color:?#b1b100;',
    ????????????2?=>?'color:?#b1b100;',
    ????????????
    3?=>?'color:?#000066;'
    ????????????)
    ,
    ????????
    'COMMENTS'?=>?array(
    ????????????
    1?=>?'color:?#666666;?font-style:?italic;',
    ????????????
    2?=>?'color:?#009966;?font-style:?italic;',
    ????????????
    3?=>?'color:?#0000ff;',
    ????????????
    4?=>?'color:?#cc0000;?font-style:?italic;',
    ????????????
    5?=>?'color:?#0000ff;',
    ????????????
    'MULTI'?=>?'color:?#666666;?font-style:?italic;'
    ????????????)
    ,
    ????????
    'ESCAPE_CHAR'?=>?array(
    ????????????
    0?=>?'color:?#000099;?font-weight:?bold;',
    ????????????
    'HARD'?=>?'color:?#000099;?font-weight:?bold;'
    ????????????)
    ,
    ????????
    'BRACKETS'?=>?array(
    ????????????
    0?=>?'color:?#009900;'
    ????????????)
    ,
    ????????
    'STRINGS'?=>?array(
    ????????????
    0?=>?'color:?#ff0000;',
    ????????????
    'HARD'?=>?'color:?#ff0000;'
    ????????????)
    ,
    ????????
    'NUMBERS'?=>?array(
    ????????????
    0?=>?'color:?#cc66cc;'
    ????????????)
    ,
    ????????
    'METHODS'?=>?array(
    ????????????
    1?=>?'color:?#006600;',
    ????????????
    2?=>?'color:?#006600;'
    ????????????)
    ,
    ????????
    'SYMBOLS'?=>?array(
    ????????????
    0?=>?'color:?#339933;'
    ????????????)
    ,
    ????????
    'REGEXPS'?=>?array(
    ????????????
    0?=>?'color:?#0000ff;',
    ????????????
    4?=>?'color:?#009999;',
    ????????????)
    ,
    ????????
    'SCRIPT'?=>?array(
    ????????????)
    ????????)
    ,
    ????
    'URLS'?=>?array(
    ????????
    1?=>?'',
    ????????
    2?=>?'',
    ????????
    3?=>?'http://www.erlang.org/doc/man/{FNAMEL}.html'
    ????????)
    ,
    ????
    'OOLANG'?=>?true,
    ????
    'OBJECT_SPLITTERS'?=>?array(
    ????????
    1?=>?'-&gt;',
    ????????
    2?=>?':'
    ????????)
    ,
    ????
    'REGEXPS'?=>?array(
    ????????
    //?Variable
    ????????0?=>?'[A-Z][_a-zA-Z0-9]*',
    ????????
    //?File?Descriptor
    ????????4?=>?'&lt;[a-zA-Z_][a-zA-Z0-9_]*&gt;'
    ????????)
    ,
    ????
    'STRICT_MODE_APPLIES'?=>?GESHI_NEVER,
    ????
    'TAB_WIDTH'?=>?4
    );

    ?>

    posted @ 2008-10-16 20:36 ZelluX 閱讀(436) | 評論 (0)編輯 收藏

    http://www.codeproject.com/KB/work/FontSurvey.aspx

    主要的衡量標(biāo)準(zhǔn)是可讀性、是否等寬、特殊字符的辨認(rèn)度(比如0和O)

    posted @ 2008-10-13 18:26 ZelluX 閱讀(1276) | 評論 (1)編輯 收藏

    依然是內(nèi)網(wǎng)日志的匯總

    1. sysenter的介紹
    http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/article.php/c8223

    System Call Optimization with the SYSENTER Instruction
    by John Gulbrandsen
    Windows下的

    2. The SLUB allocator
    slab的改進(jìn)版本

    http://lwn.net/Articles/229984/

    http://lwn.net/Articles/229096/

    Christoph’s response is the SLUB allocator, a drop-in replacement for the slab code. SLUB promises better performance and scalability by dropping most of the queues and related overhead and simplifying the slab structure in general, while retaining the current slab allocator interface.

    Wider use may be in the cards: the SLUB allocator is in the -mm tree now and could hit the mainline as soon as 2.6.22. The simplified code is attractive, as is the claimed 5-10% performance increase. If merged, SLUB is likely to coexist with the current slab allocator (and the SLOB allocator intended for small systems) for some time. In the longer term, the current slab code may be approaching the end of its life.

    3. Compilers and More: Parallel Programming Made Easy?
    http://www.hpcwire.com/features/Compilers_and_More_Parallel_Programming_Made_Easy.html

    by Michael Wolfe, Compiler Engineer, The Portland Group, Inc.

    4. OpenCL slides, SIGGRAPH '08
    發(fā)信人: jjgod (while(!asleep()) sheep++;), 信區(qū): CSArch
    標(biāo)? 題: SIGGRAPH 08 上的 OpenCL slides
    發(fā)信站: 水木社區(qū) (Mon Sep 15 01:32:03 2008), 站內(nèi)

    ※ 來源:·水木社區(qū) newsmth.net·[FROM: 125.33.176.*]

    附件: munshi-opencl.pdf (1338 KB) 鏈接:
    http://att.newsmth.net/att.php?p.272.35430.226.pdf
    全文鏈接:http://www.newsmth.net/bbscon.php?bid=272&id=35430

    5. linux-gate.so
    http://www.trilithium.com/johan/2005/08/linux-gate/
    linux下使用sysenter的機(jī)制

    posted @ 2008-10-10 15:29 ZelluX 閱讀(488) | 評論 (0)編輯 收藏

    轉(zhuǎn)自偶的內(nèi)網(wǎng)博客

    Time : 2008-08-20 21:44
    匯編文件中導(dǎo)出函數(shù)符號

    Linux 2.4.18的linux/linkage.h文件定義了若干相關(guān)的宏

    #define?SYMBOL_NAME(X)?X
    #ifdef?__STDC__
    #define?SYMBOL_NAME_LABEL(X)?X##:
    #else
    #define?SYMBOL_NAME_LABEL(X)?X/**/:
    #endif
    ?
    #define?__ALIGN?.align?16,0x90
    #define?__ALIGN_STR?".align?16,0x90"
    ?
    #define?ALIGN?__ALIGN
    #define?ALIGN_STR?__ALIGN_STR
    ?
    #define?ENTRY(name)?\
    ??.globl?SYMBOL_NAME(name);?\
    ??ALIGN;?\
    ??SYMBOL_NAME_LABEL(name)

    用ENTRY(name)就能定義函數(shù)了。后來發(fā)現(xiàn)Flux OSKit中本來就提供了類似功能的宏,定義在inc/asm.h中。
    使用的時候需要再寫一個c語言的wrapper function(至少2.4.18里面是這么做的)
    asmlinkage void ret_from_fork(void) __asm__("ret_from_fork");

    Time : 2008-08-22 15:56
    OS Lab 4 debugging notes [1]
    系統(tǒng)調(diào)用 fork()

    用Simics跟蹤一條條匯編分析頁表映射、寄存器值還真是體力活啊。。

    1. 實現(xiàn)Copy On Write時,如果某一個用戶態(tài)頁面有多個進(jìn)程共享,其中一個進(jìn)程修改該頁面時需要創(chuàng)建一個新的頁面。一開始偶忘了把原來頁面的內(nèi)容復(fù)制到新的頁面了 =_= 另外由于新的頁面要代替老的頁面,或者說它們的物理地址不同,但虛擬地址相同,我的方法是在內(nèi)核態(tài)開辟一個大小為一個頁面的空間作為中轉(zhuǎn)。

    2. do_fork函數(shù)中,子進(jìn)程復(fù)制父進(jìn)程的頁表的同時會把父進(jìn)程頁表項置為不可寫,注意最后要flush tlb。因為一開始沒有flush tlb,導(dǎo)致最后用戶態(tài)fork返回以后讀取的信息來自于tlb,直接改寫了共享頁面中fork的返回地址,導(dǎo)致切換到子進(jìn)程時fork的返回地址丟失。這個bug讓我郁悶了兩三個小時。。

    3. 使用兩次fork時,第二次fork返回的pid會被改掉。查了下發(fā)現(xiàn)為用戶空間分配物理頁面的代碼里居然在分配好以后沒有把對應(yīng)的struct置為已使用,結(jié)果導(dǎo)致第二個子進(jìn)程COW創(chuàng)建新頁面時得到了原來的父進(jìn)程頁面,改寫了父進(jìn)程頁面內(nèi)容。

    Time : 2008-08-23 19:41
    OS Lab4 debugging notes [2]
    ?
    系統(tǒng)調(diào)用 exec()

    1. 清空頁表的用戶空間映射的函數(shù)一開始寫得yts,bug到處都是,比如free的時候沒使用指向內(nèi)存塊首地址的指針,記錄內(nèi)存地址的變量沒有累加。

    2. exec傳遞給內(nèi)核態(tài)的兩個參數(shù)必須先在內(nèi)核態(tài)保存一個副本,否則清空用戶態(tài)頁表后就無法得到這兩個參數(shù)信息了。

    3. 分配給用戶態(tài)的頁面必須先清零,一方面考慮到安全性,另一方面不清零會隱藏一些潛在的bug。一開始我沒有在內(nèi)核執(zhí)行exec的時候完整的復(fù)制所有的參數(shù),而是直接指向了原進(jìn)程的內(nèi)存空間,由于清空頁表后再次申請新頁表時得到了原來的頁面,結(jié)果正好原來那個保存參數(shù)的頁面和新進(jìn)程的該頁面重合了 =_= 于是浪費(fèi)了不少時間在這個bug上

    Time : 2008-08-31 1:18
    OS Lab5 debugging notes

    還算順利,不過這個lab蠻無聊的,等有空了把syscall改成類似linux的做法,單一中斷號+寄存器選擇syscall。

    1. 最花時間的一個bug是ls返回值沒有改成應(yīng)用程序數(shù),結(jié)果一開始一直以為是brk系統(tǒng)調(diào)用沒寫好,最后才發(fā)現(xiàn)問題出在這么小的地方。

    2. brk的邏輯還不是很清楚,盡管通過了簡單的測試,但是debug輸出的信息顯示brk增長的很快,經(jīng)常是一個頁一個頁漲的,看來還得查下brk的具體行為。

    3. 寫了個比MAGIC_BREAK好用一點(diǎn)的宏,因為用戶態(tài)的程序都是按二進(jìn)制讀入的,Simics無法得到函數(shù)信息(函數(shù)名、當(dāng)前行數(shù)等),利用C99的宏寫了個新的INFO_BREAK

    #define?INFO_BREAK?\
    ????
    do?{??\
    ????????lprintf_kern(
    "break?in?%s:%d",?__FUNCTION__,?__LINE__);?\
    ????????MAGIC_BREAK;?\
    ????}
    ?while?(0)?\

    posted @ 2008-10-10 15:21 ZelluX 閱讀(591) | 評論 (0)編輯 收藏

    發(fā)信人: Zellux (null), 信區(qū): Software_06
    標(biāo) 題: OSLab之中斷處理
    發(fā)信站: 日月光華 (2008年08月30日20:15:58 星期六), 站內(nèi)信件

    1. 準(zhǔn)備工作
    在開始分析Support Code之前,先配置下我們的Source Insight,使它能夠支持.s文件的搜索。

    在Options->Document Options->Document Types中選擇x86 Asm Source File,在File fileter中增加一個*.s,變成*.asm;*.inc;*.s 然后在Project->Add and Remove
    Project Files中重新將整個oslab的目錄加入,這樣以后進(jìn)行文本搜索時.s文件也不會漏掉了。

    2. Source Insight使用
    接下來簡單分析下內(nèi)核啟動的過程,在瀏覽代碼的過程中可以迅速的掌握Source Insight的使用技巧。

    lib/multiboot /multiboot.s完成了初始化工作,可以看到其中一句call
    EXT(multiboot_main)調(diào)用了C函數(shù)multiboot_main,使用ctrl+/搜索包含multiboot_main的所有文件,最終base_multiboot_main.c中找到了它的定義。依次進(jìn)行cpu、內(nèi)存的初
    始化,然后開啟中斷,跳轉(zhuǎn)到kernel_main函數(shù),也是Lab1中所要改寫的函數(shù)之一。另外
    在這里可以通過ctrl+單擊或者ctrl+=跳轉(zhuǎn)到相應(yīng)的函數(shù)定義處,很方便。

    3. irq處理初始化工作
    來看下Lab 1的重點(diǎn)之一,irq的處理。跟蹤multiboot_main->base_cpu_setup->base_cp
    u_init->base_irq_init,可以看到這行代碼
    gate_init(base_idt, base_irq_inittab, KERNEL_CS);
    繼續(xù)使用ctrl+/找到base_irq_inittab的藏身之處:base_irq_inittab.s

    4. base_irq_inittab.s
    這個匯編文件做了不少重復(fù)性工作,方便我們在c語言級別實現(xiàn)各種handler。
    GATE_INITTAB_BEGIN(base_irq_inittab) /* irq處理函數(shù)表的起始,還記得jump
    table 嗎? */
    MASTER(0, 0) /* irq0 對應(yīng)的函數(shù) */


    來看看這個MASTER(0, 0)宏展開后是什么樣子:
    #define MASTER(irq, num) \
    GATE_ENTRY(BASE_IRQ_MASTER_BASE + (num), 0f, ACC_PL_K|ACC_INTR_GATE) ;\
    P2ALIGN(TEXT_ALIGN) ;\
    0: ;\
    pushl $(irq) /* error code = irq vector */ ;\
    pushl $BASE_IRQ_MASTER_BASE + (num) /* trap number */ ;\
    pusha /* save general registers */ ;\
    movl $(irq),%ecx /* irq vector number */ ;\
    movb $1 << num,%dl /* pic mask for this irq */ ;\
    jmp master_ints

    依次push irq號,trap號(0x20+irq號),通用寄存器(eax ecx等)入棧,把irq號保
    存到ecx寄存器,然后跳轉(zhuǎn)到master_ints,master_ints是所有master interrupts公用
    的代碼。

    跳過master_ints的前幾行,從第七行開始
    /* Acknowledge the interrupt */
    movb $0x20,%al
    outb %al,$0x20

    /* Save the rest of the standard trap frame (oskit/x86/base_trap.h). */
    pushl %ds
    pushl %es
    pushl %fs
    pushl %gs

    /* Load the kernel's segment registers. */
    movw %ss,%dx
    movw %dx,%ds
    movw %dx,%es

    /* Increment the hardware interrupt nesting counter */
    incb EXT(base_irq_nest)

    /* Load the handler vector */
    movl EXT(base_irq_handlers)(,%ecx,4),%esi

    注釋寫得很詳細(xì),首先發(fā)送0x20到0x20端口,也就是Lab1文檔上所說的發(fā)送INT_CTL_DON
    E到INT_CTL_REG,看來這一步support code已經(jīng)替我們完成了。接下來保存四個段寄存
    器ds es fs gs,并讀入kernel態(tài)的段寄存器信息。

    最后一句很關(guān)鍵,把base_irq_handlers + %ecx * 4這個值保存到了esi寄存器中,%ecx
    中保存了irq號,而*4則是一個函數(shù)指針的大小,那么base_irq_handlers是什么呢?繼
    續(xù)用ctrl+/搜索,可以在base_irq.c中找到這個數(shù)組的定義
    unsigned int (*base_irq_handlers[BASE_IRQ_COUNT])(struct trap_state *ts)
    且初始時這個數(shù)組的每一項都是base_irq_default_handler

    看來這句匯編代碼的功能是把處理irq對應(yīng)的函數(shù)地址保存到了esi寄存器中。
    為了證實這一點(diǎn),繼續(xù)看base_irq_inittab.s的代碼:
    #else
    /* Call the interrupt handler with the trap frame as a parameter */
    pushl %esp
    call *%esi
    popl %edx
    #endif
    果然,在保存了esp值后,緊接著就調(diào)用了esi指向的那個函數(shù)。而從那個函數(shù)返回后,
    之前在棧上保存的相關(guān)信息都被恢復(fù)了:

    /* blah blah blah */
    /* Return from the interrupt */
    popl %gs
    popl %fs
    popl %es
    popl %ds
    popa
    addl $4*2,%esp /* Pop trap number and error code */
    iret
    這樣就恢復(fù)到了進(jìn)入這個irq處理單元前的狀態(tài),文檔中所要求的保存通用寄存器這一步
    其實在這里也已經(jīng)完成了,不需要我們自己寫代碼。

    好了,這樣一分析后,我們要做的事情就很簡單,就是把base_irq_handlers數(shù)組中的對
    應(yīng)項改成相應(yīng)的handler函數(shù)就行了。
    注意index是相應(yīng)的idt_entry號減去BASE_IRQ_SLAVE_BASE,或者直接使用IRQ號。

    另外這個數(shù)組的初始值都是base_irq_default_handler,用ctrl+左鍵跳到這個函數(shù)的定
    義,可以看到這個函數(shù)只有一句簡單的輸出語句:
    printf("Unexpected interrupt %d\n", ts->err);
    而這就是沒有注冊handler前我們所看到的那句Unexpected interrupt 0的來源了。

    5. struct trap_state *ts
    所有的handler函數(shù)的參數(shù)都是一個struct trap_state *ts,這個參數(shù)是哪來的呢?
    注意call *%esi的前一行
    /* Call the interrupt handler with the trap frame as a parameter */
    pushl %esp
    這里把當(dāng)前的esp當(dāng)作指向ts的指針傳給了handler,列一下從esp指向的地址開始的內(nèi)容
    ,也就是在此之前push入棧的內(nèi)容:

    pushl $(irq) /* error code = irq vector */ ;\
    pushl $BASE_IRQ_MASTER_BASE + (num) /* trap number */ ;\
    pusha /* save general registers */ ;\
    pushl %ds
    pushl %es
    pushl %fs
    pushl %gs

    再看一下trap_state的定義,你會發(fā)現(xiàn)正好和push的順序相反:
    /* Saved segment registers */
    unsigned int gs;
    unsigned int fs;
    unsigned int es;
    unsigned int ds;

    /* PUSHA register state frame */
    unsigned int edi;
    unsigned int esi;
    unsigned int ebp;
    unsigned int cr2; /* we save cr2 over esp for page faults */
    unsigned int ebx;
    unsigned int edx;
    unsigned int ecx;
    unsigned int eax;

    /* Processor trap number, 0-31. */
    unsigned int trapno;

    /* Error code pushed by the processor, 0 if none. */
    unsigned int err;

    而這個定義后面的
    /* Processor state frame */
    unsigned int eip;
    unsigned int cs;
    unsigned int eflags;
    unsigned int esp;
    unsigned int ss;
    則是發(fā)生interrupt時硬件自動push的五個數(shù)據(jù)(參見Understand the Linux Kernel)

    也就是說,ts指針指向的是調(diào)用當(dāng)前handler前的寄存器狀態(tài),也是當(dāng)前handler結(jié)束后
    用來恢復(fù)的寄存器狀態(tài),了解這一點(diǎn)對以后的幾個lab幫助很大。

    p.s. 另外提一句和這個lab無關(guān)的話,非vm86模式下棧上是不會有v86_es等四個寄存器
    信息的,所以以后根據(jù)task_struct指針計算*ts的地址時使用的偏移量不應(yīng)該是sizeof(
    struct trap_state)

    6. The End
    這樣差不多就把support code中處理interrupt的方法過了一遍(另外還有base_trap_in
    ittab.s,不過和irq的處理很相似)

    了解這些后Lab1就比較簡單了,不需要任何內(nèi)嵌匯編代碼即可完成。

    posted @ 2008-09-02 11:55 ZelluX 閱讀(641) | 評論 (5)編輯 收藏

         摘要: 美國為什么需要這么多大學(xué)生,而中國培育出這么多優(yōu)秀大學(xué)生為什么失業(yè)?難道是我們學(xué)生程度不夠?難道是我們同學(xué)不夠用功?難道是我們同學(xué)專業(yè)不對口?那我告訴所有讀者,為什么大學(xué)生就業(yè)難……   閱讀全文

    posted @ 2008-07-28 11:31 ZelluX 閱讀(678) | 評論 (5)編輯 收藏

    用ctags -R或者ctags * -R的時候只能生成當(dāng)前目錄下的tag,檢查了半天發(fā)現(xiàn)原來這個版本的ctags的參數(shù)順序只能老老實實的來:ctags -R *

    太囧了,總歸要bs下的,雖說也有那么一點(diǎn)點(diǎn)可能是bash解析參數(shù)時的問題,不過我猜問題來源還是這個低版本的ctags = =

    話說我也挺圡的,不習(xí)慣用source insight,還是喜歡用vim寫代碼

    posted @ 2008-07-15 10:41 ZelluX 閱讀(544) | 評論 (3)編輯 收藏

    沒心思看離散,也不準(zhǔn)備堅持看沒有荷蘭的歐洲杯決賽。閑著點(diǎn)好友的Q-Zone,原來Q-Zone首先會判斷你的瀏覽器,如果是Firefox它會重定向到RSS閱讀界面。

    安然在開學(xué)后2個月寫的一篇日志,“記憶里的名單”,驚喜的看到有我。也列出了一張屬于我的名單。好,等待時間的遴選。

    “于是想 如果有個妹妹 我要告訴她 好好放肆猖狂 做不可思議的事情 為友情和少年青澀的愛情花心思 做只是喜歡沒有功利目的的事情 這么好的年華 就是用來這樣浪費(fèi) 和珍惜的~”

    可惜我只保持了四五個月的這種瘋狂,現(xiàn)在依然糾結(jié)于功利的選擇。有時候曾想,或許那次失敗更適合我,或許我終將把這么一條平淡無奇的路走到盡頭。“表面強(qiáng)者”,或許還是很有道理的。

    看到fofo的博的文字,“我要去杭州,把所有的事情拋掉,不管后果。這個地方太讓人壓抑,盡管有很玩得來的室友,有很好的足球隊的隊友,可以看很多以前爸媽不讓看的喜歡的書還有過米的比賽,吃的東西也都很習(xí)慣,還是會在天氣很好的星期天下午突然想起曾經(jīng)在冬日的陽光照射下一家人在陽臺上圍著一張桌子吃飯的情景,還是會在一個人騎在去計算機(jī)協(xié)會的路上很難過地想著再也不會有那么四個或者五個人在一起吃完小炒放肆地在鋪滿夕陽的校園小路上勾肩搭背地行走了,還是會在一百多個人的課堂上懷念起那些艱苦卻簡單的日子里所有的笑聲,還是會在網(wǎng)吧包夜的時候想起初中時捏著飯錢偷偷摸摸地去電腦房玩星際……想找找朋友們,調(diào)整一下自己的心情。”

    真的找不回來了。在寫這篇博文時也找不到以前寫字的感覺了。

    明天離散考試,某個記錄或許將要因此打破。

    posted @ 2008-06-30 02:09 ZelluX 閱讀(376) | 評論 (1)編輯 收藏

    不枉我周末練了那么多ZvP

    不過總比分太慘了。。

    posted @ 2008-06-24 00:20 ZelluX 閱讀(400) | 評論 (0)編輯 收藏

         摘要: 一篇關(guān)于函數(shù)式編程的介紹,在水木Java版引起了熱烈討論。  閱讀全文

    posted @ 2008-06-05 21:10 ZelluX 閱讀(766) | 評論 (1)編輯 收藏

    1. framwork/policies/Singleton.h
    Singleton模式,可以指定相應(yīng)的線程模型、創(chuàng)建策略和生命期控制策略。
    對于全局范圍的Singleton實例,定義了若干個宏便于訪問,例如
    #define?sLog?MaNGOS::Singleton<Log>::Instance()
    #define?sMaster?MaNGOS::Singleton<Master>::Instance()

    Singleton的定義:


    不知道這里的注釋Prohibited actions...this does not prevent hijacking.是什么意思,copy constructor和hijacking有什么關(guān)系呢?

    另外注意這行typedef typename ThreadingModel::Lock Guard;,原來typedef還可以用在函數(shù)上。

    Singleton的Instance方法用的是標(biāo)準(zhǔn)的double-checked lock方法,關(guān)于DCL可以參考這篇博文http://www.tkk7.com/zellux/archive/2008/04/07/191365.html

    2. Explicit Constructors
    game/WorkPacket.h中看到的語法,防止構(gòu)造函數(shù)中參數(shù)的隱式轉(zhuǎn)型
    比如explicit String(int n); 用String('c')聲明時就會報錯

    posted @ 2008-06-03 19:03 ZelluX 閱讀(777) | 評論 (0)編輯 收藏

    一套基于文件系統(tǒng)的安全方案,主要通過隔離運(yùn)行不可信任的程序、taint記錄、事故恢復(fù)。

    我的presentation:
    http://docs.google.com/Presentation?id=dcjk4xx7_473cv5ddgc8

    出于時間考慮沒有提到paper中進(jìn)程間通信的解決方法

    posted @ 2008-05-28 15:23 ZelluX 閱讀(506) | 評論 (0)編輯 收藏

    水木上有人貼了個有趣的程序

    #include? < stdlib.h >
    #include?
    < stdio.h >

    void ?print_forever( int ?n)
    {
    ????printf(
    " %d\n " ,?n);
    ????print_forever(n?
    + ? 1 );
    }


    int ?main( int ?argc,? char ? * argv[])
    {
    ????print_forever(
    0 );
    ????
    return ? 0 ;
    }


    用gcc -O2編譯運(yùn)行后會不停地打印從0開始的自然數(shù),注意如果編譯器沒有做優(yōu)化的話,打印到某個數(shù)的時候肯定會發(fā)生棧溢出從而程序終止的情況,但這個程序卻能一直運(yùn)行下去,說明編譯器做了尾遞歸優(yōu)化。

    用gcc -O2 -S生成這個程序的匯編代碼后證實了這一點(diǎn)。
    .L6:
    ????????movl????
    %ebx,?4(%esp)
    ????????addl????$
    1,?%ebx
    ????????movl????$.LC0,?(
    %esp)
    ????????call????printf
    ????????jmp?????.L6
    print_forever的關(guān)鍵部分被優(yōu)化成了一個n不斷增加的死循環(huán)。

    接下來是分析哪個優(yōu)化選項處理了尾遞歸。

    用O3 O2 O1三個優(yōu)化強(qiáng)度編譯程序,查看匯編代碼后,發(fā)現(xiàn)尾遞歸優(yōu)化是O2中新增的功能。于是查看O2新開啟的優(yōu)化開關(guān):
    gcc -c -Q -O1 --help=optimizers > /tmp/O1-opts
    gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
    diff /tmp/O2-opts /tmp/O1-opts?| grep enabled
    輸出結(jié)果:

    經(jīng)證實是-foptimize-sibling-calls這個選項實現(xiàn)了尾遞歸的優(yōu)化,具體內(nèi)容可以參看
    http://gcc.gnu.org./ml/gcc-patches/2000-03/msg00867.html

    posted @ 2008-05-24 02:05 ZelluX 閱讀(2444) | 評論 (1)編輯 收藏

    主站蜘蛛池模板: 国产亚洲福利精品一区| 久久久亚洲欧洲日产国码二区| 亚洲色WWW成人永久网址| 1000部国产成人免费视频| 久久久久久毛片免费播放| 国产精品va无码免费麻豆| 亚洲精品一品区二品区三品区| 波多野结衣亚洲一级| 波霸在线精品视频免费观看| 免费a级毛片高清视频不卡| 在线观看免费精品国产| 亚洲av日韩av激情亚洲| 国产成人va亚洲电影| 91香蕉国产线在线观看免费| 亚洲国产综合久久天堂| 亚洲人成伊人成综合网久久| 精品国产福利尤物免费| 青青草原1769久久免费播放| 日本免费一二区在线电影| 亚洲男人天堂av| 一区二区三区免费视频观看| 无码中文在线二区免费| 亚洲av无码片在线播放| 国产青草亚洲香蕉精品久久| 免费视频爱爱太爽了| 亚洲美女又黄又爽在线观看| 亚洲AV成人片无码网站| 日本最新免费网站| 亚洲乱码精品久久久久..| 欧洲亚洲综合一区二区三区| 91精品免费国产高清在线| 国产精品无码一二区免费| 亚洲高清中文字幕综合网| 精品免费久久久久国产一区| 黑人粗长大战亚洲女2021国产精品成人免费视频 | 一级特级aaaa毛片免费观看| 毛片a级毛片免费播放100| 亚洲午夜免费视频| a级片免费在线观看| 日本一区二区三区免费高清| 亚洲va久久久噜噜噜久久男同 |