EDK 6.3 で CAN が使えるようになった。opb 経由でアクセスできる。ここまで来るのにえらく時間が掛かった、、、FPGA はコンフィギャブル（re-configable じゃ無いと思う。Spartan3 は動作中に変更できると聞いたが）なので、Linux のデバイスドライバつくりは大変。別の枠組みが必要そうだ。
例えば、Windows のドライバの PnP のようなもの。リソースを教えてくれるような仕組みが必要なんじゃなかろうか？ Linux にもあると思うけど（動的ローディングは出来るんだよね）でもなんとなく PnP じゃなくて、Probe ではないかと予測している（ソースは読んでない）。調査が必要。
2.4.X と 2.6.X で drivers の下を見たが、だいぶ替わっている模様。ダメソースがなくなった？気がする。2.4.X はまさにごった煮だったから。2.6.X ではカーネルレベルでのプリエンプティブが実現されたそうだから、それにあわせてちゃんとドライバも対応しないと、ジャイアント・ロックの一因になるそうだ。
今年に入って CPU のマルチコアの開発が急加速しているので、ジャイアント・ロックの解消は必須との事。その辺は、やっぱり Solaris に一日の長がある。きっと AIX も進んでいるだろう。SMP技術について、Linux が追いつくには、まだまだ時間が掛かるでしょう。特に、Sparc はチップ自身がタスクスイッチのコストが高い CPU なので、なるべくスイッチしないような細かいテクニックを使っているに違いない。例えば、Sparc のカーネル内では memcpy に FPU（とSparc では呼ばないかも）を使って高速化していた。当然、通常のカーネルでは FPU 命令を使うとエクセプションが発生するのだが、わざわざ、発生させないように細かいステータスレジスタ等の設定をやって memcpy を実現しているわけだ。芸が細かい。64 bit 化に至っては１０年前に Ultra Sparc とかがあったので、これも Solaris が選考している。でも、市場は Solaris を選ばない。SUN の人たちは「何故だ〜〜」という気分だろう。
マルチコアばやりだが、さて、組み込みの世界ではどうだろう？そもそも必要なのだろうか？eCos は対応しているようだ。（どのレベルまでかは不明）。レベルの高いものと、レベルの低いものが同時に動く可能性があるのだから、アプリケーションの開発レベルで注意しなければならなくなる。寧ろ、タスク（eCos ならスレッド）に小さな CPU を専用に割り当ててやる方がよさそう。SMP より、非対称の MP の方がよいと思う。
