Linux日記: 1999年

新午後のこ〜だ（1999.11.13）

MP3が巷で話題にのぼるようになって久しく、メジャーなメーカーも携帯プレイヤーの販売を検討するような状況になってきました。 しかし、現在のところMP3ファイルを作成(エンコード)するにはパソコンが必要であり、エンコーダにも商用からフリーのものまで百花繚乱の状況です。

新午後のこ〜だは(補足3)MMX / 3DNow! / SSEに対応し、高速なエンコード速度がウリのエンコーダです。Windows / Linuxほか各種OSに対応してます。 午後のこ〜だはlameを元にしたもので、lameがまたISOのデモ・ソースを元にしていて、特許問題なんかも絡んでいて...、ややこしいね。 何はともあれその実力を実験してみました。

サンプル曲はB'zのFIRE BALL、曲の長さは4:12です。 なお、エンコードは44kHz / 128kbps / j-stereoの条件で行っています。

• lameの -f オプションは音質を犠牲にして高速にエンコードするオプション。
• gogoの -nopsy オプションは心理聴覚モデルの解析を省略して高速化するオプション(耳レベルだとあまり違いは分からないらしい)
• gogo自体はPentium IIIのSSEにも対応しているが、OSの対応が必要(Linuxカーネルにパッチを当てる必要がある

というわけで結果ですが、さすがに高速をウリにしているだけあって、エンコード速度はとんでもなく早いですね。 オリジナルのlameで-fオプションを使って音質を犠牲にし高速化した場合と、午後の標準状態がほぼ互角です。 また、MMXについてはそれほど効果はありませんが、K6-2では3DNow!の効果がかなり高いようです。 特に -nopsyオプションを使うとまさにぶっちぎり。 K6-2の336MHzがSSEなしのPIII-500MHzと大差ない結果となりました。

午後のこ〜だはPentium IIIのSSEにも対応しており、3DNow!以上に効果が高いらしいのですが、カーネルにパッチをあてる必要(補足1)があるのですが、うまくmakeできませんでした。
が、どうやらpgcc-2.95.2ではダメだったようでegcs-1.1.2でやり直したらうまくカーネルをmakeできましたのでテストを追加しました。 ウワサどおりSSEを使って-nopsyオプションでエンコードするととんでもない早さで、やっぱりK6-2/336では太刀打ちできませんでした(補足2)。

ところで、午後のこ〜だは wav → MP3の変換だけで、CDからwavを切り出す作業はやってくれません。 Linuxだとパイプを使って、別のCDリッパーから標準出力で持ってくればいいから別に問題にならないんですが、MS Winだと一度wavファイルを作らないとどうしようもないですね。

補足1 :

PIIIのSSE対応パッチはCygnusのこのページから入手可能

補足2 :

K6-IIIを購入したので504MHz(112x4.5)動作時のテストを追加しました。SSE有効のPIII-500と3DNow!有効のK6-IIIはほぼ互角ですね(ほんのわずかK6-IIIが上)。

補足3 :

午後のこ〜だのサイトはhttp://www.kurims.kyoto-u.ac.jp/~shigeo/soft.htmlからhttp://homepage1.nifty.com/herumi/soft.htmlに移行した模様です。

ついに公開されたSB Live!ドライバ（1999.11.6）

私の使用しているクリエイティブ・メディアのSound Blaster Live!では、従来Linux用のドライバがありませんでした。 ようやく99年7月にはβ版がバイナリのみ公開され、Creative配布のSB Live!ドライバ（1999.7.4）でもテストしました。 ただし、βドライバはバイナリのみなため、Linuxカーネルのバージョンが異なると動作しなくなってしまう場合があるという問題がありました。 また、Linuxのサウンド・ドライバの雄、ALSAでも「スペックシートを公開しないからドライバの開発ができん」とブラックリストに挙げられてしまうような状況でした。

私なんかは「オープンソースが時代の潮流なんだから、セコイこと言わないで公開しろ」と思い続けてきたのですが、11月になってようやくGPL準拠のドライバがリリースされました。 前述のALSAも11月中にLive!ドライバも取込むことを約束しましたし、ようやくLinuxでSB Live!を使う環境が整いつつあるようです。

ソースの入手

• 11月現在のバージョンは0.4です。Creative Open Source pageから、ソースファイル(emu10k1.tar.gz)を入手します。
• BIOS設定で、"PnP OS installed"オプションをNoに設定しておく
• インストールを行う前に、Linuxカーネルは下記の設定でコンパイルしておく必要があります。
  • With loadable modules support (CONFIG_MODULES = y)
  • Without SMP support (CONFIG_SMP = n)
  • With soundcard support as a module (CONFIG_SOUND = m)
  • Without any integrated soundcard drivers (CONFIG_SOUND_* = n)

make ＆ インストール

適当なディレクトリで、ソースファイルを展開し、makeします。

# tar xfz emu10k1.tar.gz
# make
# install emu10k1.o lib/modules/`uname -r`/misc
# depmod -a

後は、/etc/conf.modules に alias sound emu10k1と記述した行を追加しておくだけです。 パッケージ置場に適当ぶっこいたnosrcパッケージを置いといたので、参考にしてみてください。

これでようやくカーネルを思う存分アップデートできるようになりました。 2.2系カーネルの現在の最新は2.2.13なのに、Live!ドライバのせいで2.2.10にとどまってきましたからね。 後は、ALSAがサポートしてくれるのを待つのみです。

GLXで3Dアクセラレート（1999.10.30）

昨年12月に、Linuxでvoodooの回で、フリーのOpenGL環境Mesaと3dfx社の3Dアクセラレータ、Voodoo2を利用した3Dアクセラレートの実験を行いました。 Mesaは主にソフトウェア・レンダリングを用いたOpenGL環境ですが、VoodooシリーズのGlideにだけは対応しているので、3dfxからLinux用のGlideライブラリを入手すれば、ハードウェアによる3Dアクセラレーションが利用できたのです。

これに対して、今回実験したGLXは、XFree86用のモジュールとして提供されるもので、現在のところ、Matrox社のG200, G400チップ、NVidia社のRIVA TNTチップに対応し、OpenGL (Mesa)環境で3Dアクセラレートが可能になるようです。 GLXは将来的にはXFree86-4.0に統合されるみたいですね。

ソースの入手

• 現在のところ、GLXは開発中のスナップショット版しか存在していません。 GLXのサイトのDownloadページで、ソースを入手します。(glx-19991024.tar.bz2)
• GLXをmakeするには、Mesaのソースも必要です。実験したところ、GLXのスナップショットの日付と同じバージョンのCVS版の組み合わせがいいようです。 Mesaのサイトで、Download - Beta releasesを辿って入手しましょう。(MesaCVS.tar.gz)

ちなみに、今回のテストでは両ソースとも1999/10/24版を使いましたが、開発中のスナップショットですのでどんどんアップデートされていってます。

make ＆ インストール

configureに対応しているので、makeは簡単です。 まず、GLX、Mesaのソースを展開して、GLXを展開したディレクトリで、Mesaのソースを展開した場所を --with-mesaオプションで指定してconfigureし、make ＆ make installするだけです。

# cd (GLXを展開したディレクトリ)
# ./configure --with-mesa=(Mesaを展開したディレクトリ) --enable-extra
(configureがない場合は ./autogen.sh)
# make
# make install

標準の状態だと、XFree86用のGLXモジュールと、libGL.so、libGLU.soしか作成されません。 configureするときに、--enable-extra を指定すると、libglut.soもmakeされるので、Mesa自体をインストールしていない場合はこっちでいきましょう。 RIVA TNTチップの場合は--with-chipset=tntオプションを付ければいいようです(補足1)。

ちなみに、私はコンパイルにpgcc-2.95.1を使いましたが、-O3以上に最適化を強めるとセグフォ出まくりでダメダメでした。 パッケージ置場にnosrc.rpmを置いといたので、RPMの使える環境の方は参考にしてみてください(補足2)。

XFree86の設定

さらに、GLXを使う前に、XFree86にGLXモジュールを読込ませる必要があります。 /etc/X11/XF86Configに下の3行を追加します。

Section "Module"
Load "glx.so"
EndSection

startxする時にlogをとると、GLXモジュールの読込みに成功している場合、以下のようなメッセージが出ます。

(--) no ModulePath specified using default: /usr/X11R6/lib/modules
GLX extension module for XFree86 3.3.3.1 -- Mesa version 3.1
GLX package version 0.9, GLX protocol version 1.2.
(**) module glx.so successfully loaded from /usr/X11R6/lib/modules

というわけで実験

というわけで、インストール後、OpenGL対応アプリをビルドして実験してみると、ハードウェア・アクセラレートの威力が実感できます。 ちなみに私は、xscreensaverに含まれる gears、glplanet、atlantis等でテストしました。

以前にVoodoo2で実験した際は、なにせVoodooですからフルスクリーンじゃないとダメだったのですが、今回はウィンドウ表示でもバリバリとアクセラレートが効いてます。 この速さはまったく別次元ですね。 おぉ、すげぇ！ この喜びを皆さんに伝えたい！ ただ開発中のバージョンのせいか、ちょっと安定してないみたいです。 GLXはXFree86のモジュールなんで、死ぬときにXを道連れにしちゃうこともしばしばあるのが難点ですね(補足3)。

何はともあれこのスピードの違いを示すのに丁度いいOpenGLベンチマークはないですかねぇ。 やっぱりGLperfあたりでしょうか。 公開されているGLperfはLinuxに対応していないのですが、SuSE LinuxからLinux対応版のRPMパッケージが入手可能です。

補足1 :

nVIDIAのサイトでダウンロードできるLinuxドライバもGLXですね。nVIDIAのサイトでは、"Development Mesa/GLX module for 3D graphics support for RIVA 128, RIVA 128ZX, RIVA TNT, RIVA TNT2." と書いてあるので、このGLXもRIVA TNTだけでなくRIVA128等でもイケるかもしれません。

補足2 :

AGPを利用するには、カーネルが2.2系であれば別途AGPGARTパッチを当て(2.3以降であれば不要)、make xconfig してカーネルを作り直す必要があります。詳しくはGLXのサイトから落とした gart-SNAP-XXXXXXXX.tar.gz を参照のこと。

補足3 :

「不安定」というのは、AGPをX2モードにする(/etc/glx.conf でも危険だと警告されてます)とか、OpenGLクライアントを同時にいっぱい立ち上げるとか、無茶した場合のことです(^^;。

補足4 :

2000年6月、久々にglxをアップデートしてみたら、/etc/glx.confをいじってDMAを有効にし、クライアントのプログラムにsuidを立てればdirect renderingできるようになったみたい。これでXFree86-4.0にも負けないぜ。

HDBENCH clone（1999.10.2）

いつものようにfreshmeatをみていると、HDBENCH cloneなるソフトを発見しました。 「どこかで聞いたことのある名前じゃの〜」と思って確認してみると、やはりMS Win用のあのソフトと非常によく似ているものでした。 もちろん本家はバイナリだけしか配布されてませんから、ソース自体はオリジナルなものだと思われます。 Linuxだとこういうグラフィカルなベンチが少なかったし、頑張ってもらいたいですね。

作者のページからは、Redhat系およびDebian用のバイナリパッケージと、tarで固めたソースが入手できます。 私の環境ではglibc-2.0.7 + wscmbsではなくglibc-2.1のため、バイナリを入れようとすると文句を言われたので、ソースからコンパイルし直しました。

とりあえずベンチを取ってみたらこんなもんでした。 ちなみにハードの環境は両方ともメモリは128MB、VGAはMillenium G200です。 OSも両者ともTurbo Linux 4.0ベースで、XFree86-3.3.5、glibc-2.1.2等々のアップグレードをしてあります。 ちなみに自宅の方がカーネルバージョンが古いのはSB Live!のドライバが最新カーネルに未対応のせいです(^^;)。

* * *  HDBENCH clone Ver 0.13.1  * * *
Machine Infomation
Processor   AMD-K6(tm) 3D processor [335.977126 MHz]
            Vendor AuthenticAMD Family 5 Model 8 Stepping 0
Resolution  1280x1024 65536colors(16bit)
Display     nVidia Riva128:PCI
Memory      128380KBytes
OS          Linux 2.2.10
Date        1999/09/28 23:12

scsi0 : sym53c8xx - version 1.3c
SCSI device sda: hdwr sector= 512 bytes. Sectors= 8925000 [4357 MB] [4.4 GB]
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 8467200 [4134 MB] [4.1 GB]

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sdb2               544265     46681    469471   9% /
/dev/sda3               901787    660846    194353  77% /usr
/dev/sda5               313064    139216    173848  44% /mnt/swap
/dev/sda1              3142552   1167192   1975360  37% /mnt/win_c
/dev/sdb1              3663648   2422940   1240708  66% /mnt/win_d

 TOTAL FLOAT INTGR MEMRY  RECT CIRCL  TEXT  SCRL IMAGE  READ WRITE DRIVE
 13293 17474 47868  7825 19118 15826 16274    49    12  3697  4807 /tmp:10MB

* * *  HDBENCH clone Ver 0.13.1  * * *
Machine Infomation
Processor   Pentium III (Katmai) [501.142052 MHz]
            Vendor GenuineIntel Family 6 Model 7 Stepping 2
Resolution  1280x1024 65536colors(16bit)
Display     nVidia Riva128:PCI
Memory      128284KBytes
OS          Linux 2.2.12
Date        1999/09/28 12:41

scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.19/3.2.4
SCSI device sda: hdwr sector= 512 bytes. Sectors= 17985430 [8781 MB] [8.8 GB]

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda3              1476619    849674    550637  61% /
/dev/sda1              3142548   1192812   1949736  38% /c
/dev/sda5              3663640   2521232   1142408  69% /d
/dev/sda6               529060    151504    377556  29% /mnt/swap

 TOTAL FLOAT INTGR MEMRY  RECT CIRCL  TEXT  SCRL IMAGE  READ WRITE DRIVE
 23681 60760 67351 15817 29916 25198 26511    50    28  4527  6687 /tmp:10MB

試しにWindowsのHDBENCHと比較...はやめときました。 HDBENCHの最新リリースは2.61ですがスクロール計測等にバグがありますし、β版と比較するにしてもどのバージョンと比較するかが問題だし。 それにしても、何故にVGAがRIVA128と誤認識されてるのだろうか？

BIOSアップデートでようやく電源断 (99.8.28)

常々疑問だったのですが、MVP3チップセットでLinuxをお使いの皆さん、shutdownでちゃんと電源が落ちますかぁ？ 私は、AOpenのAX59Pro、EPoXのMVP3G-Mと2枚のMVP3マザーを使ってきたのですが、shutdownすると、画面に16進の数字がドバドバ出て電源が落ちないという状態が続いてきました。 ちゃんとWin98だと電源落ちるのにな〜、MVP3側の問題なのか、それともLinux側の問題なのか？ と悩んで、結局泣き寝入り状態でした。

ところが、現在私が使用しているEPoX MVP3G-MのBIOSが8/11付でアップデートされ、"Fixed Linux shutdown issue."の文字が。 早速試してみると、おお！ちゃんと電源が落ちるようになってるる〜。 うれしいですね。 ようやくLinuxもベンダー側が対応を考慮してくれるところにまでなってきたんですね。 でもこんなんBIOSアップで解決すんなら、もっと早くやってよ(^^;。

mpg123 / 3DNow!でもっと幸せになろう（1999.8.21）

私が愛用しているソフトの一つに、mpg123というコマンドラインのMP3プレイヤーがあります。 私が録りためたMP3ファイルは結構な数があるのですが、「今の気分は宇多田ヒカルだな〜」と思ったら、mpg123 -z Utada* な〜んてやればいいので、GUIでマウスを使って選択するより結局コンソールで操作するほうが便利だったりするんですよね〜。 で、最近のmpg123では3DNow!命令に対応していてとってもうれしいんですが、さらに音質・性能を向上させるパッチをきむらさんのページで見つけたので、早速実験してみる事にしました。

コンパイル自体はnosrc.rpmでパッケージングしてあるので説明しませんが、問題無くクリア。 さてさてどうやって効果を見ますかね〜。 mpg123のソースツリーにあるBENCHMARKINGをみると、top等でCPU占有率をみるよりもいい方法があるみたいです。

とするとCPUパワーをフルに使って最速デコードするテストモードがあるんですね。 そんなわけで早速ベンチ。 サンプル曲はB'zのFIREBALL(4:12, 96kbps/44.1kHz, 2959KB)です。

左側が再生に要した時間(userとsysを足したreal)、右側の％は元曲の長さ(4:12)に対する比率です。 おぉ、0.59rオリジナルの3DNow!版でもかなりの効果が出ますが、きむらさん版ではさらにパワーアップしてますね。 あと、浮動小数点版(非3DNow!)に比べるとオリジナル3DNow!版は音質が若干低下するのですが、きむらさん版は音質的にも浮動小数点版にひけをとらないそうです。 また、動作時に3DNow!対応CPUかどうかを自動判別する機能も追加されています。

私が愛用しているもう一つのMP3プレイヤー、gtk+を使ったGUIベースのxmmsもMP3読込みプラグインはmpg123をベースにしているようです。 ただし、xmms-0.9.1のlibmpg123では3DNow!ルーチンは組み込まれてません。 で、なんとかこれを3DNow!対応させようと四苦八苦してます。 CではHello Worldぐらいしか書けないし、IA-32のアセンブラも知らない私なので、悪戦苦闘してます(当たり前か)。 現在テスト中のxmmsのMP3読み込みプラグイン、libmpg123を3DNow!対応させるパッチ、およびRPMパッケージはパッケージ置場にあります。

Creative配布のSB Live!ドライバ（1999.7.4）

先日、ふとしたことでCreativeのデベロッパサイト(英語)から SB Live!のLinuxドライバが公開されているのに気がつきました。 最近ウォッチしてないうちにいつのまにか出てたんだ〜。 今までのLive!はといえば、ALSAでも「ベンダー側がスペックシートを公開しないからドライバ開発は不可能だ」とブラックリストにも載せられてしまうような絶望的な状態でした。

どうやら世の中の風がLinuxに向けて吹いてくる中、CreativeもLinuxドライバを配布することにしたようです。 良かった、良かった。 と思ったら残念ながら、現在公開されている0.2β版ドライバは2.0.36、2.2.5用のバイナリだけなんですね。 折をみてテストしたいところですが、Live!を搭載した2号機からはLinux消しちゃったんだよな...、どうすっかなぁ...。

ふと気がついたら2号機にLinuxがインストールされてました。 おぉ？！カーネルも何故か2.2.5になってる(最新は2.2.10なのに？)。 不思議なこともあるもんだ、まぁここまでお膳立てが出来ていればやるしかないよね。

配布ファイルには説明ファイル(README)、ドライバ(sblive.o-2.0.36, sblive.o-2.2.5)、インストールスクリプト(install_sblive)が含まれています。 インストールする前に、カーネルは非SMPで、かつ2.2.x系の場合サウンドコアをモジュールで組込んでおく必要があります。

インストールスクリプトを使っても良かったのですが簡単ですから手動でインストールしました。

# cp sblive.o-2.2.5 /lib/modules/2.2.5/misc/sblive.o

alias sound sblive
pre-install sblive insmod soundcore
post-remove sblive rmmod soundcore

後は、modprobe sbliveとやるか、サウンドを再生するコマンドを適当に使ってみればドライバが動的にロード・アンロードされるはずです。 試しにmpg123を使ってみたところ、見事にMP3が再生されました。 lsmodコマンドでみても確かにドライバがロードされているようです。

Module      Size  Used by
ppp             18316   0  (unused)
slhc             4360   0  [ppp]
nls_iso8859-1    2020   2  (autoclean)
nls_cp437        3548   2  (autoclean)
vfat            11484   2  (autoclean)
fat             25632   2  (autoclean) [vfat]
unix            10044   1  (autoclean)

Module           Size  Used by
sblive          55780   1  (autoclean)
soundcore        2372   5  [sblive]
ppp             18316   0  (unused)
slhc             4360   0  [ppp]
nls_iso8859-1    2020   2  (autoclean)
nls_cp437        3548   2  (autoclean)
vfat            11484   2  (autoclean)
fat             25632   2  (autoclean) [vfat]
unix            10044   1  (autoclean)

しかし、当然というかやはりというか、カーネルを現在の最新の2.2.10にするとこのドライバは動作しません。 う〜ん、何を気にしてるのかは判らないでもないけど、時代の流れだし、ドライバもソースレベルで公開した方がいいと思うけどなぁ。 そうすれば今ごろ誰かがパッチを出して2.2.10でも動作してると思うのだが。
TekramとかはSCSIドライバをちゃんとLinux用に昔から公開してるし、渋ってたnVIDIAもNeoMagicも公開したじゃないですか。 その方がユーザも広がるし、会社の評判も上がると思うし、クリエイティブもここは一つ頼むよ実際。

補足1 :

99年7月にドライバが0.3βに更新され、ドライバ名がsbliveからemu10k1に変更されるとともに最新カーネル2.2.10に対応しました。

補足2 :

Linux起動時にemu10k1ドライバでunresolved symbolエラーが出るのが気になる場合は、カーネル構築時に"set version information on all symbols for modules"オプションをオフにしてコンパイルし直せばメッセージは出なくなります。この場合、conf.modulesのpre-install、post-removeの2行は不要です。

補足3 :

99年11月、Creative Open Source pageからついにLive!ドライバのソースが公開されました！ALSAも11月中にLive!ドライバを出す予定だそうです。 ついに公開されたSB Live!ドライバ (1999.11.6)でも実験を行っています。

hdparmでお手軽パフォーマンスアップ（1999.3.27）

今回は、hdparm というIDEドライブの設定を変更するユーティリティで遊んでみました。 hdparm を使うと、PIO-4とかU-ATA等のモード変更、省電力モードに入るまでの経過時間等、いろいろな設定が可能ですが、良く考えずに危険な設定をしてしまうとハードディスクがクラッシュし貴重なデータが失われる可能性もあります。 くれぐれも自己責任で遊びましょう。

まず hdparm を入手してインストール。 私は hdparm-3.5.tar.gz を適当なところから探してきて、make、make installしました。 Turbo Linuxではhdparm-3.3が収録されているのでそれを使ってもいいでしょう。

等とすると表示されるドライブ情報や、dmesg で表示される起動時のログを参考にパラメータを適当に設定します。 結局、試行錯誤の末、32ビットI/Oを有効にし、設定可能範囲一杯までマルチセクタアクセスをONにするようにしてみました。 細かいパラメータについては興味があれば、各自で調べてください。

さて、こうして変更した効果を、ちょうど手元にあった bonnie というベンチマークソフトを使って、パラメータ変更の効果をみてみました。 bonnie はキャラクタ単位、ブロック単位でのシーケンシャル入出力、ランダムアクセスの速度とCPU占有率を計測するベンチマークソフトです。 ベンチマーク計測のファイルサイズは標準の100MBで、一応2回テストして大きな違いが無いことを確認した上で両者を平均した値を掲載します。 上段がベンチ結果、下段が標準状態と比べた変化率(あるいは変化幅)です。

ベンチ結果を見ると、「自作1号機」ではキャラクタ単位のシーケンシャル入出力で速度が大幅に向上しています。 また、使用しているWestern Digital社のAC31600では、DMA転送モード(1)よりもPIO転送モード(2)の方がやや早いようです。 PIO-4でもマルチワードDMA-2でも最大転送速度は16.7MB/secで同じはずなのですが、AC31600にはバグがあるみたいです。

参考までにシャープのPC-A445HというPentium 133MHzのノートPCでも実験してみましたが、 ブロック単位のシーケンシャル出力速度の大幅アップ、ブロック単位のシーケンシャル入力、ランダムアクセス時のCPU占有率の大幅減が目立った違いといえるでしょうか。 それにしてもPC-A445Hはハードディスクコントローラ自体が古くて、PIO-3ぐらいまでしか対応していないせいか、かなり遅いですねぇ。 それどころか、dmesg で確認してみるとLinux起動時に「UM8886BF Bus-Master DMA disabled (BIOS) dma_base is invalid (0x0000, BIOS problem)」と表示されています。 DMA転送もできないとは...。

自作1号機

• AMD K6-233MHz(225MHz), 96MB EDO
• Western Digital AC31600 (PIO-4) on Intel 82371SB(PIIX3)
• (1)hdparm -c3 -d1 -X34 -m16 -u1 -W1 /dev/hdb
• (2)hdparm -c3 -d1 -X12 -m16 -u1 -W1 /dev/hdb
• WDAC31600のバグのせいで、DMA転送モードでは遅くなるみたい

SHARP PC-A445H

• Intel Pentium P54C-133MHz, 32MB EDO
• IBM DTNA-22160 (mword2) on UM8886BF
• hdparm -c3 -m16 -u1 -W1 /dev/hda
• PC-A445HのBIOSバグのせいで、バスマスタ転送が利用できないみたい

RPMパッケージの作り方（1999.2.1）

様々なソフトをインストールしてきたけど、Linuxを再インストールした時や、別のマシンにLinuxを新たにインストールした時に、それらを一からmakeし直すのはかなり面倒な話になります。 しかし、RPM(Redhat Package Manager)を使えば結構簡単にパッケージ管理ができて、話が早くなります。

RPMにはソースパッケージ（foo.src.rpm）とアーキテクチャ別バイナリパッケージ(foo.i386.rpm、foo.alpha.rpm等）、アーキテクチャ非依存パッケージ（foo.noarch.rpm)等があり、ファイル名で判別できるようになっています。 そして、インストールしたバイナリパッケージはRPMがバージョンやにパッケージ間の依存関係も含めて管理してくれるのです。 例えば、「KDE-1.0のパッケージをインストールするには、QT-1.40以上が必要」としておくと、QTのバージョン1.40がインストールされていないのにKDE-1.0をインストールしようとするとエラーが出てインストールできません。
最初は、自分でfoo.tar.gz を入手してインストールしてるのにRPMに「パッケージが無い」と文句を言われたりして腹が立っていたのですが、依存関係を無視してインストールするオプションもあるし、自分で結構簡単にRPMパッケージを作れることが分かったので、最近はお手製パッケージを作るのが趣味になってきました。

RPMで使用するディレクトリ構成は以下の通りです。 パッケージを作成するには、rpm -bb foo.spec (バイナリパッケージだけ)、rpm -ba foo.spec (バイナリパッケージ、ソースパッケージ)とするだけ。 SPECファイルの書き方が分からなかったら、RedHatやPHTから 適当なソースパッケージ、foo.src.rpmを持ってきて、rpm -ivh foo.src.rpm とするとファイルが展開されるので、/usr/src/redhat/specs/foo.spec ファイルを参考にしてみましょう。 コツさえ掴めばそんなに難しいことはないと思います。

/usr/src/redhat/SOURCES

foo.tar.gz、foo.patch、等ソースファイルやパッチを置く

/usr/src/redhat/SPECS

パッケージの説明、コンパイル手順、インストールされるファイル、パッケージの依存関係等を 記述したfoo.specファイルを置く

/usr/src/redhat/SRPMS

rpm -baで作成されたソースパッケージが置かれる

/usr/src/redhat/RPMS/i386

rpm -bbやrpm -baで作成されたバイナリパッケージ(x86の場合)が置かれる。

参考までに、rpmコマンドで一般的に使われるオプションを書いてみました。 詳しくは付属ドキュメントや関連サイトを参照のこと。

ext2圧縮機能の追加（1999.1.15）

Transparent compression for the ext2 filesystem は、Linuxの標準ファイルシステムである、ext2ファイルシステムに圧縮機能を付加するものです。 Win9xのドライブスペース等と同様、圧縮されたファイルにもユーザーは従来と同様にアクセスできます。 さらに、ドライブスペースとは違って、ディレクトリやファイル毎に圧縮をかけられるので、非常に使い勝手がいいです。

カーネルソースにパッチをあてる

私が確認した時点では、カーネル2.1.132用のe2comprパッチ-0.4.28」が最新だったので、これを使いました。 2.2.0-pre6に適用すると、'arch/i386/defconfig', 'arch/ppc/defconfig', 'fs/Config.in'の３つがrejectされますが、この程度なら手パッチで頑張りましょう。

カーネルの再構築

パッチをあてたら、カーネルの再構築。 'Filesystems'のグループで、'Second extended fs support'の下に、'Ext2 file compression' が増えているので、これをチェック。 その他圧縮方法等のオプションがありますが、これはお好みで変更してください。
ただし、'Code maturity level options' で'Prompt for development and/or incomplete code/drivers' をチェックしておかないと、e2comprの項目は出現しないのでご注意を。

e2compr対応のe2fsprogsをインストール

カーネルをe2compr対応にしたら、e2fsprogsもe2compr対応のものに入替える必要があります。 圧縮属性を付加するchattr、圧縮属性などを確認するlsattr 等も含まれています。 Turbo Linux 3.0では、最初からe2compr対応のものがインストールされてたので、特にすることはありませんでした。

圧縮属性を設定

圧縮ファイルシステムはあくまでも非公式パッチで実現されているものです。システムファイルを圧縮してしまうのはチト怖いので、ドキュメントやmanファイルだけ圧縮することにしました。 使用頻度と圧縮率を天秤にかけて、ドキュメントはあまり参照しないからbzip2で、manは表示にあまり時間がかかりすぎるのも何ですからgzip -8で、等と圧縮モードを決めました。
# chattr +c -R -m bzip2 /usr/doc
# chattr +c -R -m bzip2 /usr/local/doc
# chattr +c -R -m gzip8 /usr/man
# chattr +c -R -m gzip8 /usr/local/man
# chattr +c -R -m gzip8 /usr/share

	Filesystem	1024-blocks	Used	Available	Capacity	Mounted on
使用前	/dev/sda3	746419	528299	179564	75％	/usr
使用後	/dev/sda3	746419	448634	259229	63％	/usr

VFAT日本語ファイル名対応パッチ（1999.1.15）

LinuxではWindowsパーティションをマウントして参照することができますが、日本語を含むファイル名の場合はうまく表示できません。 というのも、WindowsではShift JIS、LinuxではEUCと、OSによって標準として扱う日本語コードが異なるためです。

Linux Memo -- Hiroshi's HP （非常に情報量の豊富なサイトで、私も日ごろから勉強させてもらっています。 ぜひ一度訪れてみてはいかがかと）で、VFATの日本語ファイル名を表示できるようにするパッチ を見つけたので早速実験してみることにしました。

使い方は添付ドキュメントに書いてあるとおりで問題無くうまくいきました。

1. vfatjp-0.8.2c.tar.bz2 を解凍
2. カーネルソース（/usr/src/linux）に、カーネルのバージョン別パッチをあてる
3. カーネルソース（/usr/src/linux）に、各バージョン共通パッチをあてる
4. make menuconfig 等で'Japanese filename support' を有効にしてカーネルを再構築

私は現在、2.2.0-pre6を使用していますが、2.2.0-pre5用で問題無くいけました。 うまくいくとこんな感じになります（ちょっとJPEGの圧縮率を高めているので画質が悪いですがご容赦を）。

補足1 :

Linux Memo -- Hiroshi's HPは現在存在しません。 松嶋さんのWebページ等でメンテされてます。

一つ前のページに戻る / このページのTOPに戻る