At Thu, 11 Mar 2004 03:47:32 +0900, Yoshihiro Kawabe wrote: > Naoto> PC では ISA の I/O サイクルになりますが、ARM では memory mapped > Naoto> I/O デバイスに対するアクセスになる、などです。マクロのトリックを > Naoto> 駆使して実現しています。 > > そうですね。この手の書き方は悪くないと思います。 私は抽象化レイヤは見ためも抽象的な方が好みです。 > Naoto> 抽象化レイヤに抽象的な見てくれを与えるよりも、既存のデバドラを > Naoto> そのままマルチアーキテクチャ化する方を選んだ結果でしょう。 > > 元がバリバリPC(/AT)だったから、それはそれで自然な流れなんでしょうね。 私にはとても自然なこととは思えません。むしろ力業というか。 ただ、最近では i386 のアーキテクチャが一種の抽象プロセッサ アーキテクチャのように扱われだしたりしていますし(これも激しい 力業)、そういうやり方が時代の流れなのかなとは思います。 > Naoto> spl も同様です。splxx() は必ずその時の優先レベルより高い > Naoto> 優先レベルを指定しなくてはならないのですから、「優先レベルが > Naoto> 実行時でないと分からないような箇所では splxx() してはいけない」 > Naoto> ということになります。 > > そこら辺を素直に考えると結局は、前の状態を保持して割り込みを禁止にする > と言う操作と保存した状態を復元する操作の組みをカーネルの標準としておく > のが綺麗なんじゃないかと思いますね。 ことデバイスドライバに関するかぎり、割り込み禁止と状態復帰を対に してもさしたる効果はないと思っています。 クリティカルセクションを安全に実行することだけに注目すれば、 「本来割り込み許可で呼ばれるはずの関数が割り込み禁止で呼ばれて しまった状況(要するにバグ)」で割り込みを許可してクリティカル セクションを抜けるよりも禁止して抜ける方が、多分安全でしょう。 だから、割り込み禁止と状態復帰を対にするのはフェイルセーフに なり得ます。 しかし、デバイスを意図通りに制御するのがデバドラの仕事です。 デバドラにとって意図しない割り込み禁止状態を放置するのは 決して「フェイルセーフ」ではありません。むしろ、大半のケースで デバイスが機能しないでしょう。 つまりデバドラの場合は、いずれにしてもコードのどこで割り込みが 生じ得るのか厳密に管理してドライバを設計する必要があるわけです。 結果として割り込み禁止と状態復帰を対にしてもさして得るものは ないと言えます。 // 積極的に避ける理由もありませんけどね。 -- Naoto Shimazaki
Follow-Ups:
- [linux-users:102235] Re: 組込Linuxドライバの作成方法Yoshihiro Kawabe
- [linux-users:102185] Re: 組込Linuxドライバの作成方法Naoto Shimazaki
- [linux-users:102205] Re: 組込Linuxドライバの作成方法Yoshihiro Kawabe
- [linux-users:102223] Re: 組込Linuxドライバの作成方法Naoto Shimazaki
- [linux-users:102224] Re: 組込Linuxドライバの作成方法Yoshihiro Kawabe
- Prev by Subject: [linux-users:102233] Re: 2マウス同時使用
- Next by Subject: [linux-users:102235] Re: 組込Linuxドライバの作成方法
- Previous by thread: [linux-users:102224] Re: 組込Linuxドライバの作成方法
- Next by thread: [linux-users:102235] Re: 組込Linuxドライバの作成方法
- Indexes:[Main][Thread]