シリーズ化をもくろんでいるのでその１などとつけてみました。
今回は/procファイルシステムの内、以下の文書でドキュメント化されていないものを
ほげりましょう。ってな趣向です。

第一回はauxvインターフェースです。
/proc/[pid]/auxv にて取得できます。auxvというのはプロセスをexecするときに
カーネルが生成プロセスに引き渡す情報のうちコマンド引数と環境変数に
おさまらない、補助的な（Auxiliary）情報ってことですわ。

選んだ理由はあんまりないんですが、ま、こっそりオモロイ情報でも
渡してたら、楽しい使い道が思いつくかな。と

と、いうのはタテマエで辞書順で先頭に表示されるファイルだからですな。
なんて適当。

---

んで、さっそくですがLinuxのカーネルの linux/fs/binfmt_elf.c あたりを
つらつらと・・・
うーん、#ifdef分かりにくいのー

とりあえず、

          －－－－－ 32bit
       ／    ｜
      ↓     ↓
  +------+-------+------+-------+------+-------+------+
  |  id  |  val  |  id  |  val  |  id  |  val  |   0  |
  +------+-------+------+-------+------+-------+------+

こんな感じで IDにAT_NULL(0)が現れるまで、32bitのIDとvalueが交互に現れることが
分かったのでなんちゃってリードプログラムで実際に読んでみる。
（30秒ハックになのでバグってても苦情はうけつけません）

ソース： http://mkosaki.web.fc2.com/read_auxv.c
↓ 結果 フォーマットは 名前： valの10進値（valの16進値）

$ ./read_auxv 3184
AT_HWCAP: 58979327(383f3ff)
AT_PAGESZ: 4096(1000)
AT_CLKTCK: 100(64)
AT_PHDR: 134512692(8048034)
AT_PHENT: 32(20)
AT_PHNUM: 7(7)
AT_BASE: 0(0)
AT_FLAGS: 0(0)
AT_ENTRY: 134546208(8050320)
AT_UID: 500(1f4)
AT_EUID: 500(1f4)
AT_GID: 500(1f4)
AT_EGID: 500(1f4)
AT_SECURE: 0(0)
AT_PLATFORM: -1074135045(bff9fffb)
AT_NULL: 0(0) 

あとは、このシンボルでカーネルソースｇｒｅｐして順に読んでくだけや。
で、結果

順番に解説すると

AT_HWCAP: プラットフォーム（というよりCPU)依存な値
          x86プラットフォームではcpuid命令の結果が格納されている
          bitの意味は http://www.sandpile.org/ia32/cpuid.htm の
          「standard level 0000_0001h」のEDXレジスタの項を参照のこと。
          AMD拡張が取得できないので3D NowもNX bitもx86_64対応も
          取得できず、今となっては片手落ちなこと
          cpuid命令は特権を必要としないので、こんなもん使わなくても
          ユーザーランドで苦もなく全情報とれることから
          あまり有用とは思えない
AT_PAGESZ: 読んで字の如し。メモリのページサイズが４ｋだと言っている
AT_CLKTCK: sysconf(_SC_CLK_TCK) で取得できる clock_t分解能
AT_PHDR, AT_PHENT, AT_PHNUM: 実行ファイルのELFヘッダの位置・サイズ、ランタイムリンカが使う
AT_BASE:  なんで０になってるんや？？
AT_FLAGS: Linuxでは常に0
AT_ENTRY: 実行ファイルのエントリポイント、ランタイムリンカが使う
AT_UID, AT_EUID, AT_GID, AT_EGID: 
	アクセス権。suid, fsuidが知りたかったら結局/proc読まんとならん。
	ちゅーとはんぱやのー
AT_SECURE: libcをセキュアモードで動かして欲しいときは１．
           伝統的な意味では (uid != euid) || (gid != egid) だが
           SELinuxなどのセキュリティーモジュールをインスコしたときは
           そちらの定義に従う。
           とはいっても、glibcの関数でこのセキュアモードを意識する関数は
           とーーーっても少ないので、普段あまり意識しない。
           推測だけど、たぶん、過去にセキュリティーホールがあった関数しかチェックしてないんじゃないのか？
AT_PLATFORM: プラットフォーム文字列（"i686"とか）へのポインタ

結論。
中途半端。過去の遺物。
だからイマドキの拡張はここの引数増やさずに/procにファイルが増えるのねん。となっとく。

少なくとも、よそのプロセスのauxv情報なんぞ読んでも
まるで役に立ちそうもありません orz
（せっかく解析したのに）



参考文献
－－－－
カーネル付属ドキュメントの和訳 http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.2/proc.txt.html
Red Hat Enterprise Linux 4 のマニュアルの/procの章: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ja/ref-guide/ch-proc.html
SUSEのマニュアル：http://www.novell.co.jp/pdf/linux/administration.pdf
－－－－

関連記事

• tmpfs は本当に容量が動的なのか (2006/02/18)
• /proc ファイルシステムの重箱の隅をつつく その１ (2006/02/15)
• SAMBAではまる (2006/02/14)