うぉぉぉ! Jonathan Shapiro が突っ込んでる!

それも私が前から疑問に思ってたところに! こりゃぁしばらく目が離せないぞ!!
;; Comparing "copy" and "map/unmap" : archives にはまだ出てないのでとりあえず link 無し。
Capability についてはサッパリわかってなかったけど、address space については、「いきなり unmap されたらそこに置いてた object はどうなるの? 諦めろとでも?」と思ってた。ML に投稿したり、この日記に書いたりしようととしたけどうまく言葉にできなかったからやめといたんですな。で、この投稿を見て何でうまく問題を問題として提起できなかったかがわかった。資源管理と絡めて考えてたからあかんかったわけですよ。
階層的な map でもらった fpage をいきなり unmap されてしまう可能性への対応として異様な trust が要求されるというのは、map/unmap model 単独でも生じる。それを Hurd の level でどうやって管理するかは unmap 問題の原因の一部ではなくて、それの顕現に過ぎない。つまり L4 が抱える unmap 問題という原因が、その上に乗っかる Hurd に policy を押しつける結果を生んでしまう。決して map/unmap 上で資源管理をしようとすると問題が発生するのではない。
それに加えて「trust の要求は policy の押しつけだ」という assertion も大きい。いきなり unmap されたときの問題について私は「まぁ map の階層の深さは多寡が知れてるので、TCB*1からほぼ直に map をもらうか、そうでなければ全く信用しないようにすれば済むか」という程度に考えていたけど、どっこいこれは言われてみれば思いっ切り policy です。しかも技術的な制約から来るやつで、さらに TCB を複雑・巨大化させたり、TCB 外の code 量を制限することにもなる。大問題だ。
なるほど あースッキリした。"Trust" とか "policy" というのも理解が深まった気がするぞ。Hurd と L4 関係者の反応が楽しみでならない。

*1:Trusted Computing Base。Thread control block と紛らわしい。