NetBSD 2.0の新技術を理解する 49
ストーリー by Oliver
てんこ盛り 部門より
てんこ盛り 部門より
BSD 曰く、 " NewsForgeが 「Understanding NetBSD 2.0's new technology」 という題名で、NetBSD 2.0 に導入された新しい技術の概要と、 関係者へのインタビューを掲載している。 NetBSD 2.0 に導入された技術のうち主要なものとして、 (1)ネイティブスレッドのサポート、 (2)カーネル内部事象通知機構である kqueue 、 (3)Linux エミュレーションの改善、 (4)メモリの実行禁止領域設定、 (5)i386での SMP サポートと電源管理機構、 (6)FreeBSD からの UFS2 の移植、 (7)システムコールを制御する systrace 機構、 (8)実行プログラムの改竄を検査する Verified Exec 等が 挙げられている。 また、続くインタビューではこれらの技術の詳細や、将来への影響に ついて語られている。 興味ある内容なので、一読をお勧めしたい。"
追記(1/9 18:31 by O)：コメントによりすでに大半が邦訳されているが、Slashdot Japanと同じくOSDN Japan傘下のjapan.linux.comにも翻訳版が掲載された。
翻訳のツリー (スコア:4, 参考になる)
我々(訳注：NewsForge記者)は、NetBSDのプログラマのChristos Zoulas, Luke Mewburn, Ben Collver, Nathan J. Williams, Jaromir Dolecek, Chuck Silvers, Hubert Feyrer, Bret Lymn, Jan Schaumann, Roland Dowdeswell, およびNiels Provosにインタビューした。以下が、NetBSDの新機能に関して彼らのコメントだ。
Q24 and A24 (スコア:2, 参考になる)
Jan Schaumann: I don't know about plans, but there's sysutils/mklivecd in pkgsrc, which allows any user to create their own LiveCDs. Maybe worth mentioning. (I'll actually be using 2.0-based LiveCDs for a local programming contest organized by the ACM.)
Hubert Feyrer: Yes. A German language, 2.0-based LiveCD was already published by the German FreeX magazine. The CD boots into KDE and offers KOffice, Sodipodi and a number of other applications. An international version of the CD has been kindly made available by FreeX editor Joerg Braun which will be made available at about the time 2.0 will be released.
Jan Schaumann: 計画に関して知らないが、pkgsrcにsysutils/mklivecdというツールがあり、どんなユーザでも独自のLiveCDを作れる。言っておく価値はあると思う(ACMで行われるローカルなプログラムコンテストで2.0ベースのライブCDを実際に使うつもりだ)
Hubert Feyrer: たしかに。ドイツ語版の2.0ベースのライブCDはすでにドイツのFreeX Magazine(http://www.netbsd.org/gallery/articles.html#freeX-livecd)から発行されている。CDはKDEでブートし、KOffice、Sodipoidおよび他の多くのアプリケーションを提供する。国際版のCDも、親切なことにFreeXの編集者のJoerg Braunが作成中で、2.0がリリースされるころには利用できるだろう。
＃やっと終ったぁ。
Re:Q24 and A24 (スコア:1)
やることが速いですね... すごいな。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Q1 (スコア:1)
今回のリリースでメジャー番号が上がって2.0になった理由の一つは、SMPのサポートでしょう。どんな技術を選んで開発しましたか？
A1: Luke Mewburn (スコア:1)
SMP(いわゆる「大粒度ロック」モデル)と、pthread (POSIXのスレッド)APIをもちカーネルが支援するユーザランドのスレッドです。
Re:翻訳のツリー (スコア:1, 参考になる)
Regarding memory protection: non-exec stack and/or heap, propolice, W^X. Could you make a summary of the status of these technologies in the 2.0 release?
メモリ保護に関して: 実行禁止スタック、実行禁止ヒープ、Propolice, W^X。2.0 リリースでのこれらの技術のステータスをまとめていただけますか?
Chuck Silvers: In NetBSD 2.0, both the process stack and heap are non-executable by default on platforms where the hardware supports it. Propolice is not integrated into NetBSD, nor are the other OpenBSD W^X changes. Yet.
Chunk Silvers: NetBSD 2.0 では、ハードウェアサポートがあるプラットフォームにおいてはデフォルトでスタックとヒープでのコード実行が禁止されるようになりました。Propolice や OpenBSD の W^X については、まだ統合されていません。
Which hardware includes support for these protections?
どんなハードウェアがそのメモリ保護をサポートしていますか?
Chuck Silvers: The hardware platforms that fully support non-executable mappings are AMD64, SPARC64, SPARC (sun4m, sun4d), PowerPC (IBM4xx), Alpha, SH5 and HPPA.
Chunk Silvers: 実行禁止マッピングを完全にサポートしているのは、AMD64, SPARC64, SPARC (sun4m, sun4d), PowerPC (IBM4xx), Alpha, SH5 と HPPA です。
The hardware platforms that partially support non-executable mappings are i386 and PowerPC OEA (eg. macppc). See this document for more details.
実行禁止マッピングを部分的にサポートしているのは、i386 と PowerPC OEA (macppc など)。 詳しくはドキュメントを見てください。
訳注: Propolice: IBMによるgccでの実行時バッファオーバーフロー検出拡張。W^X: スタックやヒープといった目的別で実行禁止するのではなく、「書き込めるページにあるものは実行できない」という機能。
Re:翻訳のツリー (スコア:1, 参考になる)
この訳、ちょっと違いますね。
正しくは「Propolice や、OpenBSD の W^X の『他の』変更については、
まだ統合されていません。」でしょう。
NetBSD の non-exec は、OpenBSD が W^X と呼んでいる変更の
(かなり等価に近い) 部分集合なので。
> W^X: スタックやヒープといった目的別で実行禁止するのではなく、「書き
> 込めるページにあるものは実行できない」という機能。
これは、OpenBSD の W^X が意図している機能の説明としては正しいんですが、
実装でやってることは、NetBSD の non-exec と、まあ同じようなことなので、
違いを強調するのは、ちと違和感があります。
Q2 (スコア:1)
Q2: それはFreeBSDの4.xおよび5.x, DragonFlyBSD, OpenBSDなどのSMP技術と比較するとどうでしょうか？
A2: Luke Mewburn (スコア:1)
記憶が正しければ、FreeBSD 4.xは大粒度ロックで、FreeBSD 5.xとDragonFlyBSDとでは大粒度ロックの解決に異なったアプローチをしている。OpenBSDは大粒度ロックで、その多くがNetBSDの古いSMPコードを元にして派生している。
Q3 (スコア:1)
i386 のインテルハイパースレッディング技術のようないくつかのプラットフォームに対する特別な最適化はあるのですか？
# #675115 [srad.jp]から頂きました。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
A3: Luke Mewburn (スコア:1)
HTをサポートしたので、仮想CPUはそれぞれ独立に扱われる。 しかしスケジューラはHT固有の知識を一切持たないので、（仮想）CPUに対してプロセスをスケジュールする時にHTの独自アーキテクチャからメリットを引き出せてはいない。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Q4 & A4: Luke Mewburn (スコア:1)
新しいコードがシングルCPUシステムの性能に影響を与えませんか？
Luke Mewburn: Shouldn't be, unless you run an SMP-enabled kernel.
そんなことはないよ、SMP版カーネルを走らせるんでなければね。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Q5 & A5 (スコア:1)
ネイティブスレッドがサポートされました。なぜ「ネイティブ」と？
Christos Zoulas: They are "native" to the operating system, i.e. there are features of the operating system the threads library uses that were programmed specially to assist threads. They are native because they come with the base operating system, instead of requiring a 3rd party package to be installed. Finally the word native means that they are really kernel threads, not just userland-based. In the NetBSD implementation we have both userland and kernel threads (what is called a n:m thread model).
Christos Zoulas: まず、オペレーティングシステムに元々備わっているから。 つまりスレッドを補助するためだけにプログラムされた、オペレーティングシステムの機能ということ。スレッドライブラリがそれを使う。 次に、基本オペレーティングシステムに含まれて入手できるから。サードパーティ製パッケージをインストールする必要はない。 最後に、ネイティブという言葉はまさにカーネルスレッドを意味する。ユーザーランドのスレッドだけではなく。NetBSDの実装では、ユーザーランドとカーネルの両方でスレッドが使える（これを n:m スレッドモデルと呼んでいる）。
Ben Collver: Releases prior to NetBSD 2.0 did not provide a threads API in the base system. Technically, there were exceptions. For example, the clone() system call existed under Linux emulation to run threaded Linux applications. Userland threading implementations are sufficient to run most threaded applications in older NetBSD releases. In pkgsrc we use GNU PTH, and this is probably the most used implementation.
Ben Collver: NetBSD 2.0より前のリリースは、ベースシステムではスレッドAPIを提供しなかった。 これには技術的には例外がある。例えば clone() システムコールがLinuxエミュレーションにあって、スレッド化されたLinuxアプリケーションを実行することができた。 ユーザーランドスレッドの実装は、ほとんどのスレッド化アプリケーションを古いNetBSDリリースで実行するのに充分だ。 pkgsrcではGNU PTHを使えばいい。たぶん最も広く使われている実装だと思うよ。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Q7 & A7 (スコア:1)
古いスレッドはどのように動作しましたか？
Nathan J. Williams: Previously, there were no integrated threads. Applications that wanted to use threads would link in a library like GNU pth or PTL2. These libraries are known in the literature as pure user-space systems, meaning that all of the thread implementation is done without the kernel's knowledge, or 1:N threads, meaning that all of the application's threads are multiplexed onto one kernel process. Libraries of this form have problems implementing the full promise of threads; in particular, they are vulnerable to some computation or system call blocking all of the threads in the process, since the kernel is unaware of the existence of threads.
以前は、統一されたスレッドがなかった。スレッドを使いたいアプリケーションは、GNU PTHやPTL2といったライブラリをリンクした。これらのライブラリは、文字通りユーザ空間で動き、スレッドの実装はカーネルの知識無しに、または1:Nのスレッドでアプリケーションのスレッドのすべては一つのカーネルプロセスを分割して動作した。この形式のライブラリは、スレッドすべてを実装する問題を抱えた。特に、ある種の計算やシステムコールに致命的に弱く、それらがプロセス内の全てのスレッドをブロックした。なぜなら、カーネルがスレッドの存在に気づいていないからだ。
Ben Collver: The paper "Portable Multithreading" from Ralf S. Engelschall gives a description of how the GNU PTH works.
Ralf S. Engelschallの「ポータブルなマルチスレッド」では、GNU PTHがどのように動作するかを記述している。
One of the drawbacks of GNU PTH is that threaded applications do not benefit from multiprocessor machines. Another drawback is that the scheduling is not preemptive.
GNU PTHの一つの欠点は、スレッド化したアプリケーションがマルチプロセッサの恩恵をうけられないことだ。もう一つの欠点は、スケジューリングがプリエンプティブでないことだ。
Re:Q6 & A6 (スコア:1)
Re:Q7 & A7（Q6 & A6） (スコア:1)
これらのライブラリは文字通りの「完全なユーザー空間システム」で、マルチスレッドの実装はすべてカーネルが関知しないところで行われる、というか、1：Nのスレッドになる（訳注：カーネルプロセス1つに対し複数の仮想スレッドを持つという意味）。つまり、アプリケーションのスレッドすべてが、ひとつのカーネルプロセスの中に詰め込まれることになる。この形式を採用したライブラリには、スレッド（の動作）の十分な保証について、問題がある。特に、カーネルがスレッドの存在を関知していないために、プロセス上のすべてのスレッドをブロックするような計算やシステムコールに弱い。
多分こんな感じかと。訳注は蛇足だけど一応。
yp
Q7 & A7 (スコア:1)
POSIX標準との整合性はどうでしょう？
Christos Zoulas: Application portability between different platforms, i.e. a threaded application that works on a POSIX compliant pthread library on any other OS will work on NetBSD.
異なるプラットフォーム間でのアプリケーションのポータビリティによりけり。つまり、他のOS上のPOSIXに適合したpthreadライブラリ上で動くアプリケーションなら動作する。
Nathan J. Williams: POSIX threads are really the only thread game in town these days.
POSIXのスレッドは、最近では唯一町にあるスレッドゲームだ。
(訳注： 唯一のおもしろいトピックという意味か？)
Re:Q7 & A7 (スコア:1, 参考になる)
Q8 and A8 (スコア:1)
「スケジューラアクティベーション」に基づくというが、それは一体どんなもの？
Nathan J. Williams: Scheduler activations are a mechanism invented by Thomas Anderson in a 1992 paper, which provides an interface between an operating system kernel and an application for maintaining a desired level of concurrency. In this system, the application informs the kernel how much concurrency it has, e.g. how many simultaneously computing threads it will use, and the kernel maintains a certain number of "activations," or scheduleable entities, on which the library layers application computation. It includes messages for adjusting the size of an application's computation allocation and for notifying of operations that have blocked in the kernel and resumed.
スケジューラアクティベーションは1992年にThomas Andersonが発明した機構で、OSカーネルとアプリケーションの間で望ましい並行性のレベルを維持するためのインタフェースを提供する。このシステムでは、アプリケーションはカーネルにどの程度の並行性を持つか、つまり同時に計算するスレッドの数を告げる。そして、カーネルはある数の「アクティベーション」またはスケジュール可能実体を管理し、その上にアプリケーションの計算レイヤーが乗る。これにはアプリケーションの計算割当てのサイズを調整したり、カーネルによるブロックやそこからの復帰のメッセージを含む。
The principal virtue of SA for a POSIX thread implementation is that the number of scheduleable kernel entities, and kernel resources in general, is limited to the number of concurrently-operating threads, not the total number of threads in the application. This saves resources and prevents a lot of unnecessary intra-thread scheduling competition.
POSIXスレッドを実装するのに「スケジューラアクティベーション」が良い主な点は、一般にカーネル内スケジュール対象実体とカーネル資源の数は、並行動作するスレッドの数によって決定され、アプリケーション内のスレッドの数とは直接の関係はないことにある。これによって、多くの不必要なスレッドスケジュール計算を抑制し、資源を節約できる。
You might also want to read my USENIX paper "An Implementation of Scheduler Activations on the NetBSD Operating System".
USENIXの論文「NetBSD OSにおけるスケジューラアクティベーションの実装」も御参考に。
Q9 and A9 (スコア:1)
あたらしいkqueueの枠組とは？
Jaromir Dolecek: Traditional select()/poll() is only limited to descriptors. There are other interesting kernel events, such as signals, or file system changes.
伝統的なselect()/poll()システムコールの組合せでは、記述子に限定されていた。しかし、他にもシグナルやファイルシステムの変更など興味深いカーネル事象がある。
Furthermore, select()/poll() doesn't scale very well for a large number of watched descriptors. Their efficiency decreases quickly with larger sets -- the whole watched descriptor set must be passed for each syscall invocation, forcing the system to perform two memory copies across the user/kernel boundary, reducing the memory bandwidth available for other activities. The internal kernel handling is not very scalable either, forcing the kernel to do potentially several passes through the list and having poor interaction if a descriptor is watched by more than one process or thread.
しかも、select()/poll()は、大規模な数の記述子を見張る場合にスケーラビリティが悪い。大きな集合になると、その効率は急激に減衰する。システムコールの呼出しごとに、検査する記述子集合すべてが渡される、つまりユーザ領域とカーネル領域の境界を越えて２回のメモリコピーを実行を強いられる。これは利用可能なメモリのバンド幅を減らし、他の動作に影響する。また、カーネル内の取り扱いもスケールしない。潜在的にいくつかのリストの受渡しをカーネルに強要し、記述子が一つ以上のプロセスまたはスレッドに監視されている場合に、ひどい交互作用を引き起こす。
kqueue provides a generic method of notifying the user when an event happens or condition holds, and also provides further information related to the event. The kqueue framework is stateful, application registers interested in events with the kernel via the kqueue descriptor, and can wait for any of the events to occur. For NetBSD 2.0, supported events include the traditional functionality provided by select()/poll(); notifications for file system events such as unlink, rename, attribute changes, similar to the Windows directory notifications or IRIX's /dev/imon; signals; and an arbitrary number of timers. All types of descriptors are supported, including FIFOs, sockets, open files or other kqueue descriptors. There are no limits on the number of registered events for any type of object.
kqueueは、カーネル内事象の発生や、状態の保持、事象に関する詳細情報を通知する一般的な方法を提供する。kqueueは状態依存で、アプリケーションは、kqueueを通してカーネルに関して興味ある事象を登録し、それらの事象の発生を待つことができる。NetBSD 2.0では、伝統的にはselect()/poll()で提供したイベントもサポートする。具体的には、ファイルシステム事象の削除、名前変更、属性変更などで、Windowsのdirectory notificationやIRIXの/dev/imonなどと似ている。また、シグナルや任意の数のタイマーも含む。すべての種類の記述子をサポートし、FIFOやsocket、開いたファイルやその他のkqueue事象を含む。登録する事象やオブジェクトの種類には制約はない。
kqueue is usually used synchronously. The kqueue descriptor is pollable too, so it's compatible with the traditional non-blocking application model. Asynchronous notification of new events is available as well, by using standard O_ASYNC signal semantics on the kqueue descriptor.
kqueueは、通常同期的に用いる。が、kqueue記述子はポーリングも可能なので、伝統的な非ブロックアプリケーションでも利用可能だ。新しい事象の非同期通知も利用可能だが、kqueue記述子で通常のO_ASYNCのシグナルフラグを与えて行う。
Q10 and A10 (スコア:1)
kqueueは、どのように動作する？
Jaromir Dolecek: Internally to the kernel, kqueue has a concept of kernel filters. When application registers for an event, the appropriate filter is called to check if the event has already happened. If this is the case, the event data is immediately available for pickup. Once registered, the watch set is never re-evaluated again -- the kernel just automatically removes items from the kqueue list when watched descriptors are closed.
カーネル内部では、kqueueはカーネルフィルタの概念をもつ。アプリケーションが事象を登録すると、適切なフィルタを呼び出してその事象が起きたかをチェックする。もし起きていた場合、事象データが即座に取り出し可能になる。いったん登録された監視集合は再度評価されることはない。カーネルは、監視記述子が閉じられた場合、自動的にkqueueから削除する。
When a watched event happens, the condition and associated state is recorded in the appropriate kqueue structures, and the application can pick up the event. If the event happens several times before the application reads the event data, the data reflects only the last event context.
監視事象が発生した場合、条件と関連する状態が適切なkqueue構造体に記録され、アプリケーションは事象の取り出しが可能になる。事象がアプリケーションが事象データを読み出す前に何度か発生した場合、データは最後の事象を反映する。
kqueue has O(1) scalability for number of watched events, contrary to O(n) for select()/poll(). There is no performance degradation when the same descriptor is watched by more than one process or thread, either.
kqueueは、O(n)のスケーラビリティをもつselect()/poll()と異なり、多くの監視事象に関してO(1)のスケーラビリティを持つ。また、同じ記述子を複数のプロセスまたはスレッドで監視する場合にも、パフォーマンスの低下を起こさない。
It's very easy to convert applications to use kqueue. System utilities such as tail(1), syslogd(8) or inetd(8) were modified to take advantage of this functionality for better scalability and simpler event handling, and kqueue is also being used in third-party code. The API is available in all the main open-source BSDs, including NetBSD, FreeBSD, and OpenBSD.
アプリケーションをkqueueを使うよう変更するのは非常に簡単だ。tail(1), syslogd(8), inetd(8)などのシステムユーティリティは、スケーラビリティと簡素化した事象の取り扱いという機能の有利さを享受するために変更された。また、kqueueはサードパーティのプログラムでも利用されている。このAPIは、主要なオープンソースのBSDシステムで利用できる。
Christos Zoulas: This came from FreeBSD's Jonathan Lemon.
これは、FreeBSDのJonathan Lemonから来たものだ。
＃ほっと一息。拙速を貴びました。突っ込みよろしく。
Q11 & A11 (スコア:1)
メモリ保護に関して、実行禁止スタック・ヒープ、propolice、W^X があります。 2.0 リリースにおけるこれらの技術の状況をまとめてもらえますか？
Chuck Silvers: In NetBSD 2.0, both the process stack and heap are non-executable by default on platforms where the hardware supports it. Propolice is not integrated into NetBSD, nor are the other OpenBSD W^X changes. Yet.
Chuck Silvers: NetBSD 2.0 では、ハードウェアによるサポートがあるプラットフォームの場合、プロセスのスタックとヒープはデフォルトで実行禁止になっている。 propolice は NetBSD に統合されていない。 OpenBSD の W^X もまだだ。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Q12 & A12 (スコア:1)
どのハードウェアでこれらの保護技術がサポートされていますか？
Chuck Silvers: The hardware platforms that fully support non-executable mappings are AMD64, SPARC64, SPARC (sun4m, sun4d), PowerPC (IBM4xx), Alpha, SH5 and HPPA.
Chuck Silvers: 実行禁止マッピングを完全にサポートしているハードウェアプラットフォームは AMD64, SPARC64, SPARC (sun4m, sun4d), PowerPC (IBM4xx), Alpha, SH5 と HPPA です。
The hardware platforms that partially support non-executable mappings are i386 and PowerPC OEA (eg. macppc). See this document for more details.
実行禁止マッピングを部分的にサポートしているハードウェアプラットフォームは i386 と PowerPC OEA (例えば macppc) です。 詳しくはこの文書（ http://www.netbsd.org/Documentation/kernel/non-exec.html ）を見て下さい。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Q13 and A13 (スコア:1)
Brett Lymn: それほどはかからない。カーネルを構築し直して検証付き実行機能を組み込むだけだ。最も時間がかかるのが、指紋ファイルを生成すること。これを支援するために/usr/share/examples/veriexecctl/に二つのスクリプトがあり、適切なファイルをすべてをスキャンし指紋ファイルを作る。マシンの種類にもよるが、完了までにすこしかかる。いったん完了すれば結果のシグニチャファイルを/etcにおき、読み込み待ちになる。
Q14 and A14 (スコア:1)
Brett Lymn: ブートプロセスの初期の段階で、すべての実行可能ファイルと共有ライブラリの指紋ファイルのリスト(md5またはsha1によるハッシュ値)がカーネルに読み込まれる。何かが実行されるか、共有ライブラリが参照されると、そのファイルのハッシュ値を計算してリストと照合する。それらが一致すると実行または参照が許可される。一致しなければ、許可されずそこで停止する。このアイデアはシステムのユーティリティにトロイの木馬を挿入されるのを防ぎ、未知のバイナリが実行されるのを防ぐ。詳細は、ここに(http://users.on.net/blymn/veriexec/)。
Q15 and A15 (スコア:1)
Niels Provos: There is currently no application systraced by default. systrace can be used by the paranoid system administrator to further tighten their security. For example, monkey.org is a small ISP that runs systrace to provide restricted shell access to all their users. It seems to be working fine for them and systrace has already prevented compromises for them.
Niels Provos: 現在の所デフォルトでsystraceされるアプリケーションはない。systraceは、セキュリティ狂の管理者がさらにセキュリティを強化するのに使える。例えば、monkey.orgが小さなISPだが、systraceを走らせてシェルのユーザに限定的なシェルアクセスを提供している。うまく動いているようで、systraceは妥協を許さない。
Q16 and A16 (スコア:1)
Christos Zoulas: No, we have not. We have introduced a block level snapshot mechanism (/dev/{r,}fss*), but that is still experimental.
Christos Zoulas: いや、導入していない。ブロックレベルでのスナップショット(/dev/{r,}fss*)を導入したが、まだ実験段階だ。
Q17 and A17 (スコア:1)
Christos Zoulas: With UFS2? We had compatibility issues with our boot blocks and UFS1 file systems, but we've ironed those out. If you mean general code portability there are 3 classes of problems:
* Endianness assumptions
* Alignment constraint violation
* Type size assumptions
Most of the problems we encounter are in pkgsrc, not in our own sources. But if you can get your code to work on i386 (little endian, 32 bits, no alignment constraints) and SPARC64 (big endian, 64 bits, and alignment constraints), you've probably got most of the portability bugs figured out.
Finally, there is operating system feature portability, but that has become easier because most OSes are POSIX compliant these days.
Christos Zoulas: UFS2に関して？ブートブロックとUFS1で互換性に関する問題があったが解決した。一般的なコードの移植可能性に関する話なら、次の３つの分類の問題がある。
* エンディアンに関する仮定
* アラインメント制約の違反
* 変数型のサイズの仮定
pkgsrcでは、これらの多くの問題はでくわしたが、我々のコード中ではなかった。しかし、コードをi386(リトルエンディアン、32ビット、アラインメント制約なし)とSPARC64(ビッグエンディアン、64ビット、アラインメント制約あり)で動作させたならば、おそらくほとんどの移植可能性に関するバグを理解できるだろう。
最後にOSの機能の移植可能性がある。しかし、最近はほとんどのOSがPOSIX準拠になっているので比較的簡単な問題になっている。
Q18 and A18 (スコア:1)
Luke Mewburn: It works. We're using it within the project to provide multiple virtual machines on one physical machine for internal administrative purposes.
Luke Mewburn: 動くよ。プロジェクト内では、内部的な管理のために物理的に一つのマシンで、複数の仮想マシンを動かすのに利用している。
Q19 and A19 (スコア:1)
Luke Mewburn: Support for newer laptops, including thermal zone support. However, there is no ACPI suspend/resume support at this time.
Hubert Feyrer: *cough* I wouldn't say that ACPI is the only reason for trying NetBSD on a notebook. The fine framework for PCMCIA and Cardbus are very well worth giving NetBSD a try, in addition to the support readily available for a big number of USB devices and also modern PCI devices found in today's laptops and notebooks. The USB and PCMCIA/Cardbus systems of NetBSD are used as a base for other systems' implementations.
Luke Mewburn: より新しいラップトップ、特に温度制御も含めてのサポートがある。しかし、今の時点ではACPIのサスペンド／リジュームのサポートはしていない。
Hubert Feyrer: ＊おほん＊NetBSDをノートブックで試す唯一の理由がACPIだとは思わない。PCMCIAとCardbusの優れた枠組はNetBSDを試してみるのにふさわしい理由だろうし、さらにすでに膨大な数のUSBデバイスや、また最近のノートブックやラップトップで利用されるPCIデバイスをサポートしていることもそうだろう。NetBSDのUSBとPCMCIA/Cardbusシステムは他の実装の基礎となっている。
Q20 and A20 (スコア:1)
Hubert Feyrer: This depends on the cards that provide these features, and the drivers for them. For Atheros cards, no WAP is available; WiFi-Max is a non-technical term that may be equivalent to the Atheros "Turbo" (108Mps) mode, which is fully working under NetBSD. 802.11 standards supported by NetBSD 2.0 are "b", "a" and "g". (I have no idea if "i" is already out?).
Luke Mewburn: 802.11a/b/g is supported for various cards, including Atheros-based devices. Support for WPA is in progress. No idea about WiFi-Max.
Hubert Feyrer: これはそれらの機能を提供するカードとそのドライバに依存する。例えば、AtherosカードではWAPが利用できない。WiFi-Maxは、技術用語ではなくておそらくAtherosのターボモード(108Mbps)と同じで、NetBSD下で動作する。NetBSDでサポートする802.11標準には"b", "a"と"g"がある("i"がもうできてるかは、わからない)。
Luke Mewburn: 802.11a/b/gは、Atherosをベースとしたデバイスも含め、様々なカードでサポートしている。WPAのサポートは進行中だ。WiFi-Maxはよくわからない。
Re:Q20 and A20 (スコア:1)
> including Atheros-based devices.
> Luke Mewburn: 802.11a/b/gは、Atherosをベースとしたデバイス
> も含め、様々なカードでサポートしている。
ここは、
『802.11a/b/gは、(Atheros社のチップを使用している)多数のカード
をサポートしている』
ではないですかね。
要は、ath* として認識されるカードであれば11a/b/g を利用可能ということで。
(wi* は11bのみ)
Q21 and A21 (スコア:1)
Roland Dowdeswell: The best description can be found in the paper and man pages (which I have on my web page). But, in short form, CGD attaches to a disk or a partition on a disk and presents a pseudo disk to the rest of the operating system. It encrypts and decrypts the information in the transition. So, if you attach a CGD to, say, /dev/wd0e, then when you read and write to /dev/cgd0[a-h] what you get is the decrypted version of what's on /dev/wd0e. You can do anything with /dev/cgd0[a-h] that you can do with normal disks (mainly file systems and swap, but things like database backends are possible).
Roland Dowdeswell: 最高の記述が論文とマニュアルページで、私のウェブページにある(http://www.imrryr.org/~elric/cgd/)。簡単に言えば、CGDは、ディスクまたはディスク上のパーティションに付属させて、OSの他の部分に疑似的なディスクを提示する。そして、その中間でデータの暗号化、復号化を行う。だから、CGDを例えば/dev/wd0eに付属させたとしよう、/dev/cgd0[a-h]を読み書きしてえられるのは実際に/dev/wd0eにある内容を復号化したものだ。/dev/cgd0[a-h]には、通常のディスクにできることはなんでもできる(主にファイルシステムとスワップだが、データベースのバックエンドのようなこともできる)。
Q22 and A22 (スコア:1)
Christos Zoulas: It will work just fine. It is a block-level driver, so it works just like another layer on top of the regular disk.
Roland Dowdeswell: Use of CGD does not affect the OS's behaviour on unexpected system shutdown because it preserves all of the atomicity expectations of the underlying disk device.
Christos Zoulas: うまく動くよ。ブロックレベルのドライバで、通常のディスクの上のもうひとつのレイヤとして働く。
Roland Dowdeswell: CGDの使用はOSの挙動や不意のシステムダウンなどに影響しない。なぜなら、アトミックな予想を配下のディスクデバイスに保存するからだ。
Q23 and A23 (スコア:1)
Roland Dowdeswell: No. When I wrote CGD, I looked for prior art but I found no open source disk encryption that was both usable and cryptographically reasonable. OpenBSD allows you to add encryption to vnd(4), which works in a similar way, but it only supports one cipher (blowfish) and the key generation is weak, so one shouldn't rely on it to actually protect your data.
Given that, I wrote CGD from scratch.
CGD has been partially ported to OpenBSD by Ted Unangst, but last I checked it had not been integrated into the standard release.
Roland Dowdeswell: いや。私がCGDを書いた時点では、先行技術を探したけれどオープンソースのディスク暗号化はソースの面でも暗号化の妥当性からも利用できなかった。OpenBSDは、vnd(4)を津かって暗号化を可能として、同様に動作するが、一つの暗号化方式(blowfish)しかサポートしていなかったし、キーの生成も脆弱だった。だから、本当にデータを守りたいなら、あれに頼るべきではない。
それで、私はCGDを一から書き起こしたんだ。
CGDはTed Unanstによって部分的にOpenBSDに移植されたが、以前私がチェックした時点では標準リリースに統合されていなかった。
質問の日本語訳 (スコア:2, 参考になる)
SMP (スコア:0)
i386以外はNetBSDじゃないんですね。
日本語～ (スコア:1)
Re:日本語～ (スコア:3, 参考になる)
mhatta was here
Re:日本語～ (スコア:0)
# いや、わかる気もするんですが…
Re:日本語～ (スコア:1)
スラッシュドット関係のWikiで使える場所があるといいかもしれませんね。
Re:日本語～ (スコア:1)
＃働いてない人間がいうのもなんですが。
まぁ、以前よくやってたみたいに、このツリーで1パラグラフずつ訳してくのも
よいかもしれません。
あの、、 (スコア:1)
「kqueue」って、なんて発音するんでしょうか？
#「くえ～ぇ」？
Re:あの、、 (スコア:3, おもしろおかしい)
k-queueと切って「ケー・キュー」だと思われ。
＃10queueとか実装したい鉄の人がいるかな、、、
Re:あの、、 (スコア:1, 参考になる)
Re:あの、、 (スコア:0)
Re:あの、、 (スコア:1)
NetBSD2.0 v.s. FreeBSD5.3 (スコア:1)
これは1CPUで行ったものでNetBSD2.0の方が概ね良い結果が出ています.
freebsd-hackersのMLでは, 今のFreeBSDはMPを目指して設計しているので,
MPでも計測して欲しいって話が出ていました.
Re:NetBSD2.0 v.s. FreeBSD5.3 (スコア:1)
既にBSDセクションにこの記事 [srad.jp]がありました.