コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2015年10月10日 >>> 2015年10月10日
link もっと後

2015年10月10日

Linuxデバイスドライバを組み込んだときの初期化順序

目次: Linux

Linux用のデバイスドライバを書くときはmodule_init(関数名) と書いて、初期化関数を指定します。

ドライバをカーネルモジュール(*.ko)としてビルドしたときは、insmodした時に初期化関数が実行されます。これは想像に難くないですし、初期化関数にprintkでも入れておけば簡単に確認できます。

では…、ドライバをLinuxカーネルに組み込んだ時は、一体いつ初期化処理が実行されるのでしょうか?Linuxには他のドライバも含まれていますが、実行される順序に決まりはあるでしょうか?

わたくし恥ずかしながら、この辺の仕組みを全く理解していなかったので、コードを調べてみました。既に同じような事を調べている人がいる気がしてなりませんが…まあ良いや。

Linuxの初期化関数

Linuxの初期化は、linux/init/main.cのstart_kernel() から始まります。start_kernel() は山のように初期化を実行していますが、我らがmodule_init() の実行に関係しているのは下記の部分です。

Linuxのエントリ関数から、ドライバの初期化関数まで、その1

start_kernel()
  rest_init()
    kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);

ここでカーネルスレッドが作成され、スレッドのエントリ関数はkernel_init() です。で、続けて追いかけます。

Linuxのエントリ関数から、ドライバの初期化関数まで、その2

kernel_init()
  kernel_init_freeable()
    do_basic_setup()
      do_initcalls()
        do_initcall_level()
          do_one_initcall()
            initcall_levels[level][n]()

このような順で呼ばれます。このinitcall_levelsが今回の話のキモとなります。initcall_levelsは下記のように定義されています。

ドライバの初期化関数群

typedef int (*initcall_t)(void);

extern initcall_t __initcall_start[];
extern initcall_t __initcall0_start[];
extern initcall_t __initcall1_start[];
extern initcall_t __initcall2_start[];
extern initcall_t __initcall3_start[];
extern initcall_t __initcall4_start[];
extern initcall_t __initcall5_start[];
extern initcall_t __initcall6_start[];
extern initcall_t __initcall7_start[];
extern initcall_t __initcall_end[];

static initcall_t *initcall_levels[] __initdata = {
        __initcall0_start,
        __initcall1_start,
        __initcall2_start,
        __initcall3_start,
        __initcall4_start,
        __initcall5_start,
        __initcall6_start,
        __initcall7_start,
        __initcall_end,
};

コードを見る限り、二重配列 __initcall_levelsは __initcalln_startという配列を要素として持っていること、__initcall0_start[0], __initcall0_start[1], __initcall0_start[2], ... の順に関数ポインタが先に呼び出され、その後も同様に __initcall1_start, __initcall2_start, ... と続いて __initcall7_startに入っている関数ポインタは後に呼び出されることがわかります。

しかし肝心の __initcall0_startに何の関数ポインタが入るのか?はわかりません。それもそのはず、実はCのコード上に、これら __initcallx_start配列の定義はありません。別の方法で定義されているのです。

この __initcall0_start〜 __initcall7_start配列は、あるマクロで宣言された初期化関数のポインタを全て持つ配列となります。対応関係は下記の通りです。

  • __initcall0_start: pure_initcall()
  • __initcall1_start: core_initcall()
  • __initcall2_start: postcore_initcall()
  • __initcall3_start: arch_initcall()
  • __initcall4_start: subsys_initcall()
  • __initcall5_start: fs_initcall()
  • __initcall6_start: device_initcall()
  • __initcall7_start: late_initcall()

なぜそうなるか?は後述しますので、とりあえずこんな関係があることだけ頭の隅に置いてください。

おまじないmodule_init() の正体

カーネルモジュールを作るとき、初期化関数を指定するためのおまじないとしてmodule_init(funcname) と書きますが、これは実はマクロでlinux/include/linux/module.hにて、下記のように定義されています。

module_init() マクロの定義

/**
 * module_init() - driver initialization entry point
 * @x: function to be run at kernel boot time or module insertion
 *
 * module_init() will either be called during do_initcalls() (if
 * builtin) or at module insertion time (if a module).  There can only
 * be one per module.
 */
#define module_init(x)  __initcall(x);

#define __initcall(fn) device_initcall(fn)

#define device_initcall(fn)             __define_initcall(fn, 6)

マクロの定義はmodule_init = __initcall = device_initcallとなっていますので、module_init(funcname) はdevice_initcall(funcname) と書くのと同じです。

最後にmodule_init(funcname) は __define_init(funcname, 6) と定義されています。これもマクロでlinux/include/linux/init.hに下記のように定義されています。

__define_init() マクロの定義

