玩式草子─ソフトウェアとたわむれる日々

第30回 64ビット化への遠い道程[まとめ]

この記事を読むのに必要な時間:およそ 4 分

つい先日新年を迎えたかと思っていたら,あっと言う間に1月も終りに近づいてしまいました。そのため,タイミング的にはやや旧聞に属する感もありますが,昨年の年末ぎりぎり,12/31付けでPlamo64-1.0をリリースしたことを報告します。

図1 Plamo64-1.0のKDE環境

図1 Plamo64-1.0のKDE環境

思えば,新しいCore i7 CPUのマシンを組んで,その上で使うためにPlamo Linuxを64ビット環境へ移植し始めたのが一昨年の秋ごろだったので,64ビット化作業は丸一年以上かかったことになります。Plamo64の開発過程は本連載でも適宜紹介してきましたが,今回はまとめの意味を込めて開発過程を振り返ってみましょう。

開発の開始

Change.Logの記載を調べると,Plamo64についての記載が入り出したのは2010年(平成22年)の10月ごろでした。

この年の9月1日にPlamo-4.73を公開し,4.7系の開発作業が一段落したのに合わせて,新しいPCを組み立て,64ビット用の開発環境を構築し始めました。64ビット用の開発環境はクロスコンパイルの勉強のつもりで,CLFSの手順を参考に,

  • 32ビット環境(Plamo-4.73)上で64ビット用のバイナリを出力できるクロスコンパイル用ツールをビルド
  • それらのツールを使って64ビット用の開発環境をビルド
  • 64ビット用の開発環境を使って64ビットネイティブな環境をビルド

という手順で進めていきました。このあたりの詳細は本連載の16回目に取りあげています。

Change.Logによると,10月27日ごろから64ビット版の開発環境用のパッケージが登録されはじめ,11月の上旬ごろにはほぼ64ビット用パッケージのコンパイルに必要な環境が整ってきました。

ただし,この段階ではインストーラが64ビット版に未対応でした。そのため,インストール不要で動作するP-Plamoの手法を使って,Plamo-4.73上で64ビット用の開発ツールが動く32ビット/64ビット混在環境を作り,メンテナの人たちに公開して,開発作業を分担してもらえるようになりました。このあたりの詳細は本連載の17回目に紹介してみました。

P-Plamoの場合,インストール作業は不要なものの,メモリ上に作成したramdisk上で動作するので電源を落すと初期化されてしまいますし,カーネルや開発環境自体はDVDに書き込まれているため更新できません。

そのため,開発を本格化するためにはHDD上にインストールするためのインストーラが必須になるわけですが,インストーラはファイルシステムの作成や初期化,パッケージの展開,各種設定ファイルの作成など,さまざまな機能を持つ複雑なソフトウェアなので,ある程度開発を進めないと必要な機能が揃いそうにありません。

さてどうしたものか,としばし悩みましたが,x86-64 CPUの場合,64ビットのロングモードの中に32ビットのバイナリを動かす互換モードが存在するので,その機能を使えば既存の32ビット用のインストーラを流用できることに気づきました。そこで,インストーラでは,カーネルこそ64ビット用にするものの,ユーザ領域のライブラリやコマンド類は既存の32ビット用のバイナリを流用することにしました。こうすればカーネルを入れ替えるだけでx86用とx86-64用のインストーラを共有できるので,x86環境にもメリットがあるでしょう。

もっとも,拡張性やインストールする環境との互換性を高めるために,CライブラリをPlamo-4.73までで使っていたコンパクトなuClibcから,インストールする環境と同じglibcベースに変更したので,インストーラ用のコマンド類はすべて更新しています。

インストーラも何とかなり,メンテナの人たちからのパッケージも集まりだしたので,2011年(平成23年)1月上旬にはインストール可能な最初のDVDイメージ(Plamo64-0.1)を公開しました。

開発の長い道程

HDD上で起動できるようになれば,後はその環境上で必要なパッケージをビルドしていけばいいわけですが,Plamoは小規模なディストリビューションとはいえパッケージ数は1000を越えているので,パッケージを揃えていくにはメンテナの人たちの協力が必須です。

今回も初期の不安定なころから,メンテナの方々に献身的な協力をいただき,多数のパッケージを作成してもらいました。

複数人で作業を進める場合,分担をどうするかが問題になります。Plamoの場合,メンテナが少人数なこともあって,明確な分担分けはしておらず,そのソフトウェアを必要とする人が率先してパッケージを作ることになっています。そのため,Change.Logに記載されていくパッケージのリストを眺めていると,メンテナごとに重視する分野が違っているのが見てとれて面白かったりします。

開発が軌道に乗ってくると,ディストリビューションのとりまとめ役の仕事は,集まってきたパッケージを整理しつつ適当なタイミングでDVDイメージを更新していくことになります。その際,新しい試みとしてDVDイメージを作った日付を記録してみることにしました。

