納品の時期ですっかりBlogのことを忘れてた。
というわけで久しぶりに更新。

Kernel2.6.20を今まで使っていて、今回2.6.21に変更したら
担当ドライバをinsmodしたときにNULLポインタにアクセスして
カーネルパニックを起こすようになっちゃった。
そんなわけで、コードの見直しを迫られたわけですが、
どうやら、request_irq近辺で落ちているらしい。
で、コンソールにデバッグ出力させたら、どうやらrequest_irqで
登録するhandlerがなぜか呼ばれていると。
このドライバでは、ユーザがinit処理を呼び出してから割り込みが
発生するという前提の下、作られていたわけで
insmod時に割り込みハンドラが呼ばれたせいでinit処理していない変数を
参照したためにNULLポインタアクセスエラーになったという落ちでした。

で、request_irqの何が変わったんだということを調べると

↓Open.

#ifdef CONFIG_DEBUG_SHIRQ
　if (irqflags & IRQF_SHARED) {
　/*
　* It's a shared IRQ -- the driver ought to be prepared for it
　* to happen immediately, so let's make sure....
　* We do this before actually registering it, to make sure that
　* a 'real' IRQ doesn't run in parallel with our fake
　*/
　if (irqflags & IRQF_DISABLED) {
　　unsigned long flags;
　　local_irq_save(flags);
　　handler(irq, dev_id);
　　local_irq_restore(flags);
　} else
　　handler(irq, dev_id);
　}
#endif

kernel/irq/manage.cでrequest_irq()やらfree_irq()が定義されているわけだけど
Kernel-2.6.21と2.6.20を見比べると、上のコードが追加されている。
んー、要するにSA_SHIRQ（上のコードだとIRQF_SHAREDだけど同値だから同じこと）を
request_irqのflagで指定していて、Kernelの.configでCONFIG_DEBUG_SHIRQを
有効にしていた場合、request_irq()を呼び出したら、内部で登録しようとしている
handlerを必ず呼び出すということらしい。
英語のコメントを適当に訳すと

ドライバは割り込みハンドラを起こさせる用意ができていなければならない。
だからカーネルは本物の割り込みが発生する前の登録する前にそのハンドラを実行しますよ。

とかいうことらしい。（合ってるか知らんけど）
そんなわけで、request_irq()で登録するhandlerは登録するときに
呼ばれるようになったということで、気をつけましょう。
ついでに、free_irq()でも同じようにhandlerを呼び出すようにしているんで
こちらも注意。
Close.↑

というわけで、その１では概念だけを説明したので
今回はセマフォの関数の覚書。

↓Open.

void sema_init(struct semaphore *sem, int val)
セマフォの初期化を行う。
引数１：セマフォ構造体。セマフォを識別するのに使う。
引数２：セマフォの初期化時点で持つ資源の数。

DECLARE_MUTEX(name)
DECLARE_MUTEX_LOCKED(name)
セマフォの生成、初期化を行うマクロ。
引数は生成するセマフォ構造体名。
ミューテックスとは相互排他（MUTual EXclusion）のことで、排他制御に使える。
要するに、DECLARE_MUTEXは初期資源として１つのセマフォ資源を持つセマフォを初期化する。
DECLARE_MUTEX_LOCKEDは名前のとおり、セマフォ資源を持たない、はじめからロックされた状態の
セマフォを生成、初期化する。

void init_MUTEX(struct semaphore *sem)
void init_MUTEX_LOCKED(struct semaphore *sem)
上記マクロとは生成、初期化を行ったが、こちらは初期化のみを行う。

void down(struct semaphore *sem)
引数１のセマフォ構造体から資源をひとつとる。
資源が0ならば、資源が取得できる（1になって、確保できるまで）待ち続ける。

int down_interruptible(struct semaphore *sem)
上のdownとほぼ同じ。
ちがうのは、待ちに入っている間に割り込みが入ることが出来る。
割り込みが発生すると、0以外の値を返し、待ちから復帰します。