#define __define_initcall(fn, id) \r        static initcall_t __initcall_##fn##id __used \
        __attribute__((__section__(".initcall" #id ".init"))) = fn

何だか小難しいですが、簡単に言うとmodule_init(funcname) つまり __define_initcall(funcname, 6) と書いたら、初期化関数funcnameのポインタを値に持つ __initcall_funcname6という名前の変数を宣言し、セクション .initcall6.initに置け、という意味になります。

その変な名前の変数がどこに置かれるのか?は、リンカスクリプトlinux/arch/arm/kernel/vmlinux.ldsに書いてあります。全部は載せられませんので .initcall6.initセクションに言及しているところを見てみます。

リンカスクリプトと __initcall_funcname6の行き先

 .init.data : {
    *(.init.data) *(.meminit.data) *(.init.rodata) *(.meminit.rodata) . = ALIGN(8);
    __clk_of_table = .;
    *(__clk_of_table) *(__clk_of_table_end) . = ALIGN(32);
    __dtb_start = .;
    *(.dtb.init.rodata) __dtb_end = .;
    . = ALIGN(16);
    __setup_start = .;
    *(.init.setup) __setup_end = .;
    __initcall_start = .;
    *(.initcallearly.init) __initcall0_start = .;
    *(.initcall0.init) *(.initcall0s.init) __initcall1_start = .;
    *(.initcall1.init) *(.initcall1s.init) __initcall2_start = .;
    *(.initcall2.init) *(.initcall2s.init) __initcall3_start = .;
    *(.initcall3.init) *(.initcall3s.init) __initcall4_start = .;
    *(.initcall4.init) *(.initcall4s.init) __initcall5_start = .;
    *(.initcall5.init) *(.initcall5s.init) __initcallrootfs_start = .;
    *(.initcallrootfs.init) *(.initcallrootfss.init) __initcall6_start = .;
    *(.initcall6.init) *(.initcall6s.init) __initcall7_start = .; ★★これ★★
    *(.initcall7.init) *(.initcall7s.init) __initcall_end = .;
    __con_initcall_start = .;
    *(.con_initcall.init) __con_initcall_end = .;
    __security_initcall_start = .;
    security_initcall.init) __security_initcall_end = .;
    ...

※本来は改行が入っていませんが、見やすいように適宜改行を入れています。

私はリンカスクリプトに明るくないので、間違っていたらごめんなさいですが、基本的には書いた順でシンボル(変数や関数など)をオブジェクトファイル内に並べてくれる、という理解でこの辺りは大丈夫なはずです。

先ほどの __define_initcall() マクロの定義から __initcall_funcname6変数は、コンパイラが .initcall6.initというセクションに入れて、オブジェクトファイルを生成します。わかりにくいと思うので、例で説明します。

例えば、リンカが今までシンボルを並べてきた結果、現在のアドレスが0x10000になっていたとします。あと .initcall6.initセクションには __initcall_funcname6と __initcall_func2name6の2つのシンボルが含まれているとします。

リンカはまず「__initcall6_start = .;」を見て、現在のアドレス(ドットは現在のアドレスを表す)に0x10000: __initcall6_startを定義します。現在のアドレスは変わりません。

次に「*(.initcall6.init)」を見て、全オブジェクトファイルの .initcall6.initのシンボルを順番に並べ、現在のアドレスを進めます。つまり0x10000: __initcall_funcname6, 0x10004: __initcall_func2name6が並び、現在のアドレスは0x10008になります。「*(.initcall6s.init)」も同様ですが、何もシンボルが入っていないのでスルーします。

最後に「__initcall7_start = .;」を見て、0x10008: __initcall7_startを定義します。

すなわち下記のようなアドレス、シンボルの関係になります。

- Linuxカーネル
  - セクションA
  - セクションB
  - セクション .init.data
      - ...
      - 0x10000: __initcall6_start
      - .initcall6.init内の全シンボル
        (内訳)
        - 0x10000: __initcall_funcname6  = funcname() のポインタ
        - 0x10004: __initcall_func2name6 = func2name() のポインタ
      - 0x10008: .initcall6s.init内の全シンボル
      - __initcall7_start
      - .initcall7.init内の全シンボル
      - ...
  - セクションD
  ...

ここで、序盤の謎であった __initcall6_startの謎が解けます。思い出してほしいのですが、変数 __initcall_xxxx6はdevice_initcall(xxxx, 6) で指定した関数xxxxのポインタを値として持っていました。

リンカスクリプトによって、変数 __initcall_xxxx6の一群を __initcall_funcname6から「連続したアドレスに配置する」ので、C言語から見たときには、__initcall6_startはあたかも関数ポインタの値を持った配列に見えるわけです。

__initcall6_startが持っている値のイメージ

static initcall_t __initcall_funcname6 = funcname;
static initcall_t __initcall_func2name6 = func2name;

initcall_t __initcall6_start[] = {
        __initcall_funcname6, 
        __initcall_func2name6, 
        ..., 
};

ただし、C言語ではこのような書き方はできないし、仮に書けたとしても、

&__initcall6_start[0] == &__initcall_funcname6
&__initcall6_start[1] == &__initcall_func2name6

が成り立たないので、厳密に同じことはできません。

この仕組みはC言語だけでは記述するのは恐らく不可能で、リンカとの連携の賜物と言えるでしょう。

ビルドしたバイナリを見る

論より証拠でLinuxカーネルをビルドして、生成されたvmlinuxをreadelfで調べましょう。

実験に使うカーネルは3.14.44でARM Versatile PBボード向けコンフィグでビルドしたものです。拙作のARM9エミュレータememu(emuemuについてはこちら)の動作確認用に実際に動作させていたバイナリです。

まずは -Sオプションでセクションの一覧を見ます。

$ arm-linux-gnueabihf-readelf -S vmlinux

セクションヘッダ:
  [番] 名前              タイプ          アドレスOff    サイズES Flg Lk Inf Al
  ...
  [21] .init.pv_table    PROGBITS        c039b818 3a3818 0005cc 00   A  0   0  1
  [22] .init.data        PROGBITS        c039bde8 3a3de8 003f6c 00  WA  0   0  8
  [23] .data             PROGBITS        c03a0000 3a8000 027380 00  WA  0   0 32
  ...

アドレスc039bde8からc039ffffまで、サイズ3f6c分のセクション .init.dataが居ることがわかります。vmlinuxをバイナリエディタなどで見る場合はOffの位置、つまり3a3de8を見ると .init.dataのバイナリデータが見られます。

Linuxはビルドしたときに全シンボルのアドレスと、シンボル名の対応表を作成してくれます。アドレスとシンボル名の対応はSystem.mapというファイルに出力されます。

$ grep initcall6 System.map
c039fb08 T __initcall6_start

$ grep initcall7 System.map
c039fc94 T __initcall7_start
c039fcb4 t __initcall_deferred_probe_initcall7

System.mapを見てもわかるように、__initcallx_startの軍団は .init.dataセクションの範囲内に全員収まっていることがわかります。

初期化順序

残りの疑問であるinitcall6内の呼び出し順はどうなるか?については、コンパイルされた順番になるようです。

System.mapの __initcall6_start付近を見ると、

c039fb08 T __initcall6_start
★★★arch/arm/ 以下
c039fb08 t __initcall_fpe_init6

★★★kernel/ 以下
c039fb0c t __initcall_proc_execdomains_init6
c039fb10 t __initcall_ioresources_init6
...
c039fb50 t __initcall_pid_namespaces_init6
c039fb54 t __initcall_utsname_sysctl_init6

★★★mm/ 以下
c039fb58 t __initcall_init_per_zone_wmark_min6
c039fb5c t __initcall_kswapd_init6
...
c039fb70 t __initcall_slab_proc_init6
c039fb74 t __initcall_cpucache_init6

★★★fs/ 以下
c039fb78 t __initcall_fcntl_init6
c039fb7c t __initcall_proc_filesystems_init6
...
c039fbbc t __initcall_init_jffs2_fs6
c039fbc0 t __initcall_init_romfs_fs6

★★★ipc/ 以下
c039fbc4 t __initcall_ipc_init6
c039fbc8 t __initcall_ipc_sysctl_init6

★★★crypto/ 以下
c039fbcc t __initcall_crypto_algapi_init6
c039fbd0 t __initcall_aes_init6

★★★block/ 以下
c039fbd4 t __initcall_proc_genhd_init6
c039fbd8 t __initcall_bsg_init6
c039fbdc t __initcall_noop_init6
c039fbe0 t __initcall_deadline_init6
c039fbe4 t __initcall_cfq_init6

★★★drivers/ 以下
c039fbe8 t __initcall_pl061_gpio_init6
c039fbec t __initcall_fb_console_init6
...
c039fc68 t __initcall_ms_driver_init6  -> module_hid_driverが生成した関数
c039fc6c t __initcall_mr_driver_init6  -> module_hid_driverが生成した関数

★★★net/ 以下
c039fc70 t __initcall_sock_diag_init6
c039fc74 t __initcall_flow_cache_init_global6
...
c039fc90 t __initcall_packet_init6
c039fc94 T __initcall7_start

このようになっています。linux/Makefileを見てみると、

ifeq ($(KBUILD_EXTMOD),)
core-y          += kernel/ mm/ fs/ ipc/ security/ crypto/ block/

このように同じ順で並んでいることがわかります。ざっと見た感じだと、サブディレクトリ内のモジュール達(fs, driversの下)も同様に、Makefileに書いた順で初期化されるようです。

要するに、モジュールBがモジュールAに依存している場合、MakefileにはA → Bの順で書かないとなりません。逆に書いてしまうと、モジュールBが先に初期化され、未初期化のモジュールAを呼び出し、カーネルがクラッシュする悲劇が起きます。

編集者:すずき(2023/04/29 21:40)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2015年10月10日 >>> 2015年10月10日
link もっと後

管理用メニュー

link 記事を新規作成

<2015>
<<<10>>>
----123
45678910
11121314151617
18192021222324
25262728293031

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事3件

  • link 24年3月25日
    すずき (03/26 03:20)
    「[Might and Magic Book One TASのその後] 目次: Might and Magicファミコン版以前(...」
  • link 21年10月4日
    すずき (03/26 03:14)
    「[Might and Magicファミコン版 - まとめリンク] 目次: Might and Magicファミコン版TASに挑...」
  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/26 03:20