Plamo LinuxのDVDイメージはmkisofsコマンドで作成しています。mkisofsには,DVDからブートするための設定や不要なディレクトリを除外する指定など,オプションが多数存在し,それらを一々コマンドラインから打ち込むのは大変なので,必要なオプションを記載したシェルスクリプトを用意して,作成時にはそのスクリプトを使うようにしています。

今回は,そのシェルスクリプトにバージョン番号と日付けを書き出すような処理を追加して,開発過程でどれくらいDVDイメージを更新するかを記録してみました。その結果は以下のようになりました。

表1 Plamo64の開発ペース

バージョン番号日付
plamo64-0.12011-01-11
plamo64-0.22011-03-27
plamo64-0.32011-04-08
plamo64-0.42011-07-14
plamo64-0.52011-07-19
plamo64-0.62011-07-25
plamo64-0.72011-08-03
plamo64-0.82011-08-21
plamo64-0.92011-09-08
plamo64-0.102011-09-17
plamo64-0.112011-09-24
plamo64-0.122011-09-25
plamo64-0.132011-09-27
plamo64-0.142011-09-29
plamo64-0.152011-09-30
plamo64-0.162011-09-30
plamo64-0.172011-10-10
plamo64-0.182011-10-11
plamo64-0.192011-10-12
plamo64-0.202011-10-19
plamo64-0.212011-10-19
plamo64-0.222011-11-16
plamo64-0.232011-11-17
plamo64-0.242011-11-19
plamo64-0.252011-11-20
plamo64-0.262011-11-24
plamo64-0.272011-11-25
plamo64-0.282011-11-26
plamo64-0.292011-12-08
plamo64-0.302011-12-08
plamo64-0.312011-12-08
plamo64-0.322011-12-15
plamo64-RC12011-12-16
plamo64-RC22011-12-27
plamo64-1.02011-12-30

この表からPlamo64の開発リズムが見えてくるでしょう。

最初のバージョン(0.1)と0.2の間が1月半ほど空いているのは,新しい開発環境がメンテナの間に広まり,その上でパッケージができてくるのを待っていたためです。

0.2と0.3の間は10日間ほどなのに対し,0.3と0.4の間は3ヵ月以上空いてしまっています。この0.3と0.4の空白期間は,筆者が非常勤講師の方の仕事に時間を取られてしまって,Plamoの開発に時間を割けなかった時期にあたります。

空白期間の直前,0.3のころの状況は本連載の21回目に紹介しました。

その後,7月は0.4, 0.5, 0.6の3度,8月は0.7, 0.8の2度と比較的落ちついたペースで更新していますが,9月ごろからペースがあがり出し,9月には0.9から0.16までの7度,10月には0.17から0.21までの5度,11月には0.22から0.28までの7度と,2週に3度くらいのペースでDVDイメージをバージョンアップしています。

もっとも,これらバージョン全てを実機にインストールしたわけではありません。たいていのバージョンはVirtualBox上の仮想マシン用で,DVDイメージのまま仮想マシンにインストールし,問題が見つかれば修正して,バージョン番号を更新して再テストする,こういう作業を繰り返した結果,これだけバージョンの履歴が増えてしまったわけで,同じ日や連続した数日の間にバージョンがいくつも上っているのもそのためです。DVD-R等に焼いて,実機にインストールしたのはこの1/3ほど,FTPサイトでテスト用に公開したのは,さらにその半分くらいだったように思います。

Change.Logの記述を見ると,本連載の26回目にも紹介したように,8月ごろまでにはgrub2Btrfsなど,Plamo64で新しく採用した機能もほぼ動くようになってきました。一方,64ビット化を始めたころから一年近くが経ってしまったため,初期にビルドしたパッケージ類の中にはバージョンが古くなっているものも出てきました。

9月ごろからそれら古くなったパッケージの再ビルドサイクルが始まり,32ビット/64ビット両用になっていたパッケージを64ビット専用に再ビルドしたり,廃止されることになったHAL機能を使わないように再ビルドする作業が必要となりました。

特にHALに付いては,KDE-4.4.5が周辺機器の認識にHALを利用していたため,HALを廃止するためにはKDE-4.7にまで更新することが必要となり,Qtあたりからビルドし直すのに半月くらいかかった記憶があります。

HAL(Hardware Abstraction Layer)は,CD/DVDやUSBメモリ等の周辺機器の挿抜を監視するための仕組みとして提案され,2005年ごろからKDEやGNOMEで広く利用されていました。しかし,HALのデザインは,haldという1つのデーモンにあらゆる周辺機器を監視する機能を持たせるような作りになっていたため,複雑で拡張性に乏しく,次第にudevやudisksといった仕組みに取って代られることになりました。

著者プロフィール

こじまみつひろ

Plamo Linuxとりまとめ役。もともとは人類学的にハッカー文化を研究しようとしていたものの,いつの間にかミイラ取りがミイラになってOSSの世界にどっぷりと漬かってしまいました。最近は田舎に隠棲して半農半自営な生活をしながらソフトウェアと戯れています。

URLhttp://www.linet.gr.jp/~kojima/Plamo/index.html

コメント

コメントの記入