逆アセンブラを見なきゃいけない状況に何故かなってしまったので、
一先ず表示方法のメモです。
objdump –d --start-address=0xXXXXXXXX --stop-address=0xXXXXXXXX $(KERNEL_SOURCE)/vmlinux
panicになった時に、Oopsメッセージ以外情報がないというかわいそうな状況になったら、
逆アセンブラで共に頑張りましょう！
orz
9/17追記：
-g オプションを付けてコンパイルしたvmlinuxの場合は、
objdumpに –S オプションを付けると、対応するC言語のソースも一緒に表示されます。
アセンブラだけじゃチンプンカンプンなので、ありがたいオプションですね。
udev その２の続き・・・のようなもの。
仕事の合間を縫って調べてるのでスローペースなのですが、
まとめるには結構ややこしい機能なので、半分いいわけ（涙）になってます。
はてさて、最近気づいてしまったことがあります。
udev その１で起こった症状。
ethXの数字がどんどん増えていってしまう現象は、
udev-140で起こってる現象です。
対して私が落としてきたソースはudev-147でした。
とはいえ、大した差はないだろーと思って比較してみたら、
なーんとディレクトリツリーからして違うじゃないですか！
ということで、少し見直しますかねぇ。
Targetにudev-147を入れられないのがちょっと痛いなぁ。
# 諸処の理由により入れられないのです。
今までに分かったこと：
udevadm monitor で/sys/class/net/eth0とか見ても、
rename失敗は残っていても、rulesへの追加は残ってない。
mdioの数がPHYの数と合わない(+1)
rulesを見ると、eth0と同じMACアドレスが1回起動する度に
2個増えるのだけど、もしかして関係ある？？
とりあえず、ほとんど進んでいないので、”その2.5”デス。
YAFFS2（Yet Another Flash File System 2）は、主にNAND用に作られた、
Flash Memory用のファイルシステムです。
Flash用としてはきっとJFFS2（Journaling Flash File System 2）の方が有名でしょうし、
組み込みの開発してる方々はよく使用されてるんじゃないでしょうか。
YAFFS2の方が（unmountさえしていれば）mount時間が圧倒的に早いので、
Shutdownをきちんと何らかの方法で行えるのであればJFFS2よりも快適です。
そんな説明は、こーいう詳しいサイトにお任せするとして・・・
先日仕事中に気付いたのですが、このYAFFS2はなんと、
256byte以上の名前のファイルを作成してもエラーにならない！
のです。
それどころか255byte目の文字で途切れてしまって、
アクセスし辛いファイルが出来あがってしまいます。
ext2がそうだったような・・・・。
最近のファイルシステムは長すぎる名前でファイルを作成しようとすると、
ENAMETOOLONGというエラーを返すようになっています。
YAFFS公式サイトのリポジトリに入っているソースを確認しましたが、
対応していなさそうなので勝手に埋め込んでみました。
作成したpatch :
diff -ur yaffs2_org/yaffs_fs.c yaffs2/yaffs_fs.c
--- yaffs2_org/yaffs_fs.c 2009-05-26 10:22:44.000000000 +0900
+++ yaffs2/yaffs_fs.c 2009-09-14 10:38:27.000000000 +0900
@@ -448,6 +448,10 @@
yaffs_Object *obj;
struct inode *inode = NULL; /* NCB 2.5/2.6 needs NULL here */
+ if (dentry->d_name.len > YAFFS_MAX_NAME_LENGTH) {
+ return ERR_PTR(-ENAMETOOLONG);
+ }
+
yaffs_Device *dev = yaffs_InodeToObject(dir)->myDev;
yaffs_GrossLock(dev);
大したことはしてません。
ENAMETOOLONGを返すようにしただけです。
# Windows Live Writer の File Uploadプラグインを初めて使ってみたんですが、
# 投稿時に見事に跳ねられましたＴＴ
# ファイルサーバ用意するのも面倒だし、今回はそのまま貼り付け。
日本語でググっても引っかからないところをみると、
ものすんごくマイナーなのかな・・・ｗ
ファイル名の長さなんか誰か気付いてそうな気もするんだけどなぁ・・・。
はっ！？ 実は元々こーいう仕様でエラー返す方が間違い？
それはそれで気持ち悪いけど、まーいいかｗ
udev その１の続き。
増え続ける70-persistent-net.rules君を止める為に、
udevのソースを解析しています。
最初に犯人を探しに行くのは無謀な為、まずは末端から攻めます。
私が予想しているudevの動作は、
1.device検出時にdeviceとrulesの情報を比較
2.どれも一致しない場合は新規作成
3.最終的に一致したものにrename
renameしている部分さえ見つければ、上に追っていくだけで、
全て明らかになるはずです。
その場所はすぐに見つかりました。
info(event->udev, "renamed netif to '%s'\n", event->name);
こんな文があったので、間違いないでしょう。
udev_event.cのudev_event_execute_rules()の中で発見しました。
どうやらsysnameを取ってきて比較をし、不一致の場合は、
eventとして渡ってきた方のsysnameに上書きするようです。
sysnameってなんぞや？というのを追ってみると、
struct udev_deviceのメンバで、udev_device_new_from_subsystem_sysname()
で設定されてるようです。
/class/[subsystem]/[sysname]
の形っぽいので、きっと”eth0”とかが入ってるのでしょう。
あ・・・・あれ？
ってことは、比較してる時点で既にeth2とかeth3とか新しい名前が出来あがってるわけで、
新しいデバイス認識してrules更新してそうなところは全然別の場所？
・・・ってことになりますよね。
それに、/class/…の形って/sys下に出来るのやつですよね。
あれって各々ドライバで、class_create()で作ってるやつと記憶してますが、
どーやって動いてるのでしょうねぇ・・・。
sysfsの動きも完璧じゃないので少々混乱中です。
しょうがない、createと付くものを片っ端から洗い出して、犯人探ししますかねぇ。
足を使って捜査、古い刑事みたいだｗ
周りに詳しい人いないのがなぁ・・・。
>> その2.5
現行のプロジェクトで、ターゲットのブートローダにU-Bootを使用しているのですが、
UART部分の調整を行う際に、少し迷子になってしまったのです。
普段からUARTとは呼んでたけれどICの名前なんて覚えてなかったのがいけないのですね。
良い機会なのでメモっておきます。
UART (Universal Asynchronous Receiver Transmitter) は、
調歩同期式のシリアル通信を行う為の集積回路です。
一般的なPCで使う場合、RS-232C規格に変換するICと組み合わせて使用し、
Dサブ９ピンの端子で接続していますね。
UARTの中で代表的なものがNational Semiconductor Corporationの、
NS16550Aっていうやつです。
昔PC/ATで使用されていたもの（16450）との互換性を保つために、
基準発振周波数1.8432MHzな最大通信速度115.2kbpsが標準だそうです。
・・・Linuxのシリアルコンソールの標準が115200な理由はこれかｗ
U-BootのソースではUARTという名前ではなく、NS16550という名前になっていました。
確認は未だですが、Linuxのソースもそうなのかなぁ？
有名なICだけでも押さえておかないとマズイですね・・・・ｗ
むかーしむかしのコンピュータは、内部外部問わず新しい機器を接続する場合、
必ず電源を落として再立ち上げする必要がありました。
今はそんなことないですよね。
USBデバイスなんて、不意にグサっと差し込んでもちゃんと認識し動いてくれます。
電源を入れたまま、デバイスを接続することをhotplugと呼びますが、
Linux上ではhotplugの監視やデバイスの名前付けをudevと呼ばれているものが制御しています。
という話はLinuxユーザの中では常識かと思います。
大概は、/etc/udev/rules.d/に名前付けする際のルールが記述してあって、
それを変更することで好きなようにrenameできたり、permissionを変更したりできるはずです。
rulesに関しては、Writing udev rulesに詳しく載っていますし、
参考になるサイトはググれば沢山出てきます。
今回、udevに関して書こうと思ったのはudevの使い方云々ではなくて、
udevが意図してない動作をして少々困っているので、調査しようと思ったからです。
udevを解析してる人なんてあまりいなかったので、折角だし残しておこうと思った次第です。
現在困っているのは、Network Interface部分。
70-persistent-net.rulesにNICのMACアドレスが書いてあって、
それを元に'”eth0”のように名前付けを行っているはずの部分です。
rulesファイルに書かれているMACアドレスと、認識したNICのMACアドレスを比較して、
記述されているNICであれば、rules通りに名前付けし、
新しいNICを発見した場合は、write_net_rulesによって自動生成されるはずです。
・・・・はずです。
私の身に起きている困った現象は、
70-persistent-net.rulesの中身が再起動する度に増える！！
同じMACアドレスの情報が永遠に増え続ける！！
('A`)
さっそくudevのサイトへ飛んでソースを落としてきました。
お仕事と並行して、ゆっくりと調べることにします。
Network Interface部分のみじゃなくて、ちゃんとudevのことを理解しないと、
この問題は解決できなさそーなんで・・・がんばろう。
>> その２
ついこの間、Linuxをほとんど使ったことが無い知人に、
ISOイメージのmount方法を教えました。
「おおー、こんなことできるんだ」
と、驚いていましたが、こんな質問を返されたのです。
「ところで –o loop ってなーに？」
ハッハッハ、イメージファイルをmountする時に付けるオプションなのだよ！
とまぁ、合ってそうな感じの言葉で説明してみましたが、詳しくは知らなかったのです。
これはマズイと思って、調べておきました。
ループバックデバイスとは - Linuxキーワード:ITpro
一般的なファイルを，あたかもハード・ディスクなどのブロック型デバイスであるかのように
扱うための機能です。
パソコン上でイメージ・ファイルを直接操作したい場合などに使います。
「ループ・デバイス」とも呼ばれます。
こんなことも覚えてなかったんですねぇ、私（汗）
しっかりとした勉強していないで、経験だけ積み重ねていってるので、
基本的なところがかなーり抜けてるんだなぁと痛感しました。
