システムコール発行後の処理

以前GDBを使って、printf()のリバースエンジニアリングを行ったのですが、
最終的にはシステムコールである write() が発行されていました。

この後は、カーネル空間に入るので、詳しくは探査出来なかったのですが・・・
#システムコール発行後の処理はどうなっているのでしょうか？？

write()システムコールは デバイスファイルに対して書き込みを行うはずです。
このデバイスファイルに書かれた内容に基づいて、デバイスドライバがデバイスを制御すると思います。

ここまでは、正しいでしょうか？

この「デバイスファイルが更新された」というのは、デーモンプロセスが常にデバイスファイルを監視している必要がありますよね？？

割り込みハンドラとは、ハードウェア割り込み発生の際に出てくるプログラムですよね？
システムコール発行時（ソフトウェア割り込み）は、割り込みハンドラを使いますか？

このデバイスファイルからデバイスドライバへの連携はどのようにして行われているのでしょうか？？

カーネル空間の質問なんですが、教えてください。

行動規範の内容に同意します

回答2件

ベストアンサー

こんにちは。

この「デバイスファイルが更新された」というのは、デーモンプロセスが常にデバイスファイルを監視している必要がありますよね？？

デバイスファイルについて、微妙に捉え方を間違っているようです。

上記のWikipediaにあるように「ファイルシステム上であたかも通常のファイルのような形で提示されるデバイスドライバのインタフェースである。」ですので、物理的なファイルがあるわけではないです。

デバイスに「ファイル名」の構文で名前を付けたと考えて良いと思います。
ファイルやデバイスへのopenコールが「ファイル名」を解析して、適切なデバイス・ドライバと結びつけたデバイス制御用データを生成し、デバイス・ドライバのopenルーチンを呼んで初期化してから、デバイス制御用データのハンドルを返却します。
writeコールではそのハンドルを指定します。OSはそれを見て適切なデバイス・ドライバのwriteルーチンを呼びます。

（linuxのソースを読んだのはかなり昔だったので、微妙に違う部分はあるかも。）

投稿2017/04/27 14:12

Chironian

総合スコア23272

strike1217

2017/04/27 14:39 編集

デバイスドライバ自体は、プログラムですよね？？システムコールで呼びだされたら、プロセスとして動くんですか？？

Chironian

2017/04/27 15:15

> デバイスドライバ自体は、プログラムですよね？？その通りですね。 > システムコールで呼びだされたら、プロセスとして動くんですか？？違います。カーネル・モードのプログラムは、主に割り込みハンドラーとして動作します。スレッドもそれなりに使われているようです。しかし、カーネル内にプロセスは存在しません。　　プロセス＝スレッド＋他のプロセスから独立したメモリ空間と言うイメージです。これにより不具合があっても、他のプロセスを破壊しないわけです。しかし、カーネルに不具合があると全てを破壊しますので、メモリ空間を分離する意味があまりないのです。

strike1217

2017/04/27 15:36

カーネルはプロセスを持たないんですね！システムコール発行後、デバイスドライバが起動するんですか？？デバイスファイルとデバイスドライバの関係がよくわかりません。

Chironian

2017/04/27 16:12

デバイス・ドライバは、システム起動時にロードされる場合が多いです。システム起動後にロードされるものもあります。システム・コール発行後に、そのデバイス・ドライバの該当するルーチンが呼ばれます。ここは普通にサブルーチンだったと思います。デバイスをオープンする時に指定するデバイス名が「デバイス・ファイル」と考えると分かりやすいと思います。デバイスを指定する時「デバイス・ファイル名」を指定し、その名称からでデバイス・ドライバを特定できるのです。

strike1217

2017/04/28 03:18

システムコールはソフトウェア割り込みです。では、割り込みハンドラは起動するのでしょうか？？システムコール→割り込みハンドラ→cpu特権モード移行デバイスドライバは、割り込みハンドラによって起動するものでしょうか？？デバイスファイル名を元にデバイスドライバの選択を行うということは、システムコール発行後、デバイスファイルへのアクセスとデバイスドライバの起動は、同時ということですか？

Chironian

2017/04/28 03:34

> システムコールはソフトウェア割り込みです。 > では、割り込みハンドラは起動するのでしょうか？？起動しますよ。 http://www.wdic.org/w/TECH/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%B3%E3%83%BC%E3%83%AB > システムコール→割り込みハンドラ→cpu特権モード移行 > デバイスドライバは、割り込みハンドラによって起動するものでしょうか？？システム・コールで起動された割り込みハンドラーから、デバイスドライバの当該処理の処理ルーチンがサブルーチン・コールされ筈です。(記憶が曖昧ですが、ここにソフトウェア割り込みを使うのは性能面で避けたいところですし。) > デバイスファイルへのアクセスとデバイスドライバの起動は、同時ということですか？「デバイスドライバの起動」をどのような意味で使っているのか良く分かりません。メモリへロードされること?　openされること?　その他のリクエストをされること?　などいろいろな意味で解釈できます。デバイス・ドライバは普通のプロセスの起動時のようにメモリへロード後エントリーポイントから実行開始と言う手順は発生しませんので曖昧になるのです。

