dmraidの苦悩（その２）
限定的な環境ではあるが、dmraidがRAID1(mirror)で動作することをやっと確認した。せっかくの良いニュースなので、エイプリル・フールと間違われないような配慮も必要だった。今回も前回に続いてdmraidに関連した話題を取り上げる。
カーネル
dmraidの苦悩（その１）
そもそも去年（2004年）の7月にdmraid 1.0.0-rc1がアナウンスされてから、筆者の苦悩が始まった。かなり長い間、dmraidを動かすことができなかったのがその理由である。そしてKernel 2.6.8以降のカーネル・ツリーやFedora Core 3で正式採用された今でも、dmraidはまともには動かないようだ。
RelayFS
2.6.11-rc1-mm1のアナウンスの最初に、次のようなAndrew Mortonのコメントをみつけることができる。「Linux Trace Toolkitと、それに従ってrelayfsを加えた。あなたと同様、LTTには今まではそれほど注目していなかったというのが主な理由で。それはたいしたものでないが、少しだけkernel <-> user周りの仕事を必要とする。」
Restricted hard realtime（その２）
LKMLではリアルタイムカーネルに関する前回の議論の後、別の実装に関する議論が始まった。リアルタイム機能に関しては標準カーネルでは現在持ってなく、間違いなく今後実装されていく機能であるだけに、開発や実験が各所で行われ、しばしば長いやりとりを引き起こすのだが、そんな様子を垣間見ることができる。
Restricted hard realtime（その１）
リアルタイムカーネルの探究は何年もの間、非常に多くの仕事や多くの寄付を受けて続いている。また、常に新しい人々がそれをより良くするためのアイデアを提案してきている。Paul E. McKenneyが提案したのは、他のCPUにシステムコールと時間を消費するオペレーション負荷を移動することにより、リアルタイムSMPシステムを作成するメカニズムである。
Linux 2.6 Real Time Kernel
この作業の目的は、割込みレイテンシをさらに縮小し、2.6のカーネル・シリーズのタスク・プリエンプション・レイテンシを、画期的に縮めることである。我々の広大な目的は、ワーストケースのIRQ disableによって、限界のあるプリエンプション・レイテンシを達成することである。
Power Managementの混沌（その３）
Patrick MochelがPower Managementのコードを分岐させた顛末については、以前の記事でも取り上げた。例年通りオタワで今年7月、Linux Kernel Developers Summit 2004が開催されたが、その直前に一旦分岐したコードがマージされることになった。
Linux Kernel Developers Summit 2004報告 (2)
前回に引き続きOTTAWAで行われたLinux Kernel Developers Summitの2日目の模様を報告する。世界中から注目を集めている次期Linuxカーネル 2.7についての開始時期についても議論がされた。
Linux Kernel Developers Summit 2004報告 (1)
今年のLinux Kernel Developers Summitも、例年通りOTTAWAで開催された。世界中から主だったカーネル開発者が集まり、次期Linuxカーネル 2.7に向けた活動に関して議論がなされた。
Linux RAID （その２）
前回に続いて、MD （Linux ソフトウェアRAIDドライバ）に関する話題を取り上げる。範囲が広い話題だが、MDの今後のエンハンスメントの方向と、カーネル2.6における実装やDM(Device Mapper)との役割分担に関する議論を垣間見ることができる。
Linux RAID（その１）
「やあ皆さん。我々はカーネル2.6.xシリーズでうまく動作できるローコストで、高い信頼性のIDE
RAIDソリューションを捜している。」Dr. Johannes Ruscheinskiからのこの問い合わせがきっかけで始まったLKMLのスレッドでは、LinuxソフトウェアRAIDに関して、興味深い議論が展開されていった。
dm-cryptと2.6シリーズ・カーネルでパーティションを暗号化
今年2月、Andrew Mortenは、cryptoloopはdm-cryptによって置き換えられることになると発表した。この発表が行われた当時には多少の混乱もあったが、dm-cryptはいまや2.6.4カーネルの安定ツリーの一員となっている。本稿では、dm-cryptを使用した暗号化パーティションのセットアップ方法について見ていきたい。
Intel Vs. AMD x86-64
今年2月中旬、後世に残る大きな出来事があった。インテルがAMD64アーキテクチャを採用したのだ。これは、オペレーティングシステムを始めとするソフトウェアの開発者達にとっては、素晴らしい出来事だったと言えよう。
Linuxカーネル開発者の信用を文書化する新しいプロセス
Linus Torvaldsは、25人ほどいるLinuxカーネルサブシステムのメンテナンス担当者の誰かから送られてきたコードなら、無断借用されたものでないと信じている。TorvaldsとOSDL（Open Source Development Labs）からの提案によれば、今日から、SCOが起こしているような知的所有権（IP）クレームを防ぐための「信頼の連鎖」を文書化する承認プロセスが整備されるということだ。
RFD：Linuxパッチの配布プロセスを明示的に記録する提案
編集部より: Linus Torvaldsが、Linux Kernel Mailing Listに以下のRFD（Request for Discussion）を投稿した。この中で彼は、SCOのような攻撃を再び受けないようにする方法を提案している。
マルチプロセッサとスケジューラ（その３）
CPUのアーキテクチャが将来はマルチCPU中心に変わっていく。そのための新しい命令が追加されているのだが、まだあまり一般的には広まっていないかも知れない。
プロプライエタリ・ドライバによるLinuxカーネルの「汚染」
Slashdotなど、さまざまな媒体で報じられているとおり、Linuxカーネル上で動作するプロプライエタリなモジュールの一部が、そのライセンシングを偽装していたことが、Linuxカーネルのハッカーたちによって明らかにされた。
マルチプロセッサとスケジューラ（その２）
前回に続いて、マルチプロセッサとHyperthreading(HT)のスケジューリングに関する話題を取り上げる。最近のIntel等の動向を見ると、チップ上に複数CPUコアを載せる手法（CMPまたはマルチコア）は、今後のプロセッサ市場では一般的になるらしい。
マルチプロセッサとスケジューラ（その１）
マルチプロセッサ、スケジューラ、Hyperthreading、NUMA．．． 今後のマイクロプロセッサ技術の進化に伴って、2.6以降のカーネルが新たにサポートしていくべき、密接に絡み合うトピックスについて、どのあたりから取り上げようかと考えてしまう。
パワーマネジメント概要（その３）
今回は、前回に続いてカーネル2.6の新しいパワーマネジメント機構における、「デバイス・パワーマネジメント」と「ドライバへの要求」を取り上げる。