int down_trylock(struct semaphore *sem)
待たないセマフォ。
確保するセマフォ資源がなかった場合は即座に0以外の値を返します。

void up(struct semaphore *sem)
確保しているセマフォ構造体のセマフォ資源を1つ返します。


例）

/* includeは省略 */

#define DRV_VERSION 1.0.0
#define LOCAL_VERSION 0.0.1

//cdevを定義。
struct cdev hoge_cdev;
//セマフォを定義
struct semaphore hoge_sem;

static int hoge_read_proc( char* page, char** start, off_t offset,
　　　　　　　　　　　　　　　　　　　int count, int* eof, void* data )
{
int len = 0;

　　　　/* セマフォで排他処理開始（セマフォ確保） */
if ( down_interruptible( &hoge_sem ) ) {
printk("down_interruptible error\n" );
return -ERESTARTSYS;
}

len += sprintf(page + len, "hoge Driver Version : %s - %s \n", DRV_VERSION , LOCAL_VERSION);
len += sprintf(page + len, "hoge Driver Compiled : "__DATE__" "__TIME__"\n");

　　　　/* セマフォで排他処理終了（セマフォ解放） */
up( &hoge_sem );
return len;
}
int hoge_open(struct inode *inode, struct file *filp)
{
　　//なんかopen処理
}
int hoge_close(struct inode *inode, struct file *filp)
{
　　//なんかrelease処理
}
static long tuner_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
　　//なんかioctl処理
}

//ファイルオペレーション構造体
//このサンプルドライバを使ってopenとかcloseとかioctlを呼び出すと
//hoge_openやらhoge_closeやらhoge_ioctlが呼び出される。
static struct file_operations fops =
{
　　.owner = THIS_MODULE,
　　.unlocked_ioctl = hoge_ioctl,
　　.open = hoge_open,
　　.release = hoge_close,

};

static int __init hoge_init(void)
{

　　//適当。
　　int hoge_major = 202, hoge_minor = 0;
　　dev_t hoge_dev_t;
　　struct proc_dir_entry *hoge_entry = 0;

　　//セマフォの初期化（ミューテックス）
　　init_MUTEX(&hoge_sem);

　　/* procファイルのエントリ作成 */
　　hoge_entry = create_proc_read_entry("driver/hogeinfo", 0, NULL, hoge_read_proc, NULL);
　　if(hoge_entry == NULL) return -1;

#if 1
　　/* 自分で指定したメジャー番号を使いたいときはこっち */
　　/* MKDEV(メジャー番号, マイナー番号)ってマクロでdev_t生成*/
　　hoge_dev_t = MKDEV(hoge_major, hoge_minor)
　　register_chrdev_region(hoge_dev_t, 1, "hoge")
#else
　　/* 空いているメジャー番号を動的に取得したいときはこっち */
　　alloc_chrdev_region(&hoge_dev_t, hoge_minor, 1, "hoge");
#endif
　　cdev_init(&hoge_cdev, &hoge_fops);
　　hoge_cdev.owner = THIS_MODULE;

　　ret = cdev_add(&hoge_cdev, , 1);
　　if(ret < 0){
　　　　remove_proc_entry("driver/hogeinfo", NULL);
　　　　return -1;
　　}
　　return 0;
}

static void __exit hoge_exit(void)
{
　　remove_proc_entry("driver/hogeinfo", NULL);
　　cdev_del(&hoge_cdev);
　　unregister_chrdev_region(hoge_dev_t, 1);
}

module_init(hoge_init);
module_exit(hoge_exit);

/procファイルを使うのコードの使いまわし。
procファイルの出力に排他処理をかけてます。
Close.↑

/procファイルを使うででてきたセマフォについてめもっておいてみる。
まずはセマフォの簡単な概念から。
簡単に言えばある処理を、一定の数以上の同時処理を防ぐということ。

↓Open.

　　　　（セマフォ資源：○○○○○）
→（セマフォ確保）→処理A→（セマフォ解放）→

こんな処理があったとして、プロセス１が処理Aに入ると

---

