Linux デバイスドライバ 第３版

前に書いた解読室は紙質がいいので重いので、Linuxデバイスドライバを変わりに読んでいる

そしたら前に書いたcurrentは何かということがちゃんと書かれていた。

currentはカレントプロセスを現すグローバル変数として表現されるが、マルチスレッド/CPUでアクセスされるため、実装は環境依存となっている

らしい。それなら納得。

Linuxデバイスドライバ 第3版

• 作者: ジョナサン コルベット
• 出版社/メーカー: オライリージャパン
• 発売日: 2005/10
• メディア: 単行本

Linuxカーネル解読室

次の仕事はLinuxが関係してるそうなので、例によって積読になっていた本をあさる。

まだ一章のプロセススケジューリングのところを読んでるのだが、１つ気になることが。
schedule関数の頭で

prev = current

としている部分があったが、以下の点が気になった

・currentはどこから来たのか？
・currentがnullの可能性は無いのか？

ポインタはすべてnullチェックせよという教えに反するし、currentはグローバルなんだろうか。引数でもないし。
ただ、それまでの文章で、「アイドル時にはアイドル用プロセスが動く」とあるのでcurrentがnullであることはないんだろう。設計思想として、アイドル時にはアイドル用プロセスが動くようにしたことで、currentがnullであることは無くなった、が正解なのか？
あと、「currentを書き換えるのが誰か？」によってInterlockなどの同期の仕組みが必要になると思うが、そういうのもない。

こういうのって集団でプログラム作ってるとすごい危険だよなぁ。「どんなタイミングでも」currentが正常である前提でプログラム書いてしまう人が出てくるし。あえて強調したのは、どんなタイミングでも正常に変数がセットされていることは無い。当然だが初期化と終了時にはセットされてないことはある。マルチスレッドだと特に不完全な変数を参照してしまいがちになる。この場合はスケジューラーの話なので、複数のCPUで動かすことは無い前提なのかもしれないが、この手の同期が必要かどうかは設計思想に依存するので、実装における設計思想をもう少し記述してもらうとありがたいかなーと思う。まあ、基本概念の説明だけでも結構な量になってるからそこまでケアするのは大変だろうけれども。

Linuxカーネル2.6解読室

• 作者: 高橋浩和
• 出版社/メーカー: ソフトバンククリエイティブ
• 発売日: 2006/11/18
• メディア: 単行本

VMWareにDebianをインストールした後のVMwaretoolsを入れる方法

$ sudo rm -rf /etc/vmware-tools
とコマンドを実行しゴミファイルを掃除

そしてカーネルのヘッダーをインストールします
カーネルのリリースバージョンを確認し、それに合ったヘッダーをインストールします
$ uname -r
2.6.18-4-k7
$ sudo apt-get install linux-headers-2.6.18-4-k7

そしてmake用のツール一式をインストールします
$ sudo apt-get insall build-essential

VMtoolsのインストールを選ぶと（仮想）CDROMドライブにファイルがでてくるので、それを適当なフォルダに解凍する
$ tar zxvf VMwareTools-1.0.2-39867.tar.gz

# cd vmware-tools-distrib
# ./vmware-install.pl

ツールボックスを起動しOptionタグの「Time syncrononization ・・・」のチェックをONにする
# vmware-toolbox &

ライセンスについての忘れないうちにメモ

２ｃｈのどっかのスレで、テンプレートライブラリを公開したいが、GPLにはしたくない、でもフィードバックは欲しい（のでオープンにしてほしい）、というようなことでLGPLが適用できるかどうかという話があった。

が、LGPLは、一般的なライブラリを想定していて、テンプレートライブラリは想定していない記述がある。

「ヘッダファイルからパラメータや10行以下のコピーならOK」

あくまでソースコード本体はCでコンパイルされていて、ヘッダには中身が無いという前提で書かれている。
もちろんテンプレートライブラリは間違いなくヘッダがメインなので、LGPLは適用できないかもしれない。

で、天下のBoost先生が何やってるかというと、ちゃんとライセンス作って商標利用もOKというライセンスを作っている。そもそも公開する必要が無ければBSDライセンスで（著作権は持ってるけど、あとは何してもOKだし公開しなくてもいいよ）でよい。しかし、フィードバックが欲しいので公開して欲しいとなるとLGPLでは上記の問題がある。

で、いろいろ調べて見るとMPLが良いのではないかという話になった。「商標利用などはいくらでもOKだし、派生物は公開しなくていいけど、変更加えたら公開してね」というライセンス。BSDでもLGPLでもうまくいかない場合は、MPLというのが良いようだ。

上記の問題以外にGPLとLGPLについてのメモ

仕事で使えるかどうかは、「GPLが感染する」かどうかにかかっている。フリーならば最悪ばっくれればよいが、仕事となるとそうはいかない。どこぞのエロゲーで動画ファイルにXvidのソースを流用したことがばれてソース公開するはめになった事件もある。

GPLは一般的には商用としては使えない。Linuxで飯を食ってる人たちは、ソフトウェア料金の変わりに保守料でまかなっている。でもどうしてもLinuxのフリーななかで、プロプライエタリな商売してみたいなぁ、なんて場合のポイント。

・GCCで生成されたものはGPLの対象外（なので問題ない）。
・LGPLについては、上記にあるとおり、ヘッダファイルを使い、「スタティックリンクではなく、ダイナミックライブラリの使用」に限って、LGPLは伝播しない。

自分はスタティック派なので、これは気をつけねばならない。