strike1217

2017/04/28 03:39

ユーザー空間とだいぶ違うんですね。デバイスドライバのソースコードだけ読んでも、システムコールとの境界がよくわからないです。

strike1217

2017/04/28 03:47

デバイスファイルへの書き込みは、CPUがカーネルモードに移行した後だけ許可されるものですか？？ write()システムコールは、ファイルへの書き込みですよね？

Chironian

2017/04/28 04:19

> デバイスドライバのソースコードだけ読んでも、システムコールとの境界がよくわからないです。ユーザ・プロセスからのシステム・コールをデバイス・ドライバへ振り分けるカーネルのソースがどこかにある筈です。その辺を解説している書籍なりサイトなりを見つけるのが早道かと。 > write()システムコールは、ファイルへの書き込みですよね？回答で示したように「デバイス・ファイル」は一種のAPIであって、HDDに保存されているような「ファイル」の概念ではないですよ。「ファイルへの書き込み」が、HDDに記録されているような「ファイル」をイメージされているのでしたら、違います。

strike1217

2017/04/28 04:26

分かりました。ありがとうございます。

strike1217

2017/04/28 05:18

見つけました。詳細Linuxカーネル　キャラクタデバイスへのアクセスで、VFSによって、デバイスへのアクセスかファイルへの書き込みかを分けているようです。

strike1217

2017/04/28 15:19

https://teratail.com/questions/74238 先ほどの質問で、イメージがつかめてきました。割り込みンハンドラなど、実際の呼び出しはさらに複雑そうなので、「OSコードリーディング」という本で頑張ってみます。ありがとうございました。

行動規範の内容に同意します

Chironianさんが回答されてますので補足だけします。

カーネル空間でプログラムはカーネルスレッドと呼ばれる特権プロセスで動作します。これはユーザーモードプロセスとは明確に異なります。

デーモンが監視するというのはプロセスを中心にしてみていますが、幾つものプログラムが独立して並列に動いているように見えるのはOSの仕組みです。CPUを中心に見ると1msなり4msなりで次々と実行するプログラムを切り替えています。それを決めるのはスケジューラーというOSの機能で、スケジューラーの上でカーネル空間で動くタスク(カーネルスレッドで動作するプログラム)とユーザー空間で動くタスク(ユーザーモードプロセスで動くプログラム)は優先度が異なります。

またプログラムが切り替わる(コンテキストがスイッチする)条件は、

タイムスライスを使い切ったとき
システムコールを呼び出したとき
IO待ちからの復帰時
プロセス生成、終了時

などでこれ以外にもいくつかあったと思います（が思い出せません）

プロセスのスケジュールに関する統計は/proc/プロセスID/schedで見ることができます。

以下例としてbashのスケジュール統計。
nr_switchesが1091なので138回スイッチされています。
nr_voluntary_switchesは自発的なスイッチ回数です。
一方でnr_involuntary_switchesは非自発的なスイッチ回数で、タイムスライスを使い切ると多くなります。

[root@localhost ~]# cat /proc/18060/sched 
bash (18060, #threads: 1)
-------------------------------------------------------------------
se.exec_start                                :    1159654106.105410
se.vruntime                                  :      18776825.967971
se.sum_exec_runtime                          :          4619.692993
nr_switches                                  :                 1091
nr_voluntary_switches                        :                 1042
nr_involuntary_switches                      :                   49
se.load.weight                               :                 1024
policy                                       :                    0
prio                                         :                  120
clock-delta                                  :                   25
mm->numa_scan_seq                            :                    0
numa_migrations, 0
numa_faults_memory, 0, 0, 1, 0, -1
numa_faults_memory, 1, 0, 0, 0, -1

#ビジーループを回してみる
[root@localhost ~]# while [ 1 ];  do a=$(( 1 + 1 )); done

[root@localhost ~]# cat /proc/18060/sched 
bash (18060, #threads: 1)
-------------------------------------------------------------------
se.exec_start                                :    1159675494.749491
se.vruntime                                  :      18776298.610844
se.sum_exec_runtime                          :         21809.142310
nr_switches                                  :                 1322
nr_voluntary_switches                        :                 1049
nr_involuntary_switches                      :                  273
se.load.weight                               :                 1024
policy                                       :                    0
prio                                         :                  120
clock-delta                                  :                   21
mm->numa_scan_seq                            :                    0
numa_migrations, 0
numa_faults_memory, 0, 0, 1, 0, -1
numa_faults_memory, 1, 0, 0, 0, -1