2011-01-01 :-)
_ 新年
あけましておめでとうございます。今年もよろしくおねがいします。
_ 年明け曲
コミケでかんざきひろサークル行ったので年越し時は LINEAR vol.32 [ 20090530#p03 ] を思い出しながら Incarnation 聴いてた。また踊りたいじぇ
_ とか言っていたら
去年の年始も鼻そうめんPを聴いていた [ 20100101#p02 ]
_ 2010 年のふりかえり
目標 [ 20100105#p03 ]
- AsiaBSDCon 2010 に参加する →した
- www.NetBSD.ORG 翻訳プロジェクト で 12 本翻訳完了する →してない。NetBSD blog などに手を出してた
- NetBSD にコードで貢献する →してない
- プログラミング言語に 1 つ手を出す → Python をぼちぼち
- ゲーム3本遊ぶ →してない
- リッジレーサー7 チーム ANS のイベントを企画する →してる ARC2010 - リッジレーサー7
- 外出するときにカメラを持ち歩く →してる Flickr: Your stuff tagged with 散歩
_ 2011 年の目標
NetBSD 翻訳、カメラ、菓子作りはもはやライフワーク化してるんだけどまあ一応
- NetBSD に貢献する
- プログラミング言語 C++ をどげんかせんといかん
- カーネルに強くなる
- カメラ持ち歩く
- チョコレートケーキ作る
- 一人読書会やる
4894713195
4894712059
4894712571
2011-01-02 :-)
_ まああいかわらず目標じゃなくてやることリストになってるんだが
目標は脳内に設定してある。エア目標
_ 2011冬アニメ録画予約した
( 脳とアニメーション-2011第1クール（冬）アニメ一覧 )
とりあえずこんな。少ないな
- 夢喰いメリー TBS 1月6日（木）深夜1時55分～
- IS 〈インフィニット・ストラトス〉TBS 1月6日（木）25：25～
- GOSICK-ゴシック- テレビ東京 1月7日（金）1：23～
- フラクタル フジテレビ 1月13日（木）24：45～
- 放浪息子 フジテレビ 1月13日（木）1：25～
- レベルE テレビ東京 1月10日（月）25：45～（1月17日以降 毎週25：30～）
2011-01-03 :-)
_ 目標なんてのは
- どういう自分に成りたいか
- そう成るためには何をすればよいか
- 具体的なタスクに落としこむ
ただこんだけなんだが三輪の場合「どういう自分に成りたいか」は厨二病が炸裂するので恥ずかしくて書けない。
2011-01-04 :-)
_ [加賀屋][おもてなし]加賀屋のおもてなし
和倉温泉 加賀屋 の台湾 出兵 出店の話題。加賀屋の「おもてなし」についてガイアの夜明けで語られた部分だけを見ると
- 客が旅館に入ってから出るまで面倒を見る
- 1 客室に専任の客室係がつく
などといった特徴があるとのこと。これにより、顧客に注目し、顧客の挙動に注意を払い、顧客が望むことを 察する ことができる。別の言語でいえば「気配り」「気遣い」ということになる。
客の状態ごとにパイプライン的に複数の客室係が代わる代わる処理するよりも
- 専任するほうが客によく注意を払える
- 「自分がその客に責任を持つ」という意識を持たせる
ことができるのであろう。もう少し言えば
- 客が幸せになるためによきにはからう
ということであろう。
ああなるほど「ふつう」じゃねーの ( ふつうのシステム開発〜Rubyとアジャイルで実現する ゆるふわドンピシャ愛されシステム開発 - 角谷HTML化計画(2008-06-20) )
「おもてなし」はよいけど「おせっかい」にならないように注意が必要だけどね
2011-01-05 :-)
_ 午前
0610 起床。0510 にアラームセットしたのに起動しなかった
0800 スターバックス上野
0845 年始の挨拶のため自社 本社 || die
年始の挨拶は本社じゃなくて上野事業所だった ／(＾o＾)＼
アタシはしんだ
0855 年始の挨拶のため自社 上野事業所
0900 社長の言葉
1100 客先 && 仕事始め
_ アラームセットしたのに起動しなかった
環境
Xperia Android 2.1
現象
アラームを 05:10 に設定したが鳴らなかった
やったこと
- 寝る前
- Xperia の電源 OFF
- 充電器に接続
- 就寝
- アラームが鳴らなかった
原因
- Android を 2.1 にしたため
- 電源 OFF のときはアラームが起動しない
詳細
Android 1.6 のころは、Xperia の電源 OFF にして充電器に接続すると Xperia の電源 が自動で ON になった。この動作については 取扱説明書に書いてあるので、正しい 。
Android 2.1 にアップデートしたところ、Xperia の電源 OFF にして充電器に接続すると Xperia の電源 が自動で ON に ならなくなった 。さらに電源 OFF のままだとアラームが起動しない。
対策
電源 ON のまま充電する。
えー
2011-01-06 :-(
2011-01-08 :-)
_ 夜
1800 ヨーカ堂
1900 コーヒーる
1930 GOSICK 見る。ヴィクトリカの「老婆のようなしわがれた声」というのがどう表現されるのかと期待しておったが、なかなか良いですな
2000 夢喰いメリー 見る。夢も希望もありません っていうお話
2100 飯。カキ鍋。うまうま
2200 NHK総合。追跡 AtoZ
2011-01-09 :-)
_ 午後
1200 飯仕込み
1230 ニンテンドー3DS - NINTENDO WORLD 2011 でライブ Ust を見るなど
1300 フレッツ NTT東日本へ連絡。前回といい今回といいオペレーターの声がいわゆる「アニメ声」であった
1500 VIDEO GAME MUSIC LIVE EXTEND
2100 帰宅
2200 飯。豚肉の角煮。今日は弁当ではないので肉を大きめにした。mgmg
_ [ゲーム音楽][VIDEO GAME MUSIC LIVE EXTEND]VIDEO GAME MUSIC LIVE EXTEND
＠新木場 STUDIO COAST
EXTRA - HYPER GAME MUSIC EVENT 2008 [ 20081013#p06 ] は出演者がこの倍くらい居て長時間プレイだったので体力的にかなりキツかったんだが、今回の出演者数ならば割りと勝てる。
STUDIO COAST の 1F フロアの中央辺りだけで区切って、そこに 100 人～200人くらいの客。さらに人口密度が低いので周囲のひとと空間的に余裕がある。EXTRA はアレだけ客が居たのはアイマス効果だったんだろか。まあこれくらいのほうが過ごしやすい。整理番号 18 で、入場に多少遅刻したんだが最前列余裕でした。でも考え直してまったりと最後尾の壁に配置した。
出演者をコピペして出演順に sort
- [H.] (SEGA) (代表作：アウトラン・デイトナUSA他)
- k.h.d.n. (マイルストーン) (代表作：ラジルギシリーズ・カラス他)
- 佐藤豪 (代表作：雷電II・バイパーフェイズI他)
- quad (luvtrax) (代表作：ファミソン8bitアイドルマスター他)
- スペシャル トーク ゲスト 古代祐三 (エインシャント)(代表作：ソーサリアン・ベアナックル他)
- 細江慎治(SUPER SWEEP) 代表作：リッジレーサー・ビートマニア他)
- ZUNTATA (TAITO) (代表作：ダライアス バースト他)
細江慎治さんは 『Operation Ragnarock remix』 powered by Sampling Masters からレイブが炸裂し相変わらず高速 BPM で縦揺れできたので満足した。もう疲れたよ
quad さんはいつも同じ曲をプレイしてるような気がふじこ
しかし、知ってる曲がほとんど無いのはつらいわーマジつらいわー (ノ∀`)
2011-01-10 :-)
_ mixi
2010 年は結局アレ以来マイミクシィ解除されてないや
_ mixi(2)
数えてみたらマイミクシィ 265 人のうち会ったことが無いひとが 80 人以上いた。otsune さんとか一方的には知ってるんだがリアルでは挨拶したことが無いとか Twitter つながりとかリッジレーサーつながりのひとたちなど。リッジのひとたちは skype で会話はするんだけど実際に対面したことがないというのは不思議な感覚だ。
_ NetBSD guide
伊藤さんから反応きた。全部背負い込む気なんだろか
2011-01-11 :-)
_ 大人にとっての「友だち」とは何なのか。
「ベタベタしていなくても、距離が離れていても、極端な話、一度も会ったことがなくても、通じるものがあれば友達」でもいいんじゃないかな。
タイムリーなことになんかいいこと言ってた。
_ YO!
youtube のチャンネル登録してるひとたちを手当たり次第に「友達として追加」したら「やりすぎ。自重しろ」と怒られたので 1 回休み
2011-01-12 :-(
_ NetBSD ローダブルカーネルモジュール入門
http://www.netbsd.org/docs/ からリンクされてるが外部リソースなのでオレオレ翻訳してみた。
_ [翻訳][NetBSD][ローダブルカーネルモジュール][LKM]Introduction to NetBSD loadable kernel modules
NetBSD ローダブルカーネルモジュール入門
Introduction (はじめに)
Loadable kernel modules (LKMs) are quite popular on most modern operating systems such as GNU/Linux, FreeBSD and of course Microsoft Windows, just to name a few. They offer you the possibility to extend the kernel's functionality at runtime without recompiling or even rebooting the system. For example nearly every Linux device driver is available - or can be made available - as a loadable kernel module, that can be loaded at runtime to get support for a particular device (or even a pseudo-device).
ローダブルカーネルモジュール (LKM) は、たとえば GNU/Linux、FreeBSD、そしてもちろん Microsoft Windows のようにモダンなオペレーティングシステムで採用されているものである。これにより、システムを再コンパイルしたり再起動することなしに、カーネル実行中にカーネルの機能を拡張できる。たとえば、最近の Linux デバイスドライバーはすべてこの方式であり、実行中に個々のデバイス (疑似デバイスも含む) を有効にできる。
With NetBSD, LKMs are not that popular yet. At the time of this writing only a few drivers are available as loadable modules (mostly filesystem and compat drivers, and a few others such as the linuxrtc emulation). This might change in near future.
NetBSD の LKM はまだそこまでできていない。ローダブルモジュールとして書かれたいくつかのドライバ (ファイルシステムと互換性ドライバの大部分、そして他のいくつかの linuxrtc エミュレーション) については可能である。これは近々変更される予定だ。
The loadable kernel module interface was originally designed to be similar in functionality to the loadable kernel modules facility provided by SunOS. The lkm(4) facility is controlled by performing ioctl(2) calls on the /dev/lkm device, but since all operations are handled by the modload(8), modunload(8) and modstat(8) programs, you should never have to interact with /dev/lkm directly. Note, that you need to run a kernel compiled with the LKM option in order to make use of LKMs.
もともとローダブルカーネルモジュールのインターフェースは、SunOS のローダブルモジュールと同等の機能を実現するために設計された。lkm(4) は /dev/lkm デバイスを ioctl(2) で呼ぶことで制御できるのだが、modload(8)、modunload(8)、そして modstat(8) プログラムから呼ぶことにより操作する。けっして直接 /dev/lkm を操作してはいけない。(注意: LKM を利用するにはカーネルを LKM オプション付きでコンパイルする必要がある)
Writing the module (モジュールを書こう)
I'd like to show you how to write a simple character device driver that does nothing but the simple job of calculating the FIBONACCI numbers (I'll therefore name the module fibo.o and let all the function's names begin with fibo_). The driver will provide 8 minor devices /dev/fibo0 to /dev/fibo7. Each minor device offers the following functions:
フィボナッチ数を計算するだけの簡単なキャラクタデバイスドライバの書き方を示す( モジュール名は fibo.o とし、関数名は先頭に fibo_ を付けた )。ドライバは /dev/fibo0 から /dev/fibo7 の 8 個をマイナーデバイスを提供する。各デバイスは以下の関数を持つ:
static int fibo_open(dev_t, int, int, struct proc *); static int fibo_close(dev_t, int, int, struct proc *); static int fibo_read(dev_t dev, struct uio *, int);
You can open and close a device provided by this driver and you'll be able to read from it (we'll have a closer look at the parameters later, when we discuss the actual functions). Now we need to tell the kernel that we provide a character device with the 3 functions listed above. Therefore we need to fill in a struct cdevsw (cdevsw means character device switch and the struct cdevsw is defined in sys/conf.h).
ドライバを使うことにより、デバイスの開閉と読み込みができるようになる( ここに書いた関数は後述するような引数をもつ )。前述した、このキャラクタデバイスがもつ 3 つの関数を使えばカーネルと通信できるようになる。そのためには cdevsw 構造体を埋める必要がある( cdevsw はキャラクタデバイススイッチという意味であり、sys/conf.h で定義されている )。
static struct cdevsw fibo_dev = {
fibo_open,
fibo_close,
fibo_read,
(dev_type_write((*))) enodev,
(dev_type_ioctl((*))) enodev,
(dev_type_stop((*))) enodev,
0,
(dev_type_poll((*))) enodev,
(dev_type_mmap((*))) enodev,
0
};
enodev is a generic function that simply returns the errno(2) ENODEV (Operation not supported by device) which says that we does not support any operations besides open, close and read. So, for example, whenever you try to write to the device, the write(2) will fail with ENODEV.
enodev は errno(2) の ENODEV (Operation not supported by device) を返す関数 である。{generic function はプログラミングのテクニックとしての「ジェネリック」のことか? } fibo.o はデバイスの開閉と読み込みしかサポートしないためだ。たとえば write(2) でデバイスに書きこもうとすると ENODEV が返る。
Furtheron we need to tell the kernel how the module is named and where to find information about operations provided by the module. This is a quite simple task with the lkm interface: we use the preprocessor macro MOD_DEV, which is defined in sys/lkm.h to hand the information over. The MOD_DEV macro was changed in NetBSD-current, therefore we use the following construct to get things working with both NetBSD 1.6 and earlier and NetBSD 1.6H and later (thanks to Anil Gopinath for the hint).
では、モジュールを使ってカーネルと通信するためにモジュールが提供する操作について見てみよう{ is named って???? }。 ここでは sys/lkm.h で定義されている MOD_DEV マクロを使い、lkm インターフェースでの簡単な操作をする。MOD_DEV マクロは NetBSD-current で変更されたので、NetBSD 1.6 以前と NetBSD 1.6H 以降の両方で動作するように、以下のように定義しておく( ヒントをくれた Anil Gopinath ありがとう )。
#if (__NetBSD_Version__ >= 106080000)
MOD_DEV("fibo", "fibo", NULL, -1, &fibo_dev, -1);
#else
MOD_DEV("fibo", LM_DT_CHAR, -1, &fibo_dev);
#endif
This means that our module is named fibo, we'll provide a character device (minor devices are handled by the module itself, so they doesn't matter for now), we want to retrieve a dynamic major device number from the kernel (if you want to use a specific major device number you'll need to specify that instead of the -1, but beware of getting in conflict with other device drivers) and we provide the information about the supported operations in fibo_dev.
ここでキャラクタデバイスのモジュール名を fibo とした( マイナーデバイスはモジュール自身によって扱われるが、それは重要ではない )。カーネルからダイナミックメジャーデバイス番号を取得したいので、fibo_dev でサポートしている操作の情報を提供する( メジャーデバイス番号について詳細を取得したい場合、-1 を指定すればよい。ただし他のデバイスドライバと競合するので注意 )。
In order to ensure proper unloading of the module we need to keep a global reference counter of opened minor devices.
モジュールをアンロードするためにオープン済みのマイナーデバイスのグローバル参照カウンタを保持することにする。
static int fibo_refcnt = 0;
And furtheron we need to keep a bunch of information about each minor device.
次に、マイナーデバイスごとの情報を保持しておく。
struct fibo_softc {
int sc_refcnt;
u_int32_t sc_current;
u_int32_t sc_previous;
};
#define MAXFIBODEVS 8
static struct fibo_softc fibo_scs[MAXFIBODEVS];
As mentioned above our driver will provide 8 minor devices. Each minor device stores information about how often it was opened (in our example each minor device can only be opened once because of simplicity), the current number and the previous number for calculating the FIBONACCI numbers. If you don't know how to calculate the FIBONACCI numbers, you should have a look on a book about algorithms, as explaining this is beyond the scope of this article.
前述したとおり、ここで作成するデバイスドライバーは 8 個のマイナーデバイスを扱う。各マイナーデバイスはどのようにオープンされたかという情報( 簡単にするためにここでは 1 度だけオープンされるものとする )と、フィボナッチ数の現在の計算結果と前回の計算結果を保持する。フィボナッチ数の計算についてはこの文書の範囲外なので、アルゴリズムの本を参照するとよい。
Each kernel module needs to have an entry point which is passed to ld(1) by modload when the module is linked. The default module entry point is named xxxinit. If xxxinit cannot be found, an attempt to use modulename_lkmentry will be made, where modulename is the filename of the module being loaded without the .o. In general the entry function will consist entirely of a single DISPATCH line, with DISPATCH being a preprocessor macro defined in sys/lkm.h to handle loading, unloading and stating for us. So our fibo_lkmentry function will look like this:
リンク済みのあらゆるカーネルモジュールは modload の ld(1) から呼ばれるためのエントリーポイントを必要とする。エントリーポイントの名前は既定では xxxinit となっている。xxxinit が見つからなければ modulename_lkmentry を使って作成してみるとよい。モジュールがロードされると、モジュールのファイル名から .o を省いた名前でロードされる。一般的にエントリーポイントは DISPATCH マクロ 1 行だけから成る関数である。DISPATCH は sys/lkm.h で定義されたマクロで、アンロードやステータス取得に使用される。我々の fibo_lkmentry 関数は以下のようになるだろう:
int
fibo_lkmentry(struct lkm_table *lkmtp, int cmd, nt ver)
{
DISPATCH(lkmtp, cmd, ver, fibo_handle, fibo_handle, fibo_handle);
}
Now we need a handler function for our module to do module specific tasks when loading, unloading or stating the module. The name of this handler function is passed to DISPATCH (see above) to tell the kernel which function it has to call when doing such things. A pointer to the module entry in the LKM table and an integer representing the desired command (LKM_E_LOAD, LKM_E_UNLOAD or LKM_E_STAT) are passed to the handler function. The handler is called after the module is linked and loaded into the kernel with the LKM_E_LOAD command. Then we need to check whether the module was already loaded into the kernel and initialize our data structures. When unloading the module, the handler is called with the LKM_E_UNLOAD command and we need to check if the module is not required any more (e.g. check if all devices are closed for char/block driver modules) before confirming the unload command.
モジュールをロード、アンロード、モジュールの状態を得るときにはどうすればよいか。これらの処理をおこなうときはカーネルと通信するのだが、そのためには前述した DISPATCH を書いた関数を利用する。LKM テーブル内にあるエントリーへのポインタと、そのためのコマンド (LKM_E_LOAD, LKM_E_UNLOAD or LKM_E_STAT) へのハンドラ (整数) が利用でき、これらを利用することでハンドラ関数を利用することができる。このハンドラはリンク済みモジュールを LKM_E_LOAD コマンドでカーネルへロードする。次にモジュールがロード済みかどうか、データ構造が初期化済みかどうかチェックしなくてはならない。とくに後処理が必要ないならば( キャラクタ、ブロックドライバモジュールがすべてクローズされているかどうかをチェックしたり ) LKM_E_UNLOAD コマンドでアンロードする。
static int
fibo_handle(struct lkm_table *lkmtp, int cmd)
{
switch (cmd) {
case LKM_E_LOAD:
/* check if module was already loaded */
if (lkmexists(lkmtp))
return (EEXIST);
/* initialize minor device structures */
bzero(fibo_scs, sizeof(fibo_scs));
printf("fibo: FIBONACCI driver loaded successfully\n");
break;
case LKM_E_UNLOAD:
/* check if a minor device is opened */
if (fibo_refcnt > 0)
return (EBUSY);
break;
case LKM_E_STAT:
break;
default:
return (EIO);
}
return (0);
}
The open function is quite simple as most of the hard stuff is already handled by the NetBSD kernel (e.g. the kernel will automatically allocate a vnode(9) for you). The parameters for the open function are the major and minor device numbers (use the major and minor macros), the flag and mode arguments as described in open(2) and a pointer to the struct proc of the process that did the open system call.
オープン処理はとても簡単で、NetBSD カーネルがやってくれている( たとえばカーネルは自動的に vnode(9) を確保してくれる )。オープン処理の引数にはデバイスのメジャー番号とマイナー番号を渡す ( major と minor マクロを利用すればよい )。フラグとモードは open(2) と同じ。プロセスの proc 構造体へのポインタも open システムコールと同じである。
So the first thing to do is to check if the minor device number we got when the device was opened is not out of range, and if the minor device is not already opened. You should always keep in mind that the minor device handling is completely up to you and that this is a never ending source of mistakes! Then we need to initialize the minor device data (the FIBONACCI starting numbers: = 1, 0 + 1 = 1, 1 + 1 = 2, 1 + 2 = 3, ...) and increase the minor device and the global module reference counter.
最初にやることは、デバイスがオープン済みかどうかをチェックすることだ。これはマイナーデバイス番号が out of range ではないことをチェックすればよい。
static int
fibo_open(dev_t dev, int flag, int mode, struct proc *p)
{
struct fibo_softc *fibosc = (fibo_scs + minor(dev));
if (minor(dev) >= MAXFIBODEVS)
return (ENODEV);
/* check if device already open */
if (fibosc->sc_refcnt > 0)
return (EBUSY);
fibosc->sc_current = 1;
fibosc->sc_previous = 0;
/* increase device reference counter */
fibosc->sc_refcnt++;
/* increase module reference counter */
fibo_refcnt++;
return (0);
}
The close function has the same parameters with the same meanings as the open function described above. It is used to free the internal data structures of a minor device opened before. You do not need to worry whether the device was opened before or to do things like releasing the vnode associated with the device, all you need to do is to cleanup the module specific stuff. In our example this means decreasing the minor device and the global module reference counters and so that our close function is quite simple.
close 関数は open 関数と同じような引数を受け取り、オープンされているマイナーデバイスの構造体( これは内部データである )を解放する。ユーザーはデバイスがオープン済みかどうか、vnode が関連付けられているかどうかを気にする必要はない。モジュールがよきに計らってくれる。ここで示す close 関数の例では、マイナーデバイスとグローバルモジュールリファレンスカウンタを減算するだけの簡単なものになっている。
static int
fibo_close(dev_t dev, int flag, int mode, struct proc *p)
{
struct fibo_softc *fibosc = (fibo_scs + minor(dev));
/* decrease device reference counter */
fibosc->sc_refcnt--;
/* decrease module reference counter */
fibo_refcnt--;
return (0);
}
Last but not least the read function. This function has 3 parameters: the device major and minor numbers like in the open and close functions, a flag field indicating for example whether the read should be done in a non-blocking fashion or such things and a pointer to a struct uio defined by sys/uio.h. A struct uio typically describes data in motion, in case of a read(2) system call data moved from kernel-space to user-space. This may look a bit strange if you have already done device driver progamming on GNU/Linux, but the uio concept used by the NetBSD kernel simplifies a lot of things and provides a generic and consistent interface for kernel-space to user-space and kernel-space to kernel-space data moving. See uiomove(9) for more information.
最後に read 関数に触れておく。この関数は 3 つの引数を受け取る。open 関数や close 関数と同じようにメジャーデバイス番号、マイナーデバイス番号、非ブロック実行などを示すフラグ、そして uio 構造体へのポインタ( sys/uio.h で定義されている ) だ。uio 構造体は、read(2) システムコールのようにカーネル空間からユーザー空間へデータを移動させる場合、たいてい以下のように定義される { ????? } 。あなたが GNU/Linux でのデバイスドライバプログラミングの経験があるならば、少し違うということに気付くかもしれない。NetBSD カーネルで使用されている uio 実装は、多様な場面で利用でき、汎用的であり、カーネル空間からユーザー空間へのデータ移動と、カーネル空間からカーネル空間へのデータ移動のインターフフェースに一貫性を持たせることが簡単に出来る。詳細は uiomove(9) を参照。
Back on stage, we should first have a look at the read function and discuss the details afterwards.
まず read 関数を見て、そのあとに詳細を議論しよう。
static int
fibo_read(dev_t dev, struct uio *uio, int flag)
{
struct fibo_softc *fibosc = (fibo_scs + minor(dev));
if (uio->uio_resid < sizeof(u_int32_t))
return (EINVAL);
while (uio->uio_resid >= sizeof(u_int32_t)) {
int error;
/* copy to user space */
if ((error = uiomove(&(fibosc->sc_current),
sizeof(fibosc->sc_current), uio))) {
return (error);
}
/* prevent overflow */
if (fibosc->sc_current > (MAXFIBONUM - 1)) {
fibosc->sc_current = 1;
fibosc->sc_previous = 0;
continue;
}
/* calculate */ {
u_int32_t tmp;
tmp = fibosc->sc_current;
fibosc->sc_current += fibosc->sc_previous;
fibosc->sc_previous = tmp;
}
}
return (0);
}
So the first thing we do, is to check whether the process requests less than sizeof(u_int32_t) bytes (actually 4 bytes). Our read function always reads a bunch of 4-byte blocks and to keep it simple and easy to understand we disallow reading less than 4 bytes at a time (uio->uio_resid holds the number of remaining bytes to move to user-space, automatically decreased by uiomove).
最初にやることは、プロセスリクエストが sizeof(u_int32_t) (たいてい 4 バイト)以下であることをチェックすることだ。read 関数は 4 バイトブロックとして読み込む。4 バイト以上とすることで簡単で理解しやすい実装になる( uio->uio_resid はユーザー空間へ移動させたバイト数を保持していて、uiomove により自動的に減算されていく )。
The function copies the current FIBONACCI number into the user-space buffer, checks for a possible overflow (only the first 42 FIBONACCI numbers fit into u_int32_t) and calculates the next FIBONACCI number. If there is enough space left in the user-space buffer, the function loops and restarts the process of moving, checking and calculating until the buffer is filled up to the possible maximum or uiomove(9) returns an error. Note, that a read(2) system call on this device will never return 0, and so it will never reach an end-of-file (EOF), so the device will generate FIBONACCI numbers forever.
フィボナッチ数計算処理におけるユーザー空間でのバッファーコピーではオーバーフローをチェックでき( ただし u_int32_t 以内に収まる 42 回目の計算まで ) それから次のフィボナッチ数を計算する。ユーザー空間にじゅうぶんな空き領域があるならば、最大数 { u_int32_t のこと ???? } に達したり uiomove(9) がエラーを返さない限りは処理はループし、ユーザー空間への移動処理を再開し、計算結果をチェックしつつフィボナッチ数を計算し続ける。注意: このデバイスでの read(2) システムコールは 0 を返さない。EOF も検出しない。計算したフィボナッチ数を返し続ける。
If you're familar with GNU/Linux device driver programming you might have noticed that we do not return -ERRNO on failure, and in case of the read system call the number of bytes read, but instead we return 0 on success and the positive errno value on failure. Everything else is handled by the NetBSD kernel itself, so we do not need to care about.
GNU/Linux でのデバイスドライバプログラミングに慣れているならば、失敗時には -ERRNO を返し、read システムコールは読み込んだバイト数を返すことを期待するだろうが、ここでは、成功時に 0 を返し、失敗時は errno を使うようにしている。これは NetBSD カーネルの慣習にならったものである。
Loading the module (モジュールをロードしよう)
Now that our device driver module is completed, we need a shell script that will be executed when the module is successfully loaded to create the required device nodes in /dev. This shell script (or program) is always passed three arguments: the module id (in decimal), the module type (in hexadecimal) and the character major device number (this differs for other types of LKMs such as system call modules). So our script is pretty simple:
デバイスドライバーは完成した。/dev にデバイス作成の要求があったときにモジュールがちゃんとロードがされるようにシェルスクリプトを書く。シェルスクリプト( またはプログラム ) は 3 つの引数をとる。モジュール ID (10進数)、モジュールタイプ (16進数)、そしてキャラクタデバイスのメジャー番号( システムコールモジュールを使う他の LKM とは異なる )だ。スクリプトはじつに簡単になる。
if [ $# -ne 3 ]; then echo "$0 should only be called from modload(8) with 3 args" exit 1 fi
First check whether all three command line arguments are present and exit with error code if not.
最初にコマンドライン引数が 3 つあるかチェックしている。無ければエラーとともに終了する。
for i in 0 1 2 3 4 5 6 7; do rm -f /dev/fibo$i mknod /dev/fibo$i c $3 $i chmod 666 /dev/fibo$i done exit 0
And finally (re)create the required special device nodes. Now we are ready to give our module a first test run. Compile the module and load the module with the following command (this needs to be run as superuser):
最後に要求があったスペシャルデバイスノードを作成する。これで第一歩の準備が整った。モジュールをコンパイルし、ロードするには以下のコマンドを実行する( スーパーユーザーで実行すること )。
modload -e fibo_lkmentry -p fibo_post.sh fibo.o
If everything went well, the modstat(8) program should present you output similar to this:
成功した場合、modstat(8) を実行すると以下のような出力になる。
Type Id Off Loadaddr Size Info Rev Module Name DEV 0 29 dca4f000 0004 dca4f260 1 fibo
Testing the module (モジュールをテストしよう)
In order to test your new kernel module, we need a small test program that does nothing more than reading a 32bit unsigned integer value from /dev/fibo0 and outputs the value to standard output. See the sample program below:
新しいカーネルモジュールをテストするために、/dev/fibo0 から 32 ビット符号なし整数を読み込み、標準出力へ出力するだけの小さいテストプログラムを書く。たとえばこう
#define DEVICE "/dev/fibo0"
int
main(int argc, char **argv)
{
u_int32_t val;
int fd, ret;
if ((fd = open(DEVICE, O_RDONLY)) < 0)
err(1, "unable to open " DEVICE);
while ((ret = read(fd, &val, sizeof(val))) == sizeof(val))
printf("%u\n", val);
if (ret < 0)
err(2, "read(" DEVICE ")");
close(fd);
return 0;
}
When you run this sample test program, it will output FIBONACCI numbers below 2971215074 until you interrupt or kill the program. To unload the kernel module, you need to run the following command (as superuser):
このテストプログラムを実行すると、途中で Ctrl+C させるか、または kill しない限り 2971215074 までのフィボナッチ数を出力し続ける。カーネルモジュールをアンロードするにはスーパーユーザーで以下のコマンドを実行する。
modunload -n fibo
A tar archive which contains the complete sources from the example above with a Makefile can be found here. I hope you liked this small introduction to the NetBSD lkm system. If you have any questions or if you would like to give me some feedback feel free mailing to benny@xfce.org.
ここで示したサンプルプログラムの tar 書庫は こちら からダウンロードできる。これには Makefile なども含まれている。これがあなたにとって NetBSD lkm システムを知る足がかりとなることを願う。質問など何かフィードバックがある方はフリーのメーリングリスト benny@xfce.org に投げてほしい。
2011-01-14 :-)
_ テスト
#!/bin/sh echo hoge
_ [hikifarm][シンタックスハイライト] hikifarm でシンタックスハイライト
といっても google-code-prettify - Project Hosting on Google Code を使うだけ。
tdiary からコピペしたアレを hikifarm/plugin/00default.rb の def hiki_header に追加。prettify.{css,js} の場所はテキトーに。
<link href="../../prettify.css" type="text/css" rel="stylesheet" />
<script type="text/javascript" src="../../prettify.js"></script>
<script type="text/javascript"><!--
function google_prettify(){
var divs=document.getElementsByTagName("div");
for(var i=divs.length;i-- >0;){
if(divs[i].className!="body")continue;
var pres=divs[i].getElementsByTagName("pre");
for(var j=pres.length;j-- >0;){
pres[j].className="prettyprint";
}
}
prettyPrint();
}
if(window.addEventListener){
window.addEventListener('load',google_prettify,false);
}else if(window.attachEvent){
window.attachEvent('onload',google_prettify);
}else{
window.onload=google_prettify;
}
// --></script>
2011-01-15 :-)
_ LINEAR vol.42
新年最初なんだが行ってない。最初に tuvasa さんがきてトリが細江慎治さんという珍しい構成なんだが
17:10-17:40 佐野電磁
30 分ということはいつものトークライブか
_ [リッジレーサー7]リッジレーサー7 ARC 2010 睦月GP
GT5 の息抜きにリッジは如何ですか。みんな GT5 やってるから参加者すくないかー と嘆いていたんだがけっこう集まるものである。
- CONTI4X 146
- SOLARE 125
- かず 100
- ANSΩ三嶋出雲 97
- knhtymh 96
- ANSΩmiwarin 83
- zero 83
- MEDAL 75
- REDOGRE 64
- Locus 59
- megu.Girls 31
- ANSΩB2マンタレイ 25
- ANSΩ八雲藍 15
- agumon11 11
新年初めてのレースなんだが割りとボロボロだった。
- 走行距離 97656 km
- RSGP 進行度 100.0 %
- 名声 26191 FP
- オンラインバトル勝利数 1155/4086
2011-01-22 :-)
2011-01-25 :-)
_ 午前
0500 起床 || 新聞読む。ロシアでテロ。リアル CoD.... (不謹慎) ( 【閲覧注意】YouTube - Call of Duty Modern Warfare 2 ロシア人虐殺ステージ 「No Russian」 )
0830 出勤
0930 実機動作
_ 午後
1330 研修＠自社上野
_ object oriented
以前 尾藤正人さんと飯食べたときに「 Python is NOT object oriented language :-( Ruby is REAL object oriented language :-) 」などと言っていたことを思いだしている。
_ [mechanize][ruby]mechanize
久しぶりに手元の mechanize なコードを走らせてみたら怒られた。
!!!!! DEPRECATION NOTICE !!!!! The WWW constant is deprecated, please switch to the new top-level Mechanize constant. WWW will be removed in Mechanize version 2.0 You've referenced the WWW constant from usr/local/bin/book_meter.rb:19:in `get', please switch the "WWW" to "Mechanize". Thanks! Sincerely, Pew Pew Pew
WWW::Mechanize じゃなくてたんに Mechanize になったらしい。
- agent = WWW::Mechanize.new + agent = Mechanize.new
2011-01-26 :-)
_ [NetBSD][翻訳][eMIPS]NetBSD Blog - Support for Microsoft eMIPS ("Extensible MIPS") platform committed
Microsoft eMIPS ("Extensible MIPS") プラットフォームサポートがコミットされた
In April 2009 I got an email from Alessandro Forin containing this picture as an attachment. His group at Microsoft Research was investigating dynamically reconfigurable computing and needed an operating system for testing purposes. I was happy that they were using NetBSD for their research and was especially pleased to learn that they had also evaluated another general purpose open source OS but found NetBSD vastly superior for their purposes. Jokingly I even suggested they should send patches. A few months later I got another mail from Sandro saying: "Believe it or not this might actually happen". There were a number of issues to work on, including the paperwork for getting the copyright transferred from Microsoft Corporation to The NetBSD Foundation and forward-porting the NetBSD 4.x-based code to -current, but now I am pleased to announce I have just committed the eMIPS port to the NetBSD source tree.
2009 年 4 月 Alessandro Forin から 1 通のメールが届いた。それには このような絵 が添付されていた。マイクロソフトリサーチでの彼のグループは、動的再構成可能コンピューティング { Reconfigurable computing - Wikipedia } とそのテスト方法について調査していた。研究だけでなく評価のためにも NetBSD が使われ、他の一般的なオープンソースオペレーティングシステムではなく NetBSD が彼らの研究に特化しているということが嬉しかった。ためしに彼らに「パッチを送ってくれ」と提案してみた。数ヵ月後 Sandro からメールが届いた。「これが何か役立つかな? 」そこではいくつか作業が報告されていた。事務処理を含むマイクロソフトから The NetBSD Foundation への著作権の譲渡、そして NetBSD 4.x ベースのコードから -current への移植があったが、私には NetBSD current への eMIPS ポートが嬉しかった。
The Microsoft Research eMIPS page gives the following summary of the eMIPS architecture:
マイクロソフトリサーチの eMIPS ページ には eMIPS アーキテクチャの概要が書いてある:
The "extensible MIPS" is a dynamically extensible processor for general-purpose, multi-user systems. The reconfigurable logic (Extensions) dynamically load/unload application-specific circuits. Extensions add specialized instructions to the processor, security monitors, debuggers, new on-chip peripherals. Extended Instructions dramatically speedup application programs, just by patching their binaries. eMIPS runs NetBSD on the Xilinx ML401/2 (Virtex V4) XUP (V5), and on the BEE3(4xV5).
extensible MIPS は、一般的にはマルチユーザーシステムでの動的エクステンシブルプロセッサとして使われる。 reconfigurable logic (拡張) { 「動的再構成可能」とでも言えばよいのか? }とは、動的に ASIC (application-specific circuits) をロード/アンロードするものである。Extensions とは、プロセッサや、セキュリティモニターや、デバッガや、新しいオンチップペリフェラルに特別な命令を追加するものである。拡張された命令により、アプリケーションプログラムのバイナリにパッチを当てるだけで劇的にスピードアップする。eMIPS は Xilinx ML401/2 (Virtex V4) XUP (V5)、 BEE3(4xV5) 上の NetBSD で走る。
What makes NetBSD/emips an appealing platform for researchers and hobbyists interested in the MIPS architecture is the full availability of the CPU and platform peripheral source code. Testing of modifications can be done on FPGA platforms or in the Giano system simulator which available for download here.
NetBSD/emips は、MIPS アーキテクチャを扱う研究、趣味で使え、CPU とプラットフォーム独特のソースコード上でフルに活用できる。Giano システムシミュレータにより、FPGA プラットフォームでのテストは済んでいる。Giano は ここ からダウンロードできる。
The NetBSD port page for eMIPS is at http://www.NetBSD.org/ports/emips/. Among other things, it contains links to hardware vendors and installation instructions for NetBSD/emips using the Giano simulator. NetBSD daily autobuild system will eventually offer NetBSD/emips binaries for download. Meanwhile, Microsoft Research offers a download for NetBSD 4.0.1 here.
NetBSD の eMIPS ポートのページはこちら http://www.NetBSD.org/ports/emips/ 。このページには、ハードウェアベンダと Giano シミュレータに使われた NetBSD/emips 命令セットも含まれている。いずれ NetBSD の毎日の自動ビルド に NetBSD/emips が含まれ、バイナリがダウンロードできるようになるだろう。それまではマイクロソフトリサーチの こちら のページから NetBSD 4.0.1 がダウンロードできるのでどうぞ。
In addition to the eMIPS port, Microsoft contributed a machine independent framework for hardware accelerator scheduling, a scheduling policy for it, and a secure executable format. They will be proposed shortly on the tech-kern mailing list. Meanwhile, please have fun with eMIPS!
eMIPS ポートについて補足。マイクロソフトはハードウェアアクセラレータスケジューリングと、そのためのスケージューリングポリシー、そしてセキュア実行形式をサポートするためのマシン依存のフレームワークを配布している。それらは近いうちに tech-kern メーリングリストに流されるだろう。乞うご期待!
2011-01-27 :-(
_ [NetBSD][翻訳][EC2][amazon]hubertf's NetBSD blog - NetBSD/cloud - running NetBSD on Amazon's EC2
NetBSD/cloud - Amazon EC2 上の NetBSD
Citing the EC2 website, ``Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.
EC2 ウェブサイト から引用:
Amazon Elastic Compute Cloud (Amazon EC2) はクラウドによってサイズ可変な計算資源を提供するウェブサービスである。容易にスケールできるウェブ資源を開発者へ提供する。
Amazon EC2's simple web service interface allows you to obtain and configure capacity with minimal friction. It provides you with complete control of your computing resources and lets you run on Amazon's proven computing environment. Amazon EC2 reduces the time required to obtain and boot new server instances to minutes, allowing you to quickly scale capacity, both up and down, as your computing requirements change. Amazon EC2 changes the economics of computing by allowing you to pay only for capacity that you actually use. Amazon EC2 provides developers the tools to build failure resilient applications and isolate themselves from common failure scenarios. ''
Amazon EC2 ではシンプルなインターフェースにより、僅かな手間でキャパシティを設定することができる。これにより、計算資源を完璧に制御でき、Amazon が提供する計算環境でサービスを作ることができる。Amazon EC2 はサービスを立ち上げるまでの時間を短縮し、新しいサーバーをほんのわずかな時間で起動することができるし、必要な計算資源が変わればキャパシティの増減をサクっとスケールできる。実際に使うキャパシティのぶんだけ料金を支払ってくれれば、Amazon EC2は省力化された計算資源を提供する。Amazon EC2 は、言う事を聞かないアプリケーション { 想定外の動作という意味?????? } があれば失敗するようにさせ、既知の失敗ならばそれを隔離するためのツールを開発者へ提供する。
Internally, EC2 is based on Xen. And NetBSD also runs on Xen. So what's nearer than running NetBSD on EC2? Well, apparently it took some time and fiddling to get things together, but Alistair Crooks has posted a shell script on how to start working with NetBSD on Amazon's EC2 now. Note that pkgs for using EC2 are currently under development by Jean-Yves Migeon, and that there may be some manual fiddling required.
内部的には EC2 は Xen をもとにしている。そして NetBSD も Xen で走る。なので、EC2 では NetBSD が走ってるんじゃないかと思うのだが如何なものか? いやね、いくつか挙動を見るとそういうふうに思えるし、Alistair Crooks による「 Amazojn EC2 上の NetBSD でシェルスクリプトを走らせる方法」 という記事もあるのだよ。また、EC2 を利用するための Jean-Yves Migeon が開発している pkgs がある。ちょいと手間をかけないといけないけど。
Updated documentation (wiki, anyone?) are appreciated - who's first to post a dmesg(8) output to port-xen? :)
wiki などのドキュメントを更新してくれると嬉しいもしれず。誰が最初に Xen の dmesg(8) 出力を投稿してくれるだろか? :)
2011-01-30 :-)
_ 午前
0700 起床
0830 NTT東日本来たる && フレッツ光 終端装置回収
0900 旧部屋の写真を撮る。撮るたびに記憶が蘇り、いちいち涙が溢れるのでまったく撮影作業が進まない。
1000 荷物開放
1100 隣の方々に挨拶など。じつは親は知り合いらしい
_ youichi [>> 厨二病が炸裂 呼んだ?]
_ みわ [いえ知りません ω・)]