2019.10.09
カテゴリ： ソフト開発日誌
Linux で device (driver) と Userland を結ぶ node に付く major, minor 番号の成り立ちについて調べていた。
おそらく今時の Linux user は major, minor 番号を意識することは殆ど無いと思う。多くの場合、udev が煩雑な処理を自動的に行っているはずだ。
簡単に major, minor 番号について見ていく、コマンド ls -la /dev で表示される中で、次の様に "8, 0", "8, 1", ... と表示される値が "major, minor" だ。device に付けられた番号で、この番号を持つ node を mknod コマンドで major, minor 番号 と {block | character} device の区別を加えてファイルシステム上に作ると、open(), read(), write(), ioctl(), close(), ... などの system call で操作できるようになる。
major, minor 番号とも 0..255 の範囲だと思っていた。これは違うことに気づいたのか調べる切っ掛けだ。古くから unix 系 OS を使っていた思い込みだ。
major, minor 番号はビット単位の論理演算により dev_t 型に格納され扱われている。Userland では stat() 系の関数に使われる struct stat の st_dev がその代表だ。Kernel では device driver と file system を中心として、dev_t 型に major, minor 番号を(userland と同様ではない)ビット単位の論理演算で格納している。
Linux Kernel と Userland の dev_t に格納された major, minor のビット位置を調査してお絵描きしてみたのが次の図だ。上半分が kernel の中の dev_t、下半分が Userland の dev_t だ。
流れは Kernel to Userland の方向で書いてある。Kernel の中の dev_t の値が、Userland の dev_t (例えば struct stat 構造体のメンバ st_dev) にどのように格納されるかを示している。
MAJOR() , MINOR() , MKDEV() 、Userland の中では major() , minor() , makedev() を使っていれば dev_t の bit 配置がどうなっているのか気にしなくて良いということだ。
kernel の中で dev_t は unsigned の 32bit 型として定義されている。 dev_t の型定義 、 __kernel_dev_t の型定義 、と追っていけば比較的容易に確認できる。CPU 語長に依存しない実装だ。単純に上位 12bit が major 番号、下位 20bit が minor 番号になっている。
SystemV 系 OS の Userland で dev_t は unsigned 64bit 型として定義されている。GLIBC の実装を分かりやすそうな経路で追うと、 posix/bits/types.h (dev_t を __dev_t で型定義) , posix/bits/types.h (__dev_t を __DEV_T_TYPE で型定義) sysdeps/unix/sysv/linux/generic/bits/typesizes.h (__DEV_T_TYPPE を __UQUAD_TYPE で定義、あるいは CPU arch. 毎の実装) , posix/bits/types.h(__UQUAD_TYPE を __uint64_t で定義あるいは 64bit 語長 CPU では unsigned long int で定義) , と追っていけば確認できる。
Userland の dev_t は bit 19 .. 8 (0x13 .. 0x08) の 12bit が major 番号、bit 31 .. 20 (0x1f .. 0x14), bit 7 .. 0 (0x07 .. 0x00) の部分が Minor 番号になっている。
Userland で dev_t は 64bit ある。kernel 内 dev_t から userland の dev_t に変換する new_encode_dev() は 32bit 型の整数を返すので常に上位 32bit は 0 になっている。
bits/sysmacros.h に Userland の major(), minor(), makedev() の実装が有るので、userland の dev_t に対するビットシフトとマスク処理を確認できる。注: 古い GLIBC は別の場所に実装がある。
Userland の dev_t が複雑なビット配置になってしまった事情は古い Unix 系 OS の慣習であった major, minor とも 8bit だったのが原因なのだろうか。
おそらく今時の Linux user は major, minor 番号を意識することは殆ど無いと思う。多くの場合、udev が煩雑な処理を自動的に行っているはずだ。
簡単に major, minor 番号について見ていく、コマンド ls -la /dev で表示される中で、次の様に "8, 0", "8, 1", ... と表示される値が "major, minor" だ。device に付けられた番号で、この番号を持つ node を mknod コマンドで major, minor 番号 と {block | character} device の区別を加えてファイルシステム上に作ると、open(), read(), write(), ioctl(), close(), ... などの system call で操作できるようになる。
ls -la /dev
-- snip --
brw-rw---- 1 root disk 8, 0 Sep 25 02:21 sda
brw-rw---- 1 root disk 8, 1 Sep 9 05:23 sda1
brw-rw---- 1 root disk 8, 2 Sep 9 05:23 sda2
brw-rw---- 1 root disk 8, 3 Sep 9 05:23 sda3
brw-rw---- 1 root disk 8, 5 Sep 9 05:23 sda5
-- snip --
-- snip --
brw-rw---- 1 root disk 8, 0 Sep 25 02:21 sda
brw-rw---- 1 root disk 8, 1 Sep 9 05:23 sda1
brw-rw---- 1 root disk 8, 2 Sep 9 05:23 sda2
brw-rw---- 1 root disk 8, 3 Sep 9 05:23 sda3
brw-rw---- 1 root disk 8, 5 Sep 9 05:23 sda5
-- snip --
major, minor 番号とも 0..255 の範囲だと思っていた。これは違うことに気づいたのか調べる切っ掛けだ。古くから unix 系 OS を使っていた思い込みだ。
major, minor 番号はビット単位の論理演算により dev_t 型に格納され扱われている。Userland では stat() 系の関数に使われる struct stat の st_dev がその代表だ。Kernel では device driver と file system を中心として、dev_t 型に major, minor 番号を(userland と同様ではない)ビット単位の論理演算で格納している。
Linux Kernel と Userland の dev_t に格納された major, minor のビット位置を調査してお絵描きしてみたのが次の図だ。上半分が kernel の中の dev_t、下半分が Userland の dev_t だ。
流れは Kernel to Userland の方向で書いてある。Kernel の中の dev_t の値が、Userland の dev_t (例えば struct stat 構造体のメンバ st_dev) にどのように格納されるかを示している。
MAJOR() , MINOR() , MKDEV() 、Userland の中では major() , minor() , makedev() を使っていれば dev_t の bit 配置がどうなっているのか気にしなくて良いということだ。
kernel の中で dev_t は unsigned の 32bit 型として定義されている。 dev_t の型定義 、 __kernel_dev_t の型定義 、と追っていけば比較的容易に確認できる。CPU 語長に依存しない実装だ。単純に上位 12bit が major 番号、下位 20bit が minor 番号になっている。
SystemV 系 OS の Userland で dev_t は unsigned 64bit 型として定義されている。GLIBC の実装を分かりやすそうな経路で追うと、 posix/bits/types.h (dev_t を __dev_t で型定義) , posix/bits/types.h (__dev_t を __DEV_T_TYPE で型定義) sysdeps/unix/sysv/linux/generic/bits/typesizes.h (__DEV_T_TYPPE を __UQUAD_TYPE で定義、あるいは CPU arch. 毎の実装) , posix/bits/types.h(__UQUAD_TYPE を __uint64_t で定義あるいは 64bit 語長 CPU では unsigned long int で定義) , と追っていけば確認できる。
Userland の dev_t は bit 19 .. 8 (0x13 .. 0x08) の 12bit が major 番号、bit 31 .. 20 (0x1f .. 0x14), bit 7 .. 0 (0x07 .. 0x00) の部分が Minor 番号になっている。
Userland で dev_t は 64bit ある。kernel 内 dev_t から userland の dev_t に変換する new_encode_dev() は 32bit 型の整数を返すので常に上位 32bit は 0 になっている。
bits/sysmacros.h に Userland の major(), minor(), makedev() の実装が有るので、userland の dev_t に対するビットシフトとマスク処理を確認できる。注: 古い GLIBC は別の場所に実装がある。
Userland の dev_t が複雑なビット配置になってしまった事情は古い Unix 系 OS の慣習であった major, minor とも 8bit だったのが原因なのだろうか。
お気に入りの記事を「いいね！」で応援しよう
[ソフト開発日誌] カテゴリの最新記事
-
商用電源監視サーバー更新 - 閏年 2/29 以… 2024.05.31
-
Futaba M202MD10B アプリ と コマンドシー… 2023.09.05
-
Intel Core i5-10600K 偽物説 - 近所の HA… 2023.09.04
【毎日開催】
15記事にいいね！で1ポイント
カレンダー
サイド自由欄
コメント新着
© Rakuten Group, Inc.