　　　　（セマフォ資源：●○○○○）
→（セマフォ確保）→処理A→（セマフォ解放）→
　　　　　　　　　　○プロセス１（処理中）

こんな感じ。
プロセス１は（セマフォ確保）でセマフォ資源○をもらって、処理Aを開始します。
で、ここにさらにプロセス２〜５が入ります。

---

　　　　（セマフォ資源：●●●●●）
→（セマフォ確保）→処理A→（セマフォ解放）→
　　　　　　　　　　○プロセス１（処理中）
　　　　　　　　　　○プロセス２（処理中）
　　　　　　　　　　○プロセス３（処理中）
　　　　　　　　　　○プロセス４（処理中）
　　　　　　　　　　○プロセス５（処理中）

こんな感じになる。
で、ここにさらにプロセス６がくると・・・

---

　　　　（セマフォ資源：●●●●●）
→（セマフォ確保）→処理A→（セマフォ解放）→
・プロセス６（待ち）○プロセス１（処理中）
　　　　　　　　　　○プロセス２（処理中）
　　　　　　　　　　○プロセス３（処理中）
　　　　　　　　　　○プロセス４（処理中）
　　　　　　　　　　○プロセス５（処理中）

プロセス６はセマフォを確保しようとしたけど、セマフォ資源が空っぽなので
待ちに入ります。ここにプロセス７がくると・・・

---

　　　　（セマフォ資源：●●●●●）
→（セマフォ確保）→処理A→（セマフォ解放）→
・プロセス６（待ち）○プロセス１（処理中）
・プロセス７（待ち）○プロセス２（処理中）
　　　　　　　　　　○プロセス３（処理中）
　　　　　　　　　　○プロセス４（処理中）
　　　　　　　　　　○プロセス５（処理中）

こうなります。
さて、プロセス１が処理Aを終えると、（セマフォ解放）にいきます。

---

　　　　（セマフォ資源：●●●●○）
→（セマフォ確保）→処理A→（セマフォ解放）→
・プロセス６（待ち）○プロセス２（処理中）・プロセス１（終了）
・プロセス７（待ち）○プロセス３（処理中）
　　　　　　　　　　○プロセス４（処理中）
　　　　　　　　　　○プロセス５（処理中）

こうなります。
セマフォが解放されたので、プロセス６が確保できます。

---

　　　　（セマフォ資源：●●●●●）
→（セマフォ確保）→処理A→（セマフォ解放）→
・プロセス７（待ち）○プロセス２（処理中）・プロセス１（終了）
　　　　　　　　　　○プロセス３（処理中）
　　　　　　　　　　○プロセス４（処理中）
　　　　　　　　　　○プロセス５（処理中）
　　　　　　　　　　○プロセス６（処理中）

こうなるわけです。
もちろん、この後はプロセス２も処理が終わって、セマフォを解放して
プロセス７がセマフォを確保して、処理Aに入ると。
以上、セマフォの説明でした。
Close.↑

デバイス番号の割り当て（静的）
int register_chrdev_region(dev_t first, unsigned int count, char *name)
引数１登録するdev_t。メジャー番号とマイナー番号を持っている。
引数２登録する数。
引数３登録するデバイス名

デバイス番号の割り当て（動的）
int alloc_chrdev_region(dev_t *dev, unsigned int firstminor, unsigned int count, char *name)
静的とほとんど同じ。
引数１に渡したアドレスに動的に割り当てられるdev_tが入れられる。
firstminorははじめのマイナー番号。

デバイス番号の解放
void unregister_chrdev_region(dev_t first, unsigned int count)
引数１は割り当てたdev_tを渡す。
引数２は解放する数。

cdev初期化
void cdev_init(struct cdev * cdev, struct file_operations *fops)
引数１はcdev。キャラクタ型デバイスを表す構造体。
引数２はファイルオペレーション構造体。ドライバを用いて呼び出す処理を割り当てる。

cdev登録
int cdev_add(struct cdev *cdev, dev_t num, unsigned int count)
引数１はcdev。上で初期化したやつを入れてやればいい。
引数２はdev_t。デバイスのメジャー番号とマイナー番号を格納しているらしい。
引数３はデバイス番号の数。

cdev削除
void cdev_del(struct cdev *cdev)
引数１はcdev。上で登録したやつを入れればいい。

↓Open.

例）
/* includeは省略 */

int hoge_open(struct inode *inode, struct file *filp)
{
　　//なんかopen処理
}
int hoge_close(struct inode *inode, struct file *filp)
{
　　//なんかrelease処理
}
static long tuner_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
　　//なんかioctl処理
}

//ファイルオペレーション構造体
//このサンプルドライバを使ってopenとかcloseとかioctlを呼び出すと
//hoge_openやらhoge_closeやらhoge_ioctlが呼び出される。
static struct file_operations fops =
{
　　.owner = THIS_MODULE,
　　.unlocked_ioctl = hoge_ioctl,
　　.open = hoge_open,
　　.release = hoge_close,

};

//cdevを定義。
struct cdev hoge_cdev;

static int __init hoge_init(void)
{

　　//適当。
　　int hoge_major = 202, hoge_minor = 0;
　　dev_t hoge_dev_t;

#if 1
　　/* 自分で指定したメジャー番号を使いたいときはこっち */
　　/* MKDEV(メジャー番号, マイナー番号)ってマクロでdev_t生成*/
　　hoge_dev_t = MKDEV(hoge_major, hoge_minor)
　　register_chrdev_region(hoge_dev_t, 1, "hoge")
#else
　　/* 空いているメジャー番号を動的に取得したいときはこっち */
　　alloc_chrdev_region(&hoge_dev_t, hoge_minor, 1, "hoge");
#endif
　　cdev_init(&hoge_cdev, &hoge_fops);
　　hoge_cdev.owner = THIS_MODULE;

　　ret = cdev_add(&hoge_cdev, , 1);
　　if(ret < 0){
　　　　goto err_case;
　　}
　　return 0;
}

static void __exit hoge_exit(void)
{
　　cdev_del(&hoge_cdev);
　　unregister_chrdev_region(hoge_dev_t, 1);
}

module_init(hoge_init);
module_exit(hoge_exit);
Close.↑

デバイスドライバについて復習してみる。
というわけで、まずはinit_moduleとcleanup_moduleから。

↓Open.

デバイスドライバをカーネルにロードした時に
実行されるのがinit_module。
static int init_module(void)

自分で関数名を指定したければ
static init hoge_init(void)
{
　　//ドライバの初期化処理
}
module_init(hoge_init);
としてやればよい。

デバイスドライバをカーネルからアンロードした時に
実行されるのがcleanup_module。
static void cleanup_module(void)

自分で関数名を指定したければ
static void hoge_exit(void){
　　//ドライバクリーンアップ処理
}
module_exit(hoge_exit);
としてやればよい。

例）
#include＜linux/init.h＞
#include＜linux/module.h＞

static int __init hoge_init(void)
{
　　//なんか処理
}
static void __exit hoge_exit(void)
{
　　//なんか処理
}
module_init(hoge_init);
module_exit(hoge_exit);

これでモジュールのロード時にhoge_initが
アンロード時にhoge_exitが実行される。
__initはこの関数はモジュールの初期化のときにだけ
使われるよって宣言。
__exitもこの関数はモジュールのクリーンアップ処理の時にだけ
使われるよって宣言。
これらを宣言することによって、初期化が終了した時に__initで
修飾された関数はメモリから削除され、__exitで修飾された
関数はクリーンアップ処理（モジュールの削除、シャットダウン）
の時だけメモリに登録されるので、それ以外で使用する場合は宣言しちゃだめ。
（init_moduleで初期化失敗した時に、cleanup_moduleを呼び出して
初期化処理で確保したりソースを解放する場合なんかは、
__exit宣言しちゃだめよってこと）
初期化処理の時にだけ使うデータ宣言の__initdataとか
クリーンアップ処理の時にだけ使うデータ宣言の__exitdataとかもあるとか。
Close.↑