2010-06-08 :-)
_ 朝ッ
0520 起床
_ たいさく!!
ウェブブラウザが起動したときにそのページを表示するようにしておけばいいんじゃにけ。ファイヤーフォックス的に云えば「Firefoxを起動するとき: 前回終了時のウィンドウとタブを表示する」。まあいままでどおりですが
_ [たべすぎ]2010/6 (a)
自分がむかし書いたメールを読んでいたら、自分でもびっくりするぐらい「イイこと」を書いている部分があった。たとえばこんなの:
Research is an iterative search process. You have to implement your own idea as quickly as possible. It may or may not work, but when it doesn't, modify the code or try something else until you're satisfied (so called re-search). That's how I developed webstemmer. In the beginning, I wasn't even sure if this program was going to work at all. Good luck, Yusuke
研究とは、反復的に探索する作業のことだ。可能な限り素早く自分のアイデアを実装する必要がある。その実装は動作するかもしれないし、しないかもしれない。実装がダメだったとしても自分が満足するまでコードを更新し続けるか、他のことをためすといい( だから "再・探索" と呼ばれる )。それが私が webstemmer を開発した方法だ。最初はこのプログラムがうまくいくか分からなかった(????)。
これは研究活動に対する皮肉かしら。
あわせて読みたい: 研究さん (一休さんの偽物)
_ [NetBSD][rump][翻訳]NetBSD Blog - Kernel Modules Autoload from Host in Rump翻訳
Since early 2009 NetBSD and rump has supported execution of stock kernel module binaries in userspace on x86 architectures. Starting in -current as of today, kernel modules will automatically be loaded from the host into the rump kernel. For example, when mounting a file system in a rump kernel, support will be automatically loaded before mounting is attempted.
2009年の始めに NetBSD と rump を用いて x86 アーキテクチャ上でユーザ領域に溜め込んだカーネルモジュールのバイナリーを実行できるようになった。(今日の) current を使えば、rump カーネル内のホストからカーネルモジュールを自動でロードできる。たとえば、rump カーネル内でファイルシステムをマウントしようとすれば、マウント前に自動でロードが試みられる。
The first issue with autoloading host kernel modules in rump was kernel symbol renaming: to prevent collisions between the application and kernel C symbols, the rump build uses objcopy to prefix symbols with the string rumpns. While running objcopy on a prebuilt kernel module was possible without access to the module's source code, it was a manual step necessary to get a standard kernel module loaded. This was solved by adding a hook to the module loader to adjust the module's string table after it is loaded but before it is linked.
1 つめの課題は、rump 内でカーネルモジュールを自動ロードするとカーネルシンボルがリネームされてしまうことだ: アプリケーションとカーネルとの間で C のシンボルが衝突してしまうことを防ぐために、rump ビルドは、rumpns という接頭文字のシンボルをつけるため( ???? )に objcopy を使用する。標準的なカーネルモジュールロードを取得するためには必要な手順だけど、事前にビルドされたカーネルモジュール上で objcopy を実行している間はモジュールのソースコードにアクセスしなくても出来る。これを解決するために、ロード後のモジュールストリングテーブル( ただしリンクされる前 )を調整するためのモジュールローダーをフックする(仕組み)を追加した。
The second issue was that kernel modules had to be loaded manually by calling rump_sys_modctl(); in contrast kernel modules are commonly autoloaded when necessary. While the standard kernel routines included in a rump kernel would attempt to autoload the module, they would fail because the module files were not available within the rump file system namespace. With some improvements to the rump host file system, etfs, it is now possible to map the kernel module directory (e.g. /stand/i386/5.99.27/modules) inside the rump kernel.
2 つめの課題は、contrast なカーネルモジュール( ? ) 内で一般的な自動ロードをするためには、rump_sys_modctl(); を呼び出だして手動でロードしなければならない。標準的なカーネル関数を含む rump カーネル内で カーネルモジュールを自動ロードしようとしても失敗するだろう。rump ファイルシステム内ではそのモジュールファイルが有効じゃないからだ。etfs のような rump ホストのファイルシステムでは、rump カーネル内ではカーネルモジュールはディレクトリ( 例: /stand/i386/5.99.27/modules ) にマップされるので、これは少し改善される。
Autoloading kernel modules from the host demonstrates a key feature and difference of rump-style lightweight service virtualization: only one full host installation is necessary (although the coexistence of multiple different rump kernel versions is of course possible). This should be contrasted with traditional heavyweight approaches to building virtual services, where each virtual service requires an entire OS installation and maintenance.
ホストからカーネルモジュールを自動ロードするという重要な事例として、軽量な rump スタイルサービスの仮想化についての違いを挙よう( ???? ): 1 つのホストに完全にインストールすることは避けられない( とはいえ、複数の rump カーネルを共存させることは可能だ )。これは、仮想サービスを構築するために従来の重量級な手法とは対称的だ。そこでは各々の仮想サービスは OS の完全インストールが必要だし、それをメンテナンスしなくてはならないという。
