# 概要
CentOS6.9にてカーネルパニックした時のカーネルダンプ出力の設定メモ

## カーネルパニックとは
* カーネルで致命的なエラーが発生し、OSの稼動が完全に停止した状態の事。カーネルが自発的にpanic()関数を実行した際に発生する。
* **カーネルの設定でパニックした時に再起動する設定をいれていないと、停止したままになる。**

./kernel/panic.cで定義しているみたい。

```bash
 (v3.3.4)$ grep -r "void panic(" ./
./include/linux/kernel.h:void panic(const char *fmt, ...)
./kernel/panic.c:void panic(const char *fmt, ...)
./arch/unicore32/include/asm/system.h:extern void panic(const char *fmt, ...);
./arch/um/include/shared/user.h:extern void panic(const char *fmt, ...)
```
## 流れ
カーネルパニック発生
↓　
クラッシュカーネルに処理を移行
↓
クラッシュカーネルでカーネルダンプを出力する

クラッシュカーネルが起動するのは安全のため。クラッシュカーネルが起動するための領域をブートローダの設定ファイルで予約しないといけない。

予約すると、下記の様にカーネルがクラッシュカーネルを配置する領域を獲得する。

```bash
# cat /proc/iomem 
00000000-00000fff : reserved
00001000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000c8bff : Video ROM
000c9000-000c97ff : Adapter ROM
000c9800-000cb9ff : Adapter ROM
000f0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-dfffcfff : System RAM
  01000000-01556f04 : Kernel code
  01556f05-01c2170f : Kernel data
  01d77000-02045963 : Kernel bss
  03000000-0b0fffff : Crash kernel
```

# 設定
## 必要なパッケージ
```bash
yum install kexec-tools
```
kdump コマンドが使えるようになる。

## 必要な設定
### /etc/gurb/grub.cfg (grub1の場合)
* ブートローダのkernel行に**crashkernel=値**を設定
* メインメモリが4GB以上のときは**crashkernel=auto**で自動でクラッシュカーネルの領域を設定してくれる。それ以下の場合、デフォルトでは128MBに物理メモリー1TBごとに64 MB を加えたものを設定する。なので4GB以下の場合は**crashkernel=128M**で良さそう。Bはいらない。
* RHEL6の場合は値は**crashkernel=値**、RHEL5の場合は**crashkernel=値@値**になる

### kdumpコマンド
```bash
service kdump start
```
あとはchkconfigでOS起動時にサービスが起動するようにする

デフォルトは`crashkernel=auto`になっていて、もしメモリが4GBより少ない場合、下記のようなエラーになるので、`crashkernel=128M`に設定して再起動するとうまくいく。

```bash
# service kdump restart
Memory for crashkernel is not reserved
Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
Stopping kdump:                                            [FAILED]
Starting kdump:                                            [FAILED]
```

## 再起動設定
何も設定していないとカーネルパニックを起こしたらそのまま停止状態になる。それだとめんどくさいので、再起動するように設定をする。下記は10秒後に再起動する。

```etc/sysctl.conf 
kernel.panic = 10
```
`sysctl -p`で有効にする。

## カーネルダンプの出力先
* 設定ファイル
    - /etc/kdump.conf

```bash
・
・
#raw /dev/sda5
#ext4 /dev/sda3
#ext4 LABEL=/boot
#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
#net my.server.com:/export/tmp
#net user@my.server.com
path /var/crash
core_collector makedumpfile -c --message-level 1 -d 31
#core_collector scp
#core_collector cp --sparse=always
#extra_bins /bin/cp
#link_delay 60
#kdump_post /var/crash/scripts/kdump-post.sh
#extra_bins /usr/bin/lftp
#disk_timeout 30
#extra_modules gfs2
#options modulename options
#default shell
#debug_mem_level 0
#force_rebuild 1
#sshkey /root/.ssh/kdump_id_rsa
#fence_kdump_args -p 7410 -f auto -c 0 -i 10
#fence_kdump_nodes node1 node2
```

* デフォルトだと/var/crash/タイムスタンプ/vmcore。設定でリモートや普段アンマウントしているファイルシステムも設定できる。
* 通常の運用だと別ディスクとか専用のパーティションを区切ったりするのがよいみたい

## 出力サイズ
メモリ使用量によって変動しそう。

メモリ4.5Gくらい使用している場合。あまり大きなサイズにはならないのかな？？

```bash
$ ls -lh
total 105M
-rw-------. 1 root root 105M May 12 07:12 vmcore
-rw-r--r--. 1 root root  30K May 12 07:11 vmcore-dmesg.txt
```



## テスト
意図的にカーネルパニックを発動できる

```bash

echo c > /proc/sysrq-trigger 
```
上手くいけば/var/crash/以下にカーネルダンプが出力される。

# メモ
カーネルダンプの設定などにかかわらず、カーネルパニックが起きたら`/var/log/messages`などにログが残るのかと思っていたら、panicに関するログは出力されなかった。

http://blogs.itmedia.co.jp/komata/2016/07/linux_1.html

↑で言及されているように、カーネルパニックがおきてもそのメッセージは実際の画面で確認するしかなさそう。ただ、netconsoleなどでそのメッセージをリモートに送ることができるみたい。


# 参考
http://itpro.nikkeibp.co.jp/article/Keyword/20100917/352164/
http://blogs.itmedia.co.jp/komata/2016/07/linux_1.html
http://www.intellilink.co.jp/article/column/oss01.html




<h1>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h1>

<p>CentOS6.9にてカーネルパニックした時のカーネルダンプ出力の設定メモ</p>

<h2>
<span id="カーネルパニックとは" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%83%91%E3%83%8B%E3%83%83%E3%82%AF%E3%81%A8%E3%81%AF"><i class="fa fa-link"></i></a>カーネルパニックとは</h2>

<ul>
<li>カーネルで致命的なエラーが発生し、OSの稼動が完全に停止した状態の事。カーネルが自発的にpanic()関数を実行した際に発生する。</li>
<li><strong>カーネルの設定でパニックした時に再起動する設定をいれていないと、停止したままになる。</strong></li>
</ul>

<p>./kernel/panic.cで定義しているみたい。</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code> <span class="o">(</span>v3.3.4<span class="o">)</span><span class="nv">$ </span><span class="nb">grep</span> <span class="nt">-r</span> <span class="s2">"void panic("</span> ./
./include/linux/kernel.h:void panic<span class="o">(</span>const char <span class="k">*</span><span class="nb">fmt</span>, ...<span class="o">)</span>
./kernel/panic.c:void panic<span class="o">(</span>const char <span class="k">*</span><span class="nb">fmt</span>, ...<span class="o">)</span>
./arch/unicore32/include/asm/system.h:extern void panic<span class="o">(</span>const char <span class="k">*</span><span class="nb">fmt</span>, ...<span class="o">)</span><span class="p">;</span>
./arch/um/include/shared/user.h:extern void panic<span class="o">(</span>const char <span class="k">*</span><span class="nb">fmt</span>, ...<span class="o">)</span>
</code></pre></div></div>

<h2>
<span id="流れ" class="fragment"></span><a href="#%E6%B5%81%E3%82%8C"><i class="fa fa-link"></i></a>流れ</h2>

<p>カーネルパニック発生<br>
↓　<br>
クラッシュカーネルに処理を移行<br>
↓<br>
クラッシュカーネルでカーネルダンプを出力する</p>

<p>クラッシュカーネルが起動するのは安全のため。クラッシュカーネルが起動するための領域をブートローダの設定ファイルで予約しないといけない。</p>

<p>予約すると、下記の様にカーネルがクラッシュカーネルを配置する領域を獲得する。</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="c"># cat /proc/iomem </span>
00000000-00000fff : reserved
00001000-0009dbff : System RAM
0009dc00-0009ffff : reserved
000c0000-000c8bff : Video ROM
000c9000-000c97ff : Adapter ROM
000c9800-000cb9ff : Adapter ROM
000f0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-dfffcfff : System RAM
  01000000-01556f04 : Kernel code
  01556f05-01c2170f : Kernel data
  01d77000-02045963 : Kernel bss
  03000000-0b0fffff : Crash kernel
</code></pre></div></div>

<h1>
<span id="設定" class="fragment"></span><a href="#%E8%A8%AD%E5%AE%9A"><i class="fa fa-link"></i></a>設定</h1>

<h2>
<span id="必要なパッケージ" class="fragment"></span><a href="#%E5%BF%85%E8%A6%81%E3%81%AA%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8"><i class="fa fa-link"></i></a>必要なパッケージ</h2>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>yum <span class="nb">install </span>kexec-tools
</code></pre></div></div>

<p>kdump コマンドが使えるようになる。</p>

<h2>
<span id="必要な設定" class="fragment"></span><a href="#%E5%BF%85%E8%A6%81%E3%81%AA%E8%A8%AD%E5%AE%9A"><i class="fa fa-link"></i></a>必要な設定</h2>

<h3>
<span id="etcgurbgrubcfg-grub1の場合" class="fragment"></span><a href="#etcgurbgrubcfg-grub1%E3%81%AE%E5%A0%B4%E5%90%88"><i class="fa fa-link"></i></a>/etc/gurb/grub.cfg (grub1の場合)</h3>

<ul>
<li>ブートローダのkernel行に<strong>crashkernel=値</strong>を設定</li>
<li>メインメモリが4GB以上のときは<strong>crashkernel=auto</strong>で自動でクラッシュカーネルの領域を設定してくれる。それ以下の場合、デフォルトでは128MBに物理メモリー1TBごとに64 MB を加えたものを設定する。なので4GB以下の場合は<strong>crashkernel=128M</strong>で良さそう。Bはいらない。</li>
<li>RHEL6の場合は値は<strong>crashkernel=値</strong>、RHEL5の場合は<strong>crashkernel=値@値</strong>になる</li>
</ul>

<h3>
<span id="kdumpコマンド" class="fragment"></span><a href="#kdump%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89"><i class="fa fa-link"></i></a>kdumpコマンド</h3>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>service kdump start
</code></pre></div></div>

<p>あとはchkconfigでOS起動時にサービスが起動するようにする</p>

<p>デフォルトは<code>crashkernel=auto</code>になっていて、もしメモリが4GBより少ない場合、下記のようなエラーになるので、<code>crashkernel=128M</code>に設定して再起動するとうまくいく。</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="c"># service kdump restart</span>
Memory <span class="k">for </span>crashkernel is not reserved
Please reserve memory by passing <span class="s2">"crashkernel=X@Y"</span> parameter to the kernel
Stopping kdump:                                            <span class="o">[</span>FAILED]
Starting kdump:                                            <span class="o">[</span>FAILED]
</code></pre></div></div>

<h2>
<span id="再起動設定" class="fragment"></span><a href="#%E5%86%8D%E8%B5%B7%E5%8B%95%E8%A8%AD%E5%AE%9A"><i class="fa fa-link"></i></a>再起動設定</h2>

<p>何も設定していないとカーネルパニックを起こしたらそのまま停止状態になる。それだとめんどくさいので、再起動するように設定をする。下記は10秒後に再起動する。</p>

<div class="code-frame" data-lang="text">
<div class="code-lang"><span class="bold">etc/sysctl.conf</span></div>
<div class="highlight"><pre><code>kernel.panic = 10
</code></pre></div>
</div>

<p><code>sysctl -p</code>で有効にする。</p>

<h2>
<span id="カーネルダンプの出力先" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%83%80%E3%83%B3%E3%83%97%E3%81%AE%E5%87%BA%E5%8A%9B%E5%85%88"><i class="fa fa-link"></i></a>カーネルダンプの出力先</h2>

<ul>
<li>設定ファイル

<ul>
<li>/etc/kdump.conf</li>
</ul>
</li>
</ul>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>・
・
<span class="c">#raw /dev/sda5</span>
<span class="c">#ext4 /dev/sda3</span>
<span class="c">#ext4 LABEL=/boot</span>
<span class="c">#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937</span>
<span class="c">#net my.server.com:/export/tmp</span>
<span class="c">#net user@my.server.com</span>
path /var/crash
core_collector makedumpfile <span class="nt">-c</span> <span class="nt">--message-level</span> 1 <span class="nt">-d</span> 31
<span class="c">#core_collector scp</span>
<span class="c">#core_collector cp --sparse=always</span>
<span class="c">#extra_bins /bin/cp</span>
<span class="c">#link_delay 60</span>
<span class="c">#kdump_post /var/crash/scripts/kdump-post.sh</span>
<span class="c">#extra_bins /usr/bin/lftp</span>
<span class="c">#disk_timeout 30</span>
<span class="c">#extra_modules gfs2</span>
<span class="c">#options modulename options</span>
<span class="c">#default shell</span>
<span class="c">#debug_mem_level 0</span>
<span class="c">#force_rebuild 1</span>
<span class="c">#sshkey /root/.ssh/kdump_id_rsa</span>
<span class="c">#fence_kdump_args -p 7410 -f auto -c 0 -i 10</span>
<span class="c">#fence_kdump_nodes node1 node2</span>
</code></pre></div></div>

<ul>
<li>デフォルトだと/var/crash/タイムスタンプ/vmcore。設定でリモートや普段アンマウントしているファイルシステムも設定できる。</li>
<li>通常の運用だと別ディスクとか専用のパーティションを区切ったりするのがよいみたい</li>
</ul>

<h2>
<span id="出力サイズ" class="fragment"></span><a href="#%E5%87%BA%E5%8A%9B%E3%82%B5%E3%82%A4%E3%82%BA"><i class="fa fa-link"></i></a>出力サイズ</h2>

<p>メモリ使用量によって変動しそう。</p>

<p>メモリ4.5Gくらい使用している場合。あまり大きなサイズにはならないのかな？？</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="nv">$ </span><span class="nb">ls</span> <span class="nt">-lh</span>
total 105M
<span class="nt">-rw-------</span><span class="nb">.</span> 1 root root 105M May 12 07:12 vmcore
<span class="nt">-rw-r--r--</span><span class="nb">.</span> 1 root root  30K May 12 07:11 vmcore-dmesg.txt
</code></pre></div></div>

<h2>
<span id="テスト" class="fragment"></span><a href="#%E3%83%86%E3%82%B9%E3%83%88"><i class="fa fa-link"></i></a>テスト</h2>

<p>意図的にカーネルパニックを発動できる</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>
<span class="nb">echo </span>c <span class="o">&gt;</span> /proc/sysrq-trigger 
</code></pre></div></div>

<p>上手くいけば/var/crash/以下にカーネルダンプが出力される。</p>

<h1>
<span id="メモ" class="fragment"></span><a href="#%E3%83%A1%E3%83%A2"><i class="fa fa-link"></i></a>メモ</h1>

<p>カーネルダンプの設定などにかかわらず、カーネルパニックが起きたら<code>/var/log/messages</code>などにログが残るのかと思っていたら、panicに関するログは出力されなかった。</p>

<p><qiita-embed-ogp src="http://blogs.itmedia.co.jp/komata/2016/07/linux_1.html"></qiita-embed-ogp></p>

<p>↑で言及されているように、カーネルパニックがおきてもそのメッセージは実際の画面で確認するしかなさそう。ただ、netconsoleなどでそのメッセージをリモートに送ることができるみたい。</p>

<h1>
<span id="参考" class="fragment"></span><a href="#%E5%8F%82%E8%80%83"><i class="fa fa-link"></i></a>参考</h1>

<p><a href="http://itpro.nikkeibp.co.jp/article/Keyword/20100917/352164/" class="autolink" rel="nofollow noopener" target="_blank">http://itpro.nikkeibp.co.jp/article/Keyword/20100917/352164/</a><br>
<a href="http://blogs.itmedia.co.jp/komata/2016/07/linux_1.html" class="autolink" rel="nofollow noopener" target="_blank">http://blogs.itmedia.co.jp/komata/2016/07/linux_1.html</a><br>
<a href="http://www.intellilink.co.jp/article/column/oss01.html" class="autolink" rel="nofollow noopener" target="_blank">http://www.intellilink.co.jp/article/column/oss01.html</a></p>


カーネルダンプ出力設定メモ

備忘録です。間違いありますm(__)m。


# 概要
* 個々のプロセスのコアダンプを出力させるための設定メモ.
* `CentOS6.9`


# 個々のプロセスのリソース制限
コアダンプ以外にもファイルディスクリプタの数などシステムのリソースを**ulimit**によって制限できる。

# コマンドとか用語
## SoftLimit確認と変更
確認

```bash
ulimit -Sc
```
変更

```bash
ulimit -Sc 値
```

## HardLimit確認と変更
確認

```bash

ulimit -Hc
```

変更

```bash

ulimit -Hc 値
```

## SoftLimitとHardLimitの同時変更

```bash

ulimit -c 値
```

## Soft Limit
* **実際の制限値(コアダンプのサイズ)**
* Soft Limitが0だとコアダンプが出力されない

## Hard Limit
* **個々のユーザーが**ulimitコマンド**で変更する際の変更可能な上限値(変更可能上限値)**
* rootユーザー以外はハードリミットの値を増加させることができない。

# ulimitを使ってリソース制限を設定するタイミング
* コマンドラインから実行のプロセスに対して
* OS起動時に立上るデーモンプロセスに対して


# コアダンプ出力先設定
* /etc/sysctl.confに`kernel.core_pattern = /tmp/core`を設定する
* sysctl -p で有効にする 

# コマンドラインから実行のプロセスに対してコアダンプを出力する設定
## プロセスのリソース制限の確認
* ログインシェルを起動した時の各リソースの確認
* core file sizeがコアダンプ出力設定。ここで出力されているのは**SoftLimitの値**。値が0だと出力されない。

```bash
# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3878
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3878
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
```
## どうする
* コマンドラインからulimitコマンドでSoftLimit,HardLimtiを設定する。
* 恒久的に設定する場合は**/etc/security/limits.conf** に設定値を書く。下記参照

## SoftLimit、HardLimitのデフォルト値
* **/etc/security/limits.conf** に設定値を書く。
* **ログインシェル**、**対話シェル**起動でこのファイルを読み込む。デーモンプロセスは読みこまない。
* [ログインシェルとは](http://qiita.com/saikoro-steak/items/2e9b177fea202186bd2c)

```/etc/security/limits.conf
・
・
#<domain>      <type>  <item>         <value>
#

#*               soft    core            0
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4
・
・
```





# OS起動時に立上るデーモンプロセスに対して設定する場合
## コアダンプ出力できる設定かどうかの確認

**Max core file size**の値が0なら出力されない。0の場合、Soft Limitを修正しなければいけない。

```bash
# cat /proc/29500/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            10485760             unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             3878                 3878                 processes 
Max open files            16384                16384                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       3878                 3878                 signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        

```

## SoftLimitの修正
* OSが起動して各デーモンを**/etc/rc.d/init.d/各スクリプト**から立ち上げる時にSoftLimitを設定している様子
* **/etc/rc.d/init.d/funtcions**にてSoftLimitの設定を有効にしている
* **DAEMON_COREFILE_LIMIT**は通常空なので通常SoftLimitは0(コアダンプ出力しない)設定になっている。functionsとは、起動スクリプトで利用する関数を定義した一覧、でよいのかな？？

```bash:/etc/rc.d/funtcions
# -*-Shell-script-*-
#
# functions     This file contains functions to be used by most or all
#               shell scripts in the /etc/init.d directory.
#
・
・
414 ^   # make sure it doesn't core dump anywhere unless requested~
415 ^   corelimit="ulimit -S -c ${DAEMON_COREFILE_LIMIT:-0}"~
```

```bash
$ grep -r DAEMON_COREFILE_LIMIT /etc
/etc/rc.d/init.d/functions:     corelimit="ulimit -S -c ${DAEMON_COREFILE_LIMIT:-0}"
```


httpdの場合
スクリプトの先頭で**/etc/rc.d/init.d/functions**を読み込んでいる

```bash
#!/bin/bash
#
# httpd        Startup script for the Apache HTTP Server
#
# chkconfig: - 85 15
# description: The Apache HTTP Server is an efficient and extensible  \
#              server implementing the current HTTP standards.
# processname: httpd
# config: /etc/httpd/conf/httpd.conf
# config: /etc/sysconfig/httpd
# pidfile: /var/run/httpd/httpd.pid
#
### BEGIN INIT INFO
# Provides: httpd
# Required-Start: $local_fs $remote_fs $network $named
# Required-Stop: $local_fs $remote_fs $network
# Should-Start: distcache
# Short-Description: start and stop Apache HTTP Server
# Description: The Apache HTTP Server is an extensible server 
#  implementing the current HTTP standards.
### END INIT INFO

# Source function library.
. /etc/rc.d/init.d/functions

if [ -f /etc/sysconfig/httpd ]; then
        . /etc/sysconfig/httpd
fi
```

## どうするか
よってコアダンプを出力させるようにするためには例えばfunctionsの前で**DAEMON_COREFILE_LIMIT=unlimited**のような設定を追加したり、各起動スクリプトで
**`ulimit -S -c unlimited`**してSoftLimitの上書きをすれば良いはず。実際に前者の方法で上手くコアダンプを出力させることができた。

## upstartの場合
upsatartを利用するlogstashの場合、limit のフォーマットがありこの箇所で設定すれば上手くコアダンプを出力してくれる。

```bash:/etc/init/logstash.conf
description     "logstash"
start on filesystem or runlevel [2345]
stop on runlevel [!2345]

respawn
umask 022
nice 19
limit nofile 16384 16384
chroot /
chdir /

#limit core <softlimit> <hardlimit>
limit core unlimited unlimited
#limit cpu <softlimit> <hardlimit>
#limit data <softlimit> <hardlimit>
#limit fsize <softlimit> <hardlimit>
#limit memlock <softlimit> <hardlimit>
#limit msgqueue <softlimit> <hardlimit>
#limit nice <softlimit> <hardlimit>
#limit nofile <softlimit> <hardlimit>
#limit nproc <softlimit> <hardlimit>
#limit rss <softlimit> <hardlimit>
#limit rtprio <softlimit> <hardlimit>
#limit sigpending <softlimit> <hardlimit>
#limit stack <softlimit> <hardlimit>


script
  [ -r "/etc/default/logstash" ] && . "/etc/default/logstash"
  [ -r "/etc/sysconfig/logstash" ] && . "/etc/sysconfig/logstash"
  exec chroot --userspec logstash:logstash / /usr/share/logstash/bin/logstash "--path.settings" "/etc/logstash" >> /var/log/logstash-stdout.log 2>> /var/log/logstash-stderr.log
end script

```
## それ以外
* serviceコマンドやinitctlコマンドで起動しない場合、それ専用の起動シェルスクリプトにulimitコマンドを追加しないといけない。

## 他に
* 例えばmysqlだとmysqlの設定ファイルにコアダンプを出力させる設定があったような。各アプリケーションの設定ファイルで各種リソースを制限できるのかも。

# 参考
http://qiita.com/suzutsuki0220/items/aa84d7e2e8f37e867f3d
[プロのためのLinuxシステム構築・運用技術](https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE-Linux%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E6%A7%8B%E7%AF%89%E3%83%BB%E9%81%8B%E7%94%A8%E6%8A%80%E8%A1%93-Software-Design-plus/dp/4774145017/ref=sr_1_2?s=books&ie=UTF8&qid=1494485482&sr=1-2&keywords=%E3%83%97%E3%83%AD%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AElinux%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E6%A7%8B%E7%AF%89+%E9%81%8B%E7%94%A8%E6%8A%80%E8%A1%93)



<h1>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h1>

<ul>
<li>個々のプロセスのコアダンプを出力させるための設定メモ.</li>
<li><code>CentOS6.9</code></li>
</ul>

<h1>
<span id="個々のプロセスのリソース制限" class="fragment"></span><a href="#%E5%80%8B%E3%80%85%E3%81%AE%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%AE%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%88%B6%E9%99%90"><i class="fa fa-link"></i></a>個々のプロセスのリソース制限</h1>

<p>コアダンプ以外にもファイルディスクリプタの数などシステムのリソースを<strong>ulimit</strong>によって制限できる。</p>

<h1>
<span id="コマンドとか用語" class="fragment"></span><a href="#%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%A8%E3%81%8B%E7%94%A8%E8%AA%9E"><i class="fa fa-link"></i></a>コマンドとか用語</h1>

<h2>
<span id="softlimit確認と変更" class="fragment"></span><a href="#softlimit%E7%A2%BA%E8%AA%8D%E3%81%A8%E5%A4%89%E6%9B%B4"><i class="fa fa-link"></i></a>SoftLimit確認と変更</h2>

<p>確認</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="nb">ulimit</span> <span class="nt">-Sc</span>
</code></pre></div></div>

<p>変更</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="nb">ulimit</span> <span class="nt">-Sc</span> 値
</code></pre></div></div>

<h2>
<span id="hardlimit確認と変更" class="fragment"></span><a href="#hardlimit%E7%A2%BA%E8%AA%8D%E3%81%A8%E5%A4%89%E6%9B%B4"><i class="fa fa-link"></i></a>HardLimit確認と変更</h2>

<p>確認</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>
<span class="nb">ulimit</span> <span class="nt">-Hc</span>
</code></pre></div></div>

<p>変更</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>
<span class="nb">ulimit</span> <span class="nt">-Hc</span> 値
</code></pre></div></div>

<h2>
<span id="softlimitとhardlimitの同時変更" class="fragment"></span><a href="#softlimit%E3%81%A8hardlimit%E3%81%AE%E5%90%8C%E6%99%82%E5%A4%89%E6%9B%B4"><i class="fa fa-link"></i></a>SoftLimitとHardLimitの同時変更</h2>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>
<span class="nb">ulimit</span> <span class="nt">-c</span> 値
</code></pre></div></div>

<h2>
<span id="soft-limit" class="fragment"></span><a href="#soft-limit"><i class="fa fa-link"></i></a>Soft Limit</h2>

<ul>
<li><strong>実際の制限値(コアダンプのサイズ)</strong></li>
<li>Soft Limitが0だとコアダンプが出力されない</li>
</ul>

<h2>
<span id="hard-limit" class="fragment"></span><a href="#hard-limit"><i class="fa fa-link"></i></a>Hard Limit</h2>

<ul>
<li>
<strong>個々のユーザーが</strong>ulimitコマンド<strong>で変更する際の変更可能な上限値(変更可能上限値)</strong>
</li>
<li>rootユーザー以外はハードリミットの値を増加させることができない。</li>
</ul>

<h1>
<span id="ulimitを使ってリソース制限を設定するタイミング" class="fragment"></span><a href="#ulimit%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%88%B6%E9%99%90%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B%E3%82%BF%E3%82%A4%E3%83%9F%E3%83%B3%E3%82%B0"><i class="fa fa-link"></i></a>ulimitを使ってリソース制限を設定するタイミング</h1>

<ul>
<li>コマンドラインから実行のプロセスに対して</li>
<li>OS起動時に立上るデーモンプロセスに対して</li>
</ul>

<h1>
<span id="コアダンプ出力先設定" class="fragment"></span><a href="#%E3%82%B3%E3%82%A2%E3%83%80%E3%83%B3%E3%83%97%E5%87%BA%E5%8A%9B%E5%85%88%E8%A8%AD%E5%AE%9A"><i class="fa fa-link"></i></a>コアダンプ出力先設定</h1>

<ul>
<li>/etc/sysctl.confに<code>kernel.core_pattern = /tmp/core</code>を設定する</li>
<li>sysctl -p で有効にする </li>
</ul>

<h1>
<span id="コマンドラインから実行のプロセスに対してコアダンプを出力する設定" class="fragment"></span><a href="#%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3%E3%81%8B%E3%82%89%E5%AE%9F%E8%A1%8C%E3%81%AE%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%AB%E5%AF%BE%E3%81%97%E3%81%A6%E3%82%B3%E3%82%A2%E3%83%80%E3%83%B3%E3%83%97%E3%82%92%E5%87%BA%E5%8A%9B%E3%81%99%E3%82%8B%E8%A8%AD%E5%AE%9A"><i class="fa fa-link"></i></a>コマンドラインから実行のプロセスに対してコアダンプを出力する設定</h1>

<h2>
<span id="プロセスのリソース制限の確認" class="fragment"></span><a href="#%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%AE%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%88%B6%E9%99%90%E3%81%AE%E7%A2%BA%E8%AA%8D"><i class="fa fa-link"></i></a>プロセスのリソース制限の確認</h2>

<ul>
<li>ログインシェルを起動した時の各リソースの確認</li>
<li>core file sizeがコアダンプ出力設定。ここで出力されているのは<strong>SoftLimitの値</strong>。値が0だと出力されない。</li>
</ul>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="c"># ulimit -a</span>
core file size          <span class="o">(</span>blocks, <span class="nt">-c</span><span class="o">)</span> unlimited
data seg size           <span class="o">(</span>kbytes, <span class="nt">-d</span><span class="o">)</span> unlimited
scheduling priority             <span class="o">(</span><span class="nt">-e</span><span class="o">)</span> 0
file size               <span class="o">(</span>blocks, <span class="nt">-f</span><span class="o">)</span> unlimited
pending signals                 <span class="o">(</span><span class="nt">-i</span><span class="o">)</span> 3878
max locked memory       <span class="o">(</span>kbytes, <span class="nt">-l</span><span class="o">)</span> 64
max memory size         <span class="o">(</span>kbytes, <span class="nt">-m</span><span class="o">)</span> unlimited
open files                      <span class="o">(</span><span class="nt">-n</span><span class="o">)</span> 1024
pipe size            <span class="o">(</span>512 bytes, <span class="nt">-p</span><span class="o">)</span> 8
POSIX message queues     <span class="o">(</span>bytes, <span class="nt">-q</span><span class="o">)</span> 819200
real-time priority              <span class="o">(</span><span class="nt">-r</span><span class="o">)</span> 0
stack size              <span class="o">(</span>kbytes, <span class="nt">-s</span><span class="o">)</span> 10240
cpu <span class="nb">time</span>               <span class="o">(</span>seconds, <span class="nt">-t</span><span class="o">)</span> unlimited
max user processes              <span class="o">(</span><span class="nt">-u</span><span class="o">)</span> 3878
virtual memory          <span class="o">(</span>kbytes, <span class="nt">-v</span><span class="o">)</span> unlimited
file locks                      <span class="o">(</span><span class="nt">-x</span><span class="o">)</span> unlimited
</code></pre></div></div>

<h2>
<span id="どうする" class="fragment"></span><a href="#%E3%81%A9%E3%81%86%E3%81%99%E3%82%8B"><i class="fa fa-link"></i></a>どうする</h2>

<ul>
<li>コマンドラインからulimitコマンドでSoftLimit,HardLimtiを設定する。</li>
<li>恒久的に設定する場合は<strong>/etc/security/limits.conf</strong> に設定値を書く。下記参照</li>
</ul>

<h2>
<span id="softlimithardlimitのデフォルト値" class="fragment"></span><a href="#softlimithardlimit%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4"><i class="fa fa-link"></i></a>SoftLimit、HardLimitのデフォルト値</h2>

<ul>
<li>
<strong>/etc/security/limits.conf</strong> に設定値を書く。</li>
<li>
<strong>ログインシェル</strong>、<strong>対話シェル</strong>起動でこのファイルを読み込む。デーモンプロセスは読みこまない。</li>
<li><a href="http://qiita.com/saikoro-steak/items/2e9b177fea202186bd2c" id="reference-17a4400ba3d444b57416">ログインシェルとは</a></li>
</ul>

<div class="code-frame" data-lang="text">
<div class="code-lang"><span class="bold">/etc/security/limits.conf</span></div>
<div class="highlight"><pre><code>・
・
#&lt;domain&gt;      &lt;type&gt;  &lt;item&gt;         &lt;value&gt;
#

#*               soft    core            0
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4
・
・
</code></pre></div>
</div>

<h1>
<span id="os起動時に立上るデーモンプロセスに対して設定する場合" class="fragment"></span><a href="#os%E8%B5%B7%E5%8B%95%E6%99%82%E3%81%AB%E7%AB%8B%E4%B8%8A%E3%82%8B%E3%83%87%E3%83%BC%E3%83%A2%E3%83%B3%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%AB%E5%AF%BE%E3%81%97%E3%81%A6%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B%E5%A0%B4%E5%90%88"><i class="fa fa-link"></i></a>OS起動時に立上るデーモンプロセスに対して設定する場合</h1>

<h2>
<span id="コアダンプ出力できる設定かどうかの確認" class="fragment"></span><a href="#%E3%82%B3%E3%82%A2%E3%83%80%E3%83%B3%E3%83%97%E5%87%BA%E5%8A%9B%E3%81%A7%E3%81%8D%E3%82%8B%E8%A8%AD%E5%AE%9A%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B%E3%81%AE%E7%A2%BA%E8%AA%8D"><i class="fa fa-link"></i></a>コアダンプ出力できる設定かどうかの確認</h2>

<p><strong>Max core file size</strong>の値が0なら出力されない。0の場合、Soft Limitを修正しなければいけない。</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="c"># cat /proc/29500/limits</span>
Limit                     Soft Limit           Hard Limit           Units     
Max cpu <span class="nb">time              </span>unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            10485760             unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max resident <span class="nb">set          </span>unlimited            unlimited            bytes     
Max processes             3878                 3878                 processes 
Max open files            16384                16384                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       3878                 3878                 signals   
Max msgqueue size         819200               819200               bytes     
Max <span class="nb">nice </span>priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime <span class="nb">timeout      </span>unlimited            unlimited            us        

</code></pre></div></div>

<h2>
<span id="softlimitの修正" class="fragment"></span><a href="#softlimit%E3%81%AE%E4%BF%AE%E6%AD%A3"><i class="fa fa-link"></i></a>SoftLimitの修正</h2>

<ul>
<li>OSが起動して各デーモンを<strong>/etc/rc.d/init.d/各スクリプト</strong>から立ち上げる時にSoftLimitを設定している様子</li>
<li>
<strong>/etc/rc.d/init.d/funtcions</strong>にてSoftLimitの設定を有効にしている</li>
<li>
<strong>DAEMON_COREFILE_LIMIT</strong>は通常空なので通常SoftLimitは0(コアダンプ出力しない)設定になっている。functionsとは、起動スクリプトで利用する関数を定義した一覧、でよいのかな？？</li>
</ul>

<div class="code-frame" data-lang="bash">
<div class="code-lang"><span class="bold">/etc/rc.d/funtcions</span></div>
<div class="highlight"><pre><code><span class="c"># -*-Shell-script-*-</span>
<span class="c">#</span>
<span class="c"># functions     This file contains functions to be used by most or all</span>
<span class="c">#               shell scripts in the /etc/init.d directory.</span>
<span class="c">#</span>
・
・
414 ^   <span class="c"># make sure it doesn't core dump anywhere unless requested~</span>
415 ^   <span class="nv">corelimit</span><span class="o">=</span><span class="s2">"ulimit -S -c </span><span class="k">${</span><span class="nv">DAEMON_COREFILE_LIMIT</span><span class="k">:-</span><span class="nv">0</span><span class="k">}</span><span class="s2">"</span>~
</code></pre></div>
</div>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="nv">$ </span><span class="nb">grep</span> <span class="nt">-r</span> DAEMON_COREFILE_LIMIT /etc
/etc/rc.d/init.d/functions:     <span class="nv">corelimit</span><span class="o">=</span><span class="s2">"ulimit -S -c </span><span class="k">${</span><span class="nv">DAEMON_COREFILE_LIMIT</span><span class="k">:-</span><span class="nv">0</span><span class="k">}</span><span class="s2">"</span>
</code></pre></div></div>

<p>httpdの場合<br>
スクリプトの先頭で<strong>/etc/rc.d/init.d/functions</strong>を読み込んでいる</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="c">#!/bin/bash</span>
<span class="c">#</span>
<span class="c"># httpd        Startup script for the Apache HTTP Server</span>
<span class="c">#</span>
<span class="c"># chkconfig: - 85 15</span>
<span class="c"># description: The Apache HTTP Server is an efficient and extensible  \</span>
<span class="c">#              server implementing the current HTTP standards.</span>
<span class="c"># processname: httpd</span>
<span class="c"># config: /etc/httpd/conf/httpd.conf</span>
<span class="c"># config: /etc/sysconfig/httpd</span>
<span class="c"># pidfile: /var/run/httpd/httpd.pid</span>
<span class="c">#</span>
<span class="c">### BEGIN INIT INFO</span>
<span class="c"># Provides: httpd</span>
<span class="c"># Required-Start: $local_fs $remote_fs $network $named</span>
<span class="c"># Required-Stop: $local_fs $remote_fs $network</span>
<span class="c"># Should-Start: distcache</span>
<span class="c"># Short-Description: start and stop Apache HTTP Server</span>
<span class="c"># Description: The Apache HTTP Server is an extensible server </span>
<span class="c">#  implementing the current HTTP standards.</span>
<span class="c">### END INIT INFO</span>

<span class="c"># Source function library.</span>
<span class="nb">.</span> /etc/rc.d/init.d/functions

<span class="k">if</span> <span class="o">[</span> <span class="nt">-f</span> /etc/sysconfig/httpd <span class="o">]</span><span class="p">;</span> <span class="k">then</span>
        <span class="nb">.</span> /etc/sysconfig/httpd
<span class="k">fi</span>
</code></pre></div></div>

<h2>
<span id="どうするか" class="fragment"></span><a href="#%E3%81%A9%E3%81%86%E3%81%99%E3%82%8B%E3%81%8B"><i class="fa fa-link"></i></a>どうするか</h2>

<p>よってコアダンプを出力させるようにするためには例えばfunctionsの前で<strong>DAEMON_COREFILE_LIMIT=unlimited</strong>のような設定を追加したり、各起動スクリプトで<br>
<strong><code>ulimit -S -c unlimited</code></strong>してSoftLimitの上書きをすれば良いはず。実際に前者の方法で上手くコアダンプを出力させることができた。</p>

<h2>
<span id="upstartの場合" class="fragment"></span><a href="#upstart%E3%81%AE%E5%A0%B4%E5%90%88"><i class="fa fa-link"></i></a>upstartの場合</h2>

<p>upsatartを利用するlogstashの場合、limit のフォーマットがありこの箇所で設定すれば上手くコアダンプを出力してくれる。</p>

<div class="code-frame" data-lang="bash">
<div class="code-lang"><span class="bold">/etc/init/logstash.conf</span></div>
<div class="highlight"><pre><code>description     <span class="s2">"logstash"</span>
start on filesystem or runlevel <span class="o">[</span>2345]
stop on runlevel <span class="o">[!</span>2345]

respawn
<span class="nb">umask </span>022
<span class="nb">nice </span>19
limit nofile 16384 16384
<span class="nb">chroot</span> /
chdir /

<span class="c">#limit core &lt;softlimit&gt; &lt;hardlimit&gt;</span>
limit core unlimited unlimited
<span class="c">#limit cpu &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit data &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit fsize &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit memlock &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit msgqueue &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit nice &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit nofile &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit nproc &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit rss &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit rtprio &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit sigpending &lt;softlimit&gt; &lt;hardlimit&gt;</span>
<span class="c">#limit stack &lt;softlimit&gt; &lt;hardlimit&gt;</span>


script
  <span class="o">[</span> <span class="nt">-r</span> <span class="s2">"/etc/default/logstash"</span> <span class="o">]</span> <span class="o">&amp;&amp;</span> <span class="nb">.</span> <span class="s2">"/etc/default/logstash"</span>
  <span class="o">[</span> <span class="nt">-r</span> <span class="s2">"/etc/sysconfig/logstash"</span> <span class="o">]</span> <span class="o">&amp;&amp;</span> <span class="nb">.</span> <span class="s2">"/etc/sysconfig/logstash"</span>
  <span class="nb">exec chroot</span> <span class="nt">--userspec</span> logstash:logstash / /usr/share/logstash/bin/logstash <span class="s2">"--path.settings"</span> <span class="s2">"/etc/logstash"</span> <span class="o">&gt;&gt;</span> /var/log/logstash-stdout.log 2&gt;&gt; /var/log/logstash-stderr.log
end script

</code></pre></div>
</div>

<h2>
<span id="それ以外" class="fragment"></span><a href="#%E3%81%9D%E3%82%8C%E4%BB%A5%E5%A4%96"><i class="fa fa-link"></i></a>それ以外</h2>

<ul>
<li>serviceコマンドやinitctlコマンドで起動しない場合、それ専用の起動シェルスクリプトにulimitコマンドを追加しないといけない。</li>
</ul>

<h2>
<span id="他に" class="fragment"></span><a href="#%E4%BB%96%E3%81%AB"><i class="fa fa-link"></i></a>他に</h2>

<ul>
<li>例えばmysqlだとmysqlの設定ファイルにコアダンプを出力させる設定があったような。各アプリケーションの設定ファイルで各種リソースを制限できるのかも。</li>
</ul>

<h1>
<span id="参考" class="fragment"></span><a href="#%E5%8F%82%E8%80%83"><i class="fa fa-link"></i></a>参考</h1>

<p><a href="http://qiita.com/suzutsuki0220/items/aa84d7e2e8f37e867f3d" class="autolink" id="reference-52e4019b246934cbc279">http://qiita.com/suzutsuki0220/items/aa84d7e2e8f37e867f3d</a><br>
<a href="https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE-Linux%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E6%A7%8B%E7%AF%89%E3%83%BB%E9%81%8B%E7%94%A8%E6%8A%80%E8%A1%93-Software-Design-plus/dp/4774145017/ref=sr_1_2?s=books&amp;ie=UTF8&amp;qid=1494485482&amp;sr=1-2&amp;keywords=%E3%83%97%E3%83%AD%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AElinux%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E6%A7%8B%E7%AF%89+%E9%81%8B%E7%94%A8%E6%8A%80%E8%A1%93" rel="nofollow noopener" target="_blank">プロのためのLinuxシステム構築・運用技術</a></p>


プロセスのコアダンプ出力設定メモ

# 概要
CentOS6.9でSystemTapを使ってみた時の自分メモ。`深く使ったわけでもないので`、使いながら随時更新予定。

# インストール
## 必要なもの
* `kernel-devel`(実行しているカーネルバージョン)
    - インストール方法　→ https://wiki.centos.org/HowTos/I_need_the_Kernel_Source
    - `wget`して`rpm -ivh`する
* `kernel-debuginfo`(実行しているカーネルバージョン)
    - `yum install yum-utils`で`debuginfo-install`コマンドをインストール
    - `debuginfo-install kernel-`uname -r``
    - yumでインストールするとcentos.plusみたいなものがインストールされてしまう
* `kernel-debuginfo-common-arch`(実行しているカーネルバージョン)
    - kernel-debuginfoをインストールで一緒にインストールされる
* gcc
* systemtap

## `kernel-devel`とは
カーネルモジュール.koを作成するために必要なもの。systemtapではカーネルモジュールを作成するので必要になる。

```
Description :
This package provides kernel headers and makefiles sufficient to build modules
against the kernel package.
```

## `kernel-debuginfo`とは
* カーネルのdebug情報。/boot以下のカーネルのマップ情報から得られるものとは異なる？？カーネルモジュール用にまた何かあるのだろうか？

```
Description :
This package provides debug information for package kernel.
This is required to use SystemTap with kernel-2.6.32-642.15.1.el6.x86_64.
```

## インストールの確認
`stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'`
エラーがなければOK


# SystemTapの実行
```bash
sudo stap -v ファイル.stp
```
* -vをつけてることでどこまで実行されたのかを確認したほうがよい。`-e`でワンライナーでも実行できる。
* `/usr/share/systemtap/tapset`に沢山のサンプルがある

# SystemTap書式
各プローブ(測定ポイント)を以下の様に指定する。プローブで指定したカーネル関数などのプローブポイントが呼び出されたタイミングで{}の中を実行して観測できる。`プローブ.return`でそのプローブポイントが終了するタイミングで呼べる。

```c
probe プローブ {statements}
```
下の場合だと、カーネル関数の`sys_sync`が呼び出された時に{}の中が実行される。

```c
global count=0

probe kernel.function("sys_sync") {
  count++
  printf( "sys_sync called %d times, currently by pid %d\n", count, pid );
}
```

# プローブポイント一覧
`stap -L`でポイントの一覧が確認できる。

```bash

# VFSのfile_operationイベントのブローブポイント一覧
stap -L vfs.*
# カーネル関数のブローブポイント一覧
stap -L 'kernel.function("*")'
#静的ブローブポイント一覧
stap -L 'kernel.trace("*")'
#モジュール内の関数のプローブポイント一覧
stap -L 'module("*").function("*")'
```
* 例
    - vfsでは下記の関数とその関数に関して利用できる型がある

```bash

$ stap -L vfs.*
vfs.__set_page_dirty_buffers dev:long devname:string ino:long index:long name:string argstr:string size:long units:string $page:struct page*
vfs.add_to_page_cache dev:long devname:string ino:long index:long nrpages:long size:long units:string name:string argstr:string $page:struct page* $mapping:struct address_space* $offset:long unsigned int $gfp_mask:gfp_t
vfs.block_sync_page dev:long devname:string ino:long index:long name:string argstr:string size:long units:string $page:struct page*
vfs.buffer_migrate_page dev:long ino:long devname:string index:long name:string argstr:string size:long units:string $mapping:struct address_space* $newpage:struct page* $page:struct page*
vfs.do_mpage_readpage dev:long devname:string ino:long index:long name:string argstr:string size:long units:string $bio:struct bio* $page:struct page* $nr_pages:unsigned int $last_block_in_bio:sector_t* $map_bh:struct buffer_head* $first_logical_block:long unsigned int* $get_block:get_block_t* $blocks:sector_t[]
vfs.do_sync_read dev:long devname:string ino:long file:long len:long pos:long buf:long name:string argstr:string size:long units:string bytes_to_read:long $filp:struct file* $buf:char* $len:size_t $ppos:loff_t* $iov:struct iovec $kiocb:struct kiocb
vfs.do_sync_write dev:long devname:string ino:long file:long len:long pos:long buf:long bytes_to_write:long name:string argstr:string size:long units:string $filp:struct file* $buf:char const* $len:size_t $ppos:loff_t* $iov:struct iovec $kiocb:struct kiocb
vfs.read file:long pos:long buf:long bytes_to_read:long dev:long devname:string ino:long name:string argstr:string $file:struct file* $buf:char* $count:size_t $pos:loff_t*
vfs.readv file:long dev:long devname:string ino:long pos:long vec:long vlen:long bytes_to_read:long name:string argstr:string $file:struct file* $vec:struct iovec const* $vlen:long unsigned int $pos:loff_t*
vfs.remove_from_page_cache dev:long devname:string ino:long index:long name:string argstr:string $page:struct page*
vfs.write file:long pos:long buf:long bytes_to_write:long dev:long devname:string ino:long name:string argstr:string $file:struct file* $buf:char const* $count:size_t $pos:loff_t*
vfs.writev file:long dev:long devname:string ino:long pos:long vlen:long vec:long bytes_to_write:long name:string argstr:string $file:struct file* $vec:struct iovec const* $vlen:long unsigned int $pos:loff_t*
```

# SystemTapの仕組み
https://www.ibm.com/developerworks/jp/linux/library/l-systemtap/
↑より
Kprobe はアーキテクチャーに特化されており、**プローブ対象の命令の先頭バイトにブレークポイント命令を挿入します。ブレークポイント命令にヒットするとプローブ固有のハンドラーが実行され、それが完了すると本来の命令の実行が (ブレークポイントから) 再開され、実行が継続されます。**
Kretprobe の場合は多少異なり、呼び出された関数から戻ってきた時点で動作します。関数には複数のリターン・ポイントがある場合もあるため、複雑なことのように思えますが、Kretprobe が実際に使用するのはトランポリン (trampoline) という単純な手法です。この手法では、関数のすべてのリターン・ポイントを計測するのではなく (これでは、すべての事例をキャッチできません)、わずかな量のコードを関数の入り口に追加します。**このコードはスタックのリターン・アドレスをトランポリン・アドレス、つまり Kretprobe のアドレスに置き換えます。そのため関数の実行が終了すると、呼び出し側に制御が返される代わりに、Kretprobe が呼び出されます。そして呼び出された Kretprobe がその機能を実行した後、実際に関数を呼び出した側に制御を返すという仕組みです。**




## 5 つの動作フェーズ
```
開始
↓
スクリプトを解析ツリーに変換 (pass 1)
↓
シンボル情報を使用してシンボルを解決(pass 2)
↓
解析ツリーを C ソースに変換(pass 3)
tapset スクリプト (SystemTap で定義された便利な機能を集めたライブラリー) も使用
↓
カーネル・モジュールの作成(pass 4)
↓
staprun と stapio
カーネルへのモジュールのインストールを管理し、その出力を stdout にルーティングします (pass 5)
↓
終了
(シェルで Ctrl-C が押された場合や、スクリプトが終了した場合は、クリーンアップ・プロセスによってモジュールがアンロードされ、その結果、関連するすべてのユーティリティーが終了)
```



# Systemtap使ってみた
## カーネルスタックの計測
* もっとも頻繁にカーネルスタックの値が同じである回数を知ることができ、頻繁に実行されているカーネルスタックの中身は何かがわかる

```c:kernelstack.stp
global s;

probe timer.profile{
    # 現在のカーネルスタックの16 進バックトレース
    if (execname() == "java")
        s[backtrace()] <<< 1
}
probe end{
    foreach(i in s+){
        # スタック番地からカーネルスタックの中身を出力
        print_stack(i)
        printf("\n\t%d\n",@count(s[i]))
    }
}
```

結果

```bash
 0xffffffff811b551a : __d_lookup+0x9a/0x150 [kernel]

        1
 0xffffffff810198db : syscall_trace_enter+0x16b/0x1e0 [kernel]

        2
 0xffffffff8111a6bf : prof_syscall_enter+0x1bf/0x270 [kernel]

        2
 0xffffffff810682ff : finish_task_switch+0x4f/0xf0 [kernel]

        11
 0xffffffffa12a407c : 0xffffffffa12a407c [stap_827021213c17f52ed8777c332d91e694_6260+0x807c/0x0]
 0xffffffffa12a57d3 : 0xffffffffa12a57d3 [stap_827021213c17f52ed8777c332d91e694_6260+0x97d3/0x0]
 0xffffffffa12a700e : 0xffffffffa12a700e [stap_827021213c17f52ed8777c332d91e694_6260+0xb00e/0x0]
 0xffffffff810b0d49 : profile_tick+0x99/0xa0 [kernel]
 0xffffffff810b8a50 : tick_sched_timer+0x70/0xc0 [kernel]
 0xffffffff810ab12e : __run_hrtimer+0x8e/0x1d0 [kernel]
 0xffffffff810ab4ce : hrtimer_interrupt+0xee/0x270 [kernel]
 0xffffffff8103879d : local_apic_timer_interrupt+0x3d/0x70 [kernel]
 0xffffffff81552f55 : smp_apic_timer_interrupt+0x45/0x60 [kernel]
 0xffffffff8100bc13 : apic_timer_interrupt+0x13/0x20 [kernel]
 0xcf9b000000ffff : 0xcf9b000000ffff

        128
```
## カーネル関数のコールグラフ

```c:kernelfunction-callgraph.stp
probe module("ext4").function("*").call
{
  if (execname() == "java")
  printf ("%s -> %s\n", thread_indent(1), probefunc())
}
probe module("ext4").function("*").return
{
  if (execname() == "java")
  printf ("%s <- %s\n", thread_indent(-1), probefunc())
}
```
結果

```bash
     0 java(3926): -> ext4_readdir
    10 java(3926):  -> free_rb_tree_fname
    15 java(3926):  <- ext4_readdir
    18 java(3926):  -> ext4_htree_fill_tree
    25 java(3926):   -> htree_dirblock_to_tree
    31 java(3926):    -> ext4_bread
    37 java(3926):     -> ext4_getblk
    43 java(3926):      -> ext4_get_blocks
    50 java(3926):       -> ext4_ext_get_blocks
    56 java(3926):       <- ext4_get_blocks
    60 java(3926):       -> ext4_data_block_valid
    67 java(3926):       <- ext4_get_blocks
    68 java(3926):      <- ext4_getblk
    74 java(3926):     <- ext4_bread
    76 java(3926):    <- htree_dirblock_to_tree
    79 java(3926):    -> ext4_check_dir_entry
    84 java(3926):    <- htree_dirblock_to_tree
    88 java(3926):    -> ext4fs_dirhash
    96 java(3926):     -> str2hashbuf_signed
   101 java(3926):     <- ext4fs_dirhash
   103 java(3926):    <- htree_dirblock_to_tree
   105 java(3926):    -> ext4_htree_store_dirent
   111 java(3926):    <- htree_dirblock_to_tree
   113 java(3926):    -> ext4_check_dir_entry
   115 java(3926):    <- htree_dirblock_to_tree
   117 java(3926):    -> ext4fs_dirhash
   119 java(3926):     -> str2hashbuf_signed
   121 java(3926):     <- ext4fs_dirhash
   122 java(3926):    <- htree_dirblock_to_tree
   124 java(3926):    -> ext4_htree_store_dirent
   127 java(3926):    <- htree_dirblock_to_tree
   128 java(3926):   <- ext4_htree_fill_tree
   130 java(3926):  <- ext4_readdir
   132 java(3926):  -> call_filldir
   137 java(3926):  <- ext4_readdir
   139 java(3926):  -> call_filldir
   141 java(3926):  <- ext4_readdir
   142 java(3926): <- vfs_readdir
```

# メモ
## ユーザー空間
* カーネル3.5以上だとユーザー空間もプローブできる。

## 関数でグローバルな変数へのアクセス
```
When a target variable is not local to the probe point, like a global external variable or a file local static variable defined in another file then it can be referenced through
```
```c
“@var("変数名@src/file.c")”.
```

## 構造体へのアクセス
```c
@var("変数名@src/file.c")->構造体メンバ
```

これで外部変数に入っている構造体のメンバにもアクセスできる

## キャスティング
* コードの中ではvoidのポインタかも、型情報は使えないかも
* プローブハンドラの中では型情報は使えるが、stapの中で自分で作成した関数では使えない。
* その関数の中では。ポインタはlong型を使うようになっている

よって
### @cast() operator
* 第一引数
    - ポインター
* 第二引数
    - キャストしたい型
* 第三引数(オプション４)
    - キャストしたい型が定義してあるファイル

```c
function task_state:long (task:long)
{
 return @cast(task, "task_struct", "kernel<linux/sched.h>")->state
}
```
これでtask_struct task->stateでアクセスできる


# まとめ
* カーネルスタックの値を動的に見れたのは初めてだった
* 本格的に使っていないのでなんともですが、perfコマンドやOSのコマンドである程度調査はできそう。
* SystemTapを使いながら内部の挙動に詳しくなる

# 参考
* https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html-single/SystemTap_Beginners_Guide/index.html#scripts
* https://www.ibm.com/developerworks/jp/linux/library/l-systemtap/
* https://sourceware.org/systemtap/
* https://sourceware.org/systemtap/SystemTap_Beginners_Guide.pdf


SystemTap使ってみた

# 概要
CentOSでシステムのボトルネックを調査する時の問題切り分け方法の自分メモ。

## 前提
* カーネルモードでCPUが使われるのは、`割り込み`、`システムコール`、`カーネルスレッド`

## ロードアベレージとは
* CPUの実行権限が与えられているのを待っているタスク
* ディスクI/Oが完了するのを待っているタスクの

**２つの状態のプロセスの数**


# 切り分けフロー
- LA高いか？
  * 低い 
      - ネットワークなどがボトルネックになっているかも。**muninなど、NWに関するグラフを見ると帯域が圧迫しているなどありえる**
      - OSの設定などがボトルネック。カーネルのsynパケットの受付数が低いなど。
      - **アプリケーション、OSのログ、各種ログを見ることが大事** 

↓
LA高い場合

- vmstatで負荷の特徴把握
↓

- CPU負荷 or IO負荷 どちらか
  * cpu負荷: us列, sy列 が高い
  * IO負荷: b列をみる。IO列は低くてもIOが高い場合がるので注意
  
↓

+ CPU負荷の場合
    + システム空間での負荷(system列多い)
        - 割り込み調査
        - システムコール調査
        - カーネルスレッド調査
    + ユーザー空間での負荷(user列多い)
        - アプリケーション調査
+ IO負荷の場合
    + スワップ
        - メモリ沢山使用しているプロセスを調査
    + IO量
        - iostatでボトルネックがディスクなのか、ディスクより上のシステムコール層、VFS層、ファイルシステム層なのかを調査

## 詳細
## LAが高いか？
* `uptime`,`sar -q 1`などでLAを把握

## vmstat、その前に
* `mpstat -P ALL 1`などで各コアでの状況を確認したほうがよい。コアで分散すれば解決するような問題もある。
* システムログも大事(dmesg | tail)
    - oomkillerやパケットのエラーなどでている場合がある様子。エラーは使用率や飽和などを端的に表しているのでやはりログのエラーは大事。

## vmstatで負荷の特徴を把握する
* `vmstat -S m 1`

```sh
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0     17   5064    275    204    0    0     3   154   11   16  0  1 96  3  0 
 0  0     17   5064    275    204    0    0     0   580 1255  329  1  2 87 10  0
```

## 特徴無し
* muninなども含めてシステムに異常がない場合は、監視の閾値上げても良いかも


## waが高い
* IO負荷調査へ

## syとwaが高い
* IO負荷調査へ

## syだけ高い場合(システム空間での負荷)
- `top`などでどのプロセスがCPUを使っているか特定しておく
- waが小さくてもIO負荷ありえるので、IO負荷もありうる。[IO待ちメモ](http://qiita.com/saikoro-steak/items/244362bcceec4df19343)
    - システムの他の箇所(前提より、`割り込み`、`システムコール`、`カーネルスレッド`)のどれかでCPU沢山使っている
        - 割り込み調査
            - `vmstat`のcs,inが多い
            - `systemtap`、`perf`で割り込みの種類を特定する。その割り込み毎に対応する。
        - システムコール調査
            - `strace -c -tttT -p` してシステムコールのレイテンシ、頻度を計測。怪しいシステムコールを把握する。
            - システムコールの先を`systemtap`、`perf`で調査。関数まで特定する。カーネルソース読んで静的解析。
        - カーネルスレッド調査
            - `systemtap`,`perf`で調査。関数まで特定する。カーネルソース読んで静的解析。

## us高い(ユーザー空間での負荷)
* プロセスのログをみる。apacheならアクセスログなど、変なIPなどないかなどなど。
* `top`などでどのプロセスがCPUを使っているか特定してして`psatck`を何回か打ってユーザースタックを確認することでアプリケーションがどの処理で何をしているのかを把握する。ただアプリケーションのシンボル情報がない場合が多いはずなので関数名は16進数表示になっているかも。カーネルの関数やなぜか共有ライブラリの関数はわかるはずなのでそこからなんとかする


# IO負荷高い場合
## スワップを疑う
* `vmstatの`swpd、`free`でスワップの状況を把握
* メモリを消費しているプロセス特定
    - `ps aux --sort -rss`

## IO量が多いかどうか
* `iostat`で調査
    - IOPS(r/s + w/s)が増え、await(1回のI/Oに要する時間)が増える、(avgqu-sz)キューも増えている場合
        + IOが増えた原因はなにかを調査する必要あり
            * `iotop`でプロセス特定
            * アクセスログ、重いクエリ、などなどアプリの観点で調査
    -  平均 I/O サイズ(avgrq-sz)が変わらないのにサービスタイム、1回のI/Oに要する時間 (ミリ秒)(svctm)が大きくなった場合
        +   I/O性能が劣化しており、ストレージに問題がありそう
    - ストレージがボトルネックになっていない場合
        + それより上のシステムコール層、VFS層、ファイルシステム層を調査
            * `strace -cttT -p`でIOに関するシステムコールのレイテンシを測定。時間が通常よりかかっていればディスクより上層が怪しい。レイテンシが小さいのであればストレージもそれより上層も怪しくない。
            * ここでも深く調べるには`systemtap`,`perf`。そう、カーネルソースまで追ってボトルネックになっている関数を特定する。

iostatのカラムの見方

http://d.hatena.ne.jp/yohei-a/20110711/1310396665

```
r/s: 秒間の読み込み回数
w/s: 秒間の書き込み回数
avgrq-sz: 平均 I/O サイズ
avgqu-sz: 平均待ち行列長
await: レスポンスタイム。I/O を実施していない待ち時間を含む。
svctm: サービスタイム。1回のI/Oに要する時間 (ミリ秒)。
%util: 使用率（ビジー率）
```


# メモ
## IOのレスポンスが悪いかどうか
* iotopなどで怪しいプロセスを発見、`strace -cttT -p` してIO関連システムコールのレイテンシを計測する。
* レイテンシが大きかったらiostatでどこがボトルネックになっているのはディスクなのか、それより上位なのか切り分ける。最初からiostatで切り分ければよいのかも

## VFS層、ブロック層
```
システムコール
　　↓
---------------------------------------------
(VFSレイヤー)
　VFS
　　↓
ファイルシステム ←　→ ディスクキャッシュ
---------------------------------------------
  　↓
---------------------------------------------
(ブロックレイヤー)
IOスケジューラ　→　デバイスドライバ
---------------------------------------------
　　　　　　　　　　　　　↓
　　　　　　　　ディスクコントローラ
　　　　　　　　　　　　　↓
　　　　　　　　　　 物理ディスク
```



# まとめ
* システム空間で負荷がある場合、深く調べるには上記で度々できているsystemtap、perfなどのLinuxツールでボトルネックになっている関数まで特定するしかなさそう。そしてソースを呼んで静的に解析。対策実施。
* 自分で根本原因まで特定しようとしたいならば、最後はカーネルソースに辿り着くことがありそう。そして、システムの状況とコードを結びつけてなんとか原因を推定してチューニングを実施する。自分でここまでできるのがオープンソースのよいところ。
* [perf使ってみた](http://qiita.com/saikoro-steak/items/bf066241eeef1141ef5f)

# 参考
* https://yakst.com/ja/posts/3601?platform=hootsuite
* http://d.hatena.ne.jp/yohei-a/20110711/1310396665
* http://d.hatena.ne.jp/yohei-a/20121030/1351561743





<h1>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h1>

<p>CentOSでシステムのボトルネックを調査する時の問題切り分け方法の自分メモ。</p>

<h2>
<span id="前提" class="fragment"></span><a href="#%E5%89%8D%E6%8F%90"><i class="fa fa-link"></i></a>前提</h2>

<ul>
<li>カーネルモードでCPUが使われるのは、<code>割り込み</code>、<code>システムコール</code>、<code>カーネルスレッド</code>
</li>
</ul>

<h2>
<span id="ロードアベレージとは" class="fragment"></span><a href="#%E3%83%AD%E3%83%BC%E3%83%89%E3%82%A2%E3%83%99%E3%83%AC%E3%83%BC%E3%82%B8%E3%81%A8%E3%81%AF"><i class="fa fa-link"></i></a>ロードアベレージとは</h2>

<ul>
<li>CPUの実行権限が与えられているのを待っているタスク</li>
<li>ディスクI/Oが完了するのを待っているタスクの</li>
</ul>

<p><strong>２つの状態のプロセスの数</strong></p>

<h1>
<span id="切り分けフロー" class="fragment"></span><a href="#%E5%88%87%E3%82%8A%E5%88%86%E3%81%91%E3%83%95%E3%83%AD%E3%83%BC"><i class="fa fa-link"></i></a>切り分けフロー</h1>

<ul>
<li>LA高いか？

<ul>
<li>低い 

<ul>
<li>ネットワークなどがボトルネックになっているかも。<strong>muninなど、NWに関するグラフを見ると帯域が圧迫しているなどありえる</strong>
</li>
<li>OSの設定などがボトルネック。カーネルのsynパケットの受付数が低いなど。</li>
<li>
<strong>アプリケーション、OSのログ、各種ログを見ることが大事</strong> </li>
</ul>
</li>
</ul>
</li>
</ul>

<p>↓<br>
LA高い場合</p>

<ul>
<li><p>vmstatで負荷の特徴把握<br>
↓</p></li>
<li>
<p>CPU負荷 or IO負荷 どちらか</p>

<ul>
<li>cpu負荷: us列, sy列 が高い</li>
<li>IO負荷: b列をみる。IO列は低くてもIOが高い場合がるので注意</li>
</ul>
</li>
</ul>

<p>↓</p>

<ul>
<li>CPU負荷の場合

<ul>
<li>システム空間での負荷(system列多い)

<ul>
<li>割り込み調査</li>
<li>システムコール調査</li>
<li>カーネルスレッド調査</li>
</ul>
</li>
<li>ユーザー空間での負荷(user列多い)

<ul>
<li>アプリケーション調査</li>
</ul>
</li>
</ul>
</li>
<li>IO負荷の場合

<ul>
<li>スワップ

<ul>
<li>メモリ沢山使用しているプロセスを調査</li>
</ul>
</li>
<li>IO量

<ul>
<li>iostatでボトルネックがディスクなのか、ディスクより上のシステムコール層、VFS層、ファイルシステム層なのかを調査</li>
</ul>
</li>
</ul>
</li>
</ul>

<h2>
<span id="詳細" class="fragment"></span><a href="#%E8%A9%B3%E7%B4%B0"><i class="fa fa-link"></i></a>詳細</h2>

<h2>
<span id="laが高いか" class="fragment"></span><a href="#la%E3%81%8C%E9%AB%98%E3%81%84%E3%81%8B"><i class="fa fa-link"></i></a>LAが高いか？</h2>

<ul>
<li>
<code>uptime</code>,<code>sar -q 1</code>などでLAを把握</li>
</ul>

<h2>
<span id="vmstatその前に" class="fragment"></span><a href="#vmstat%E3%81%9D%E3%81%AE%E5%89%8D%E3%81%AB"><i class="fa fa-link"></i></a>vmstat、その前に</h2>

<ul>
<li>
<code>mpstat -P ALL 1</code>などで各コアでの状況を確認したほうがよい。コアで分散すれば解決するような問題もある。</li>
<li>システムログも大事(dmesg | tail)

<ul>
<li>oomkillerやパケットのエラーなどでている場合がある様子。エラーは使用率や飽和などを端的に表しているのでやはりログのエラーは大事。</li>
</ul>
</li>
</ul>

<h2>
<span id="vmstatで負荷の特徴を把握する" class="fragment"></span><a href="#vmstat%E3%81%A7%E8%B2%A0%E8%8D%B7%E3%81%AE%E7%89%B9%E5%BE%B4%E3%82%92%E6%8A%8A%E6%8F%A1%E3%81%99%E3%82%8B"><i class="fa fa-link"></i></a>vmstatで負荷の特徴を把握する</h2>

<ul>
<li><code>vmstat -S m 1</code></li>
</ul>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>procs <span class="nt">-----------memory----------</span> <span class="nt">---swap--</span> <span class="nt">-----io----</span> <span class="nt">--system--</span> <span class="nt">-----cpu-----</span>
 r  b   swpd   free   buff  cache   si   so    bi    bo   <span class="k">in   </span>cs us sy <span class="nb">id </span>wa st
 0  0     17   5064    275    204    0    0     3   154   11   16  0  1 96  3  0 
 0  0     17   5064    275    204    0    0     0   580 1255  329  1  2 87 10  0
</code></pre></div></div>

<h2>
<span id="特徴無し" class="fragment"></span><a href="#%E7%89%B9%E5%BE%B4%E7%84%A1%E3%81%97"><i class="fa fa-link"></i></a>特徴無し</h2>

<ul>
<li>muninなども含めてシステムに異常がない場合は、監視の閾値上げても良いかも</li>
</ul>

<h2>
<span id="waが高い" class="fragment"></span><a href="#wa%E3%81%8C%E9%AB%98%E3%81%84"><i class="fa fa-link"></i></a>waが高い</h2>

<ul>
<li>IO負荷調査へ</li>
</ul>

<h2>
<span id="syとwaが高い" class="fragment"></span><a href="#sy%E3%81%A8wa%E3%81%8C%E9%AB%98%E3%81%84"><i class="fa fa-link"></i></a>syとwaが高い</h2>

<ul>
<li>IO負荷調査へ</li>
</ul>

<h2>
<span id="syだけ高い場合システム空間での負荷" class="fragment"></span><a href="#sy%E3%81%A0%E3%81%91%E9%AB%98%E3%81%84%E5%A0%B4%E5%90%88%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E7%A9%BA%E9%96%93%E3%81%A7%E3%81%AE%E8%B2%A0%E8%8D%B7"><i class="fa fa-link"></i></a>syだけ高い場合(システム空間での負荷)</h2>

<ul>
<li>
<code>top</code>などでどのプロセスがCPUを使っているか特定しておく</li>
<li>waが小さくてもIO負荷ありえるので、IO負荷もありうる。<a href="http://qiita.com/saikoro-steak/items/244362bcceec4df19343" id="reference-126384302dd0632c1402">IO待ちメモ</a>

<ul>
<li>システムの他の箇所(前提より、<code>割り込み</code>、<code>システムコール</code>、<code>カーネルスレッド</code>)のどれかでCPU沢山使っている

<ul>
<li>割り込み調査

<ul>
<li>
<code>vmstat</code>のcs,inが多い</li>
<li>
<code>systemtap</code>、<code>perf</code>で割り込みの種類を特定する。その割り込み毎に対応する。</li>
</ul>
</li>
<li>システムコール調査

<ul>
<li>
<code>strace -c -tttT -p</code> してシステムコールのレイテンシ、頻度を計測。怪しいシステムコールを把握する。</li>
<li>システムコールの先を<code>systemtap</code>、<code>perf</code>で調査。関数まで特定する。カーネルソース読んで静的解析。</li>
</ul>
</li>
<li>カーネルスレッド調査

<ul>
<li>
<code>systemtap</code>,<code>perf</code>で調査。関数まで特定する。カーネルソース読んで静的解析。</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>

<h2>
<span id="us高いユーザー空間での負荷" class="fragment"></span><a href="#us%E9%AB%98%E3%81%84%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E7%A9%BA%E9%96%93%E3%81%A7%E3%81%AE%E8%B2%A0%E8%8D%B7"><i class="fa fa-link"></i></a>us高い(ユーザー空間での負荷)</h2>

<ul>
<li>プロセスのログをみる。apacheならアクセスログなど、変なIPなどないかなどなど。</li>
<li>
<code>top</code>などでどのプロセスがCPUを使っているか特定してして<code>psatck</code>を何回か打ってユーザースタックを確認することでアプリケーションがどの処理で何をしているのかを把握する。ただアプリケーションのシンボル情報がない場合が多いはずなので関数名は16進数表示になっているかも。カーネルの関数やなぜか共有ライブラリの関数はわかるはずなのでそこからなんとかする</li>
</ul>

<h1>
<span id="io負荷高い場合" class="fragment"></span><a href="#io%E8%B2%A0%E8%8D%B7%E9%AB%98%E3%81%84%E5%A0%B4%E5%90%88"><i class="fa fa-link"></i></a>IO負荷高い場合</h1>

<h2>
<span id="スワップを疑う" class="fragment"></span><a href="#%E3%82%B9%E3%83%AF%E3%83%83%E3%83%97%E3%82%92%E7%96%91%E3%81%86"><i class="fa fa-link"></i></a>スワップを疑う</h2>

<ul>
<li>
<code>vmstatの</code>swpd、<code>free</code>でスワップの状況を把握</li>
<li>メモリを消費しているプロセス特定

<ul>
<li><code>ps aux --sort -rss</code></li>
</ul>
</li>
</ul>

<h2>
<span id="io量が多いかどうか" class="fragment"></span><a href="#io%E9%87%8F%E3%81%8C%E5%A4%9A%E3%81%84%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B"><i class="fa fa-link"></i></a>IO量が多いかどうか</h2>

<ul>
<li>
<code>iostat</code>で調査

<ul>
<li>IOPS(r/s + w/s)が増え、await(1回のI/Oに要する時間)が増える、(avgqu-sz)キューも増えている場合

<ul>
<li>IOが増えた原因はなにかを調査する必要あり

<ul>
<li>
<code>iotop</code>でプロセス特定</li>
<li>アクセスログ、重いクエリ、などなどアプリの観点で調査</li>
</ul>
</li>
</ul>
</li>
<li> 平均 I/O サイズ(avgrq-sz)が変わらないのにサービスタイム、1回のI/Oに要する時間 (ミリ秒)(svctm)が大きくなった場合

<ul>
<li>  I/O性能が劣化しており、ストレージに問題がありそう</li>
</ul>
</li>
<li>ストレージがボトルネックになっていない場合

<ul>
<li>それより上のシステムコール層、VFS層、ファイルシステム層を調査

<ul>
<li>
<code>strace -cttT -p</code>でIOに関するシステムコールのレイテンシを測定。時間が通常よりかかっていればディスクより上層が怪しい。レイテンシが小さいのであればストレージもそれより上層も怪しくない。</li>
<li>ここでも深く調べるには<code>systemtap</code>,<code>perf</code>。そう、カーネルソースまで追ってボトルネックになっている関数を特定する。</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>

<p>iostatのカラムの見方</p>

<p><qiita-embed-ogp src="http://d.hatena.ne.jp/yohei-a/20110711/1310396665"></qiita-embed-ogp></p>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>r/s: 秒間の読み込み回数
w/s: 秒間の書き込み回数
avgrq-sz: 平均 I/O サイズ
avgqu-sz: 平均待ち行列長
await: レスポンスタイム。I/O を実施していない待ち時間を含む。
svctm: サービスタイム。1回のI/Oに要する時間 (ミリ秒)。
%util: 使用率（ビジー率）
</code></pre></div></div>

<h1>
<span id="メモ" class="fragment"></span><a href="#%E3%83%A1%E3%83%A2"><i class="fa fa-link"></i></a>メモ</h1>

<h2>
<span id="ioのレスポンスが悪いかどうか" class="fragment"></span><a href="#io%E3%81%AE%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B9%E3%81%8C%E6%82%AA%E3%81%84%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B"><i class="fa fa-link"></i></a>IOのレスポンスが悪いかどうか</h2>

<ul>
<li>iotopなどで怪しいプロセスを発見、<code>strace -cttT -p</code> してIO関連システムコールのレイテンシを計測する。</li>
<li>レイテンシが大きかったらiostatでどこがボトルネックになっているのはディスクなのか、それより上位なのか切り分ける。最初からiostatで切り分ければよいのかも</li>
</ul>

<h2>
<span id="vfs層ブロック層" class="fragment"></span><a href="#vfs%E5%B1%A4%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E5%B1%A4"><i class="fa fa-link"></i></a>VFS層、ブロック層</h2>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>システムコール
　　↓
---------------------------------------------
(VFSレイヤー)
　VFS
　　↓
ファイルシステム ←　→ ディスクキャッシュ
---------------------------------------------
  　↓
---------------------------------------------
(ブロックレイヤー)
IOスケジューラ　→　デバイスドライバ
---------------------------------------------
　　　　　　　　　　　　　↓
　　　　　　　　ディスクコントローラ
　　　　　　　　　　　　　↓
　　　　　　　　　　 物理ディスク
</code></pre></div></div>

<h1>
<span id="まとめ" class="fragment"></span><a href="#%E3%81%BE%E3%81%A8%E3%82%81"><i class="fa fa-link"></i></a>まとめ</h1>

<ul>
<li>システム空間で負荷がある場合、深く調べるには上記で度々できているsystemtap、perfなどのLinuxツールでボトルネックになっている関数まで特定するしかなさそう。そしてソースを呼んで静的に解析。対策実施。</li>
<li>自分で根本原因まで特定しようとしたいならば、最後はカーネルソースに辿り着くことがありそう。そして、システムの状況とコードを結びつけてなんとか原因を推定してチューニングを実施する。自分でここまでできるのがオープンソースのよいところ。</li>
<li><a href="http://qiita.com/saikoro-steak/items/bf066241eeef1141ef5f" id="reference-440fa3f6b8621197eb69">perf使ってみた</a></li>
</ul>

<h1>
<span id="参考" class="fragment"></span><a href="#%E5%8F%82%E8%80%83"><i class="fa fa-link"></i></a>参考</h1>

<ul>
<li><a href="https://yakst.com/ja/posts/3601?platform=hootsuite" class="autolink" rel="nofollow noopener" target="_blank">https://yakst.com/ja/posts/3601?platform=hootsuite</a></li>
<li><a href="http://d.hatena.ne.jp/yohei-a/20110711/1310396665" class="autolink" rel="nofollow noopener" target="_blank">http://d.hatena.ne.jp/yohei-a/20110711/1310396665</a></li>
<li><a href="http://d.hatena.ne.jp/yohei-a/20121030/1351561743" class="autolink" rel="nofollow noopener" target="_blank">http://d.hatena.ne.jp/yohei-a/20121030/1351561743</a></li>
</ul>


システム負荷切り分け自分メモ

# 概要
CentOS6.9でperfコマンドを使ってみたメモ

# 参考
* [Linux Performance](http://www.brendangregg.com/linuxperf.html)
* [perf Examples](http://www.brendangregg.com/perf.html)
* [perf-tools](https://github.com/brendangregg/perf-tools)
* [perf wiki](https://perf.wiki.kernel.org/index.php/Main_Page)
* [Systems Performance: Enterprise and the Cloud](https://www.amazon.co.jp/Systems-Performance-Enterprise-Brendan-Gregg/dp/0133390098/ref=sr_1_sc_1?s=books&ie=UTF8&qid=1492582490&sr=8-1-spell&keywords=systemperformance)

# perf is 何
* Performance analysis tools for Linux
* 参考のリンクがとても詳しい

# なぜ使うのか
システムコールから先のカーネルのどこでボトルネックになっているかなどを知りたい場合

# 導入
yumでサクッとインストールできる。

```sh
yum install perf
```

# 使い方
* プロファイルの実行
    - `perf record -ag`

* 結果を保存
* 結果の確認
    - `perf report -g -G --stdio`

# コマンド
perf [サブコマンド]


# サブコマンド
```sh
perf-stat(1), perf-top(1), perf-record(1), perf-report(1), perf-list(1)
```
`man perf-サブコマンド`でmanが見れる

# コマンド使ってみる
## perf top
* 関数単位でcpu使用率を閲覧
* 共有ライブラリのシンボルは16進数で読めない。`kernel-debuginfo`などインストールしていないがカーネルシンボルが読める。共有ライブラリもシンボルが見れるものがある、なぜでしょうか＞＜？？？？？

```sh
Samples: 72K of event 'cpu-clock', Event count (approx.): 2471353254
Overhead  Shared Object             Symbol
   3.76%  [kernel]                  [k] find_vma
   3.56%  [kernel]                  [k] __d_lookup
   2.44%  [kernel]                  [k] avc_has_perm_noaudit
   2.42%  [kernel]                  [k] __link_path_walk
   2.39%  libjvm.so                 [.] 0x00000000004743a3
   1.89%  [kernel]                  [k] prof_syscall_enter
   1.72%  [kernel]                  [k] inode_has_perm
   1.64%  libc-2.12.so              [.] mkfifo
   1.34%  [kernel]                  [k] selinux_inode_permission
   1.23%  [kernel]                  [k] finish_task_switch
   1.04%  [kernel]                  [k] kmem_cache_alloc
   0.87%  [kernel]                  [k] system_call
   0.84%  [kernel]                  [k] syscall_trace_enter
   0.80%  [kernel]                  [k] strncpy_from_user
   0.74%  [kernel]                  [k] __do_softirq
   0.66%  [kernel]                  [k] acl_permission_check
   0.61%  [kernel]                  [k] do_lookup
   0.54%  libjvm.so                 [.] 0x000000000065af65
   0.53%  libc-2.12.so              [.] memcpy
   0.51%  [kernel]                  [k] follow_managed
   0.47%  [kernel]                  [k] audit_syscall_entry
   0.44%  libjvm.so                 [.] 0x00000000009ff88c
   0.43%  [kernel]                  [k] dput
   0.43%  libjvm.so                 [.] 0x00000000006c1c56
   0.42%  [kernel]                  [k] _atomic_dec_and_lock
   0.41%  perf                      [.] hists__output_resort
   0.41%  libjvm.so                 [.] 0x000000000032ef1e
```

## perf list
* 調査可能なイベント一覧
* 出力されたイベントは他のサブコマンドの-eオプションで指定できる

```
# perf list | more

List of pre-defined events (to be used in -e):

  alignment-faults                                   [Software event]
  context-switches OR cs                             [Software event]
  cpu-clock                                          [Software event]
  cpu-migrations OR migrations                       [Software event]
  dummy                                              [Software event]
  emulation-faults                                   [Software event]
  major-faults                                       [Software event]
  minor-faults                                       [Software event]
  page-faults OR faults                              [Software event]
  task-clock                                         [Software event]

  rNNN                                               [Raw hardware event descriptor]
  cpu/t1=v1[,t2=v2,t3 ...]/modifier                  [Raw hardware event descriptor]
   (see 'man perf-list' on how to encode it)

  block:block_bio_backmerge                          [Tracepoint event]
```
* 他のコマンドで`-e block:block_bio_backmerge `みたいに指定してパフォーマンスを測定できる。
* `perf stat -e block:block_bio_backmerge -p プロセス番号`
* [perf Examples](http://www.brendangregg.com/perf.html) にイベントの詳しい一覧図がある
* イベントをピンポイントで計測可能。負荷調査などで大体のボトルネックの箇所がわかっていて、ピンポイントで調べたいときに便利そう
* 詳しく使ってないのでなんともですが、他のコマンドでは測定できない箇所を調べられるのがよさそう

## perf stat
`perf-stat - Run a command and gather performance counter statistics`
システムコールをイベント指定して使ってみた

```sh
$ perf stat -e 'syscalls:sys_enter_gettimeofday' -p 3887
^C
 Performance counter stats for process id '3887':

               592      syscalls:sys_enter_gettimeofday

       0.772927115 seconds time elapsed
```
ハードウェアイベント関連

```sh
perf stat -e cycles,instructions,cache-references,cache-misses,bus-cycles -a sleep 10

 Performance counter stats for 'system wide':

    12,660,287,860      cycles                                                        (100.00%)
     6,503,412,662      instructions              #    0.51  insns per cycle          (100.00%)
       239,947,605      cache-references                                              (100.00%)
         9,235,423      cache-misses              #    3.849 % of all cache refs      (100.00%)
       435,088,963      bus-cycles

      10.000614024 seconds time elapsed
```
* 利用できるカウンタは、プロセッサのアーキテクチャによって決まり、プロセッサのマニュアル(たとえば、Interlの「ソフトウェアデベロッパーズ・マニュアル」にドキュメントされている。)

KVM上のハードウェア関連のイベントをいくつか試したが`not supprot`。なぜだろう？

```sh
$ perf stat -e cycles,instructions,cache-references,cache-misses,bus-cycles -a sleep 10

 Performance counter stats for 'system wide':

   <not supported>      cycles
   <not supported>      instructions
   <not supported>      cache-references
   <not supported>      cache-misses
   <not supported>      bus-cycles

      10.011931754 seconds time elapsed

```

# Linuxパフォーマンスを記録してみる
システム全体を調査

```sh
perf record -ag
```

```sh
-a, --all-cpus
          System-wide collection from all CPUs.
-g, --call-graph
          Do call-graph (stack chain/backtrace) recording.
```
* デフォルトだとカレントディレクトリに`perf.data`として保存される

### コマンドも指定できる
個々のプロセスを対象にすることもできる

```sh
perf record -- [コマンド]
```

# 結果の確認

```sh
perf report -g -G --stdio
```

* -Gをつけないと関数名が16進数表示になる
* --stdioで標準出力
* -gは今回だと特につけてもつけなくても変わらないように見えた。値を指定すると変わるのか、今度試す。

結果

```sh
# To display the perf.data header info, please use --header/--header-only options.
#
# Samples: 5K of event 'cpu-clock'
# Event count (approx.): 59969696370
#
# Children      Self  Command          Shared Object       Symbol
# ........  ........  ...............  ..................  .......................................
#
    48.02%    48.02%  swapper          [kernel.vmlinux]    [k] native_safe_halt
                    |
                    ---native_safe_halt

     6.30%     0.35%  java             libc-2.12.so        [.] mkfifo
                       |
                       ---mkfifo
                          |
                          |--16.04%-- __d_lookup
                          |
                          |--12.83%-- avc_has_perm_noaudit
                          |
                          |--9.09%-- __link_path_walk
                          |
                          |--5.88%-- inode_has_perm
                          |
                          |--4.01%-- acl_permission_check
```

# フレームグラフ
* perf実行結果からスタックフレームをグラフにできる。視覚化され、CPUの使用状況を素早く明確に理解できる
* グラフの見方など [perf + Flame Graphs で Linux カーネル内のボトルネックを特定する](http://d.hatena.ne.jp/yohei-a/20150706/1436208007)

![image](https://qiita-image-store.s3.amazonaws.com/0/91729/4bfb792e-407a-69a6-055a-3f1ba2a68e16.png)

### フレームグラフ作成方法
以下にperfとsystemtapでのCPUフレームグラフの作成方法が載ってた
[CPU Flame Graphs](http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html)

```bash
# git clone https://github.com/brendangregg/FlameGraph  # or download it from github
# cd FlameGraph
# perf record -F 99 -a -g -- sleep 60
# perf script | ./stackcollapse-perf.pl > out.perf-folded
# ./flamegraph.pl out.perf-folded > perf-kernel.svg
```
# まとめ
`vmstat`などで負荷調査。SystemのCPU使用率高いー
↓
`strace`でシステムコールみてみる。あーなんか沢山時間使ってるシステムコールあるー。でもシステムコールから先のカーネルのどこで時間使ってるかわからないー。でも知りたいー。
↓
私には`perf`がある!!
↓
`perf top`でどのカーネル関数がCPU上で沢山使われてるのかー
↓
`perf record`と`perf repot`で詳しいコールグラフみて、どの流れでCPU沢山つかっているんやろーを把握。問題となる関数を把握。
↓
カーネルソース見ながらもくもく`静的解析`して原因究明。対策実施。

次はSystemTap



<h1>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h1>

<p>CentOS6.9でperfコマンドを使ってみたメモ</p>

<h1>
<span id="参考" class="fragment"></span><a href="#%E5%8F%82%E8%80%83"><i class="fa fa-link"></i></a>参考</h1>

<ul>
<li><a href="http://www.brendangregg.com/linuxperf.html" rel="nofollow noopener" target="_blank">Linux Performance</a></li>
<li><a href="http://www.brendangregg.com/perf.html" rel="nofollow noopener" target="_blank">perf Examples</a></li>
<li><a href="https://github.com/brendangregg/perf-tools" rel="nofollow noopener" target="_blank">perf-tools</a></li>
<li><a href="https://perf.wiki.kernel.org/index.php/Main_Page" rel="nofollow noopener" target="_blank">perf wiki</a></li>
<li><a href="https://www.amazon.co.jp/Systems-Performance-Enterprise-Brendan-Gregg/dp/0133390098/ref=sr_1_sc_1?s=books&amp;ie=UTF8&amp;qid=1492582490&amp;sr=8-1-spell&amp;keywords=systemperformance" rel="nofollow noopener" target="_blank">Systems Performance: Enterprise and the Cloud</a></li>
</ul>

<h1>
<span id="perf-is-何" class="fragment"></span><a href="#perf-is-%E4%BD%95"><i class="fa fa-link"></i></a>perf is 何</h1>

<ul>
<li>Performance analysis tools for Linux</li>
<li>参考のリンクがとても詳しい</li>
</ul>

<h1>
<span id="なぜ使うのか" class="fragment"></span><a href="#%E3%81%AA%E3%81%9C%E4%BD%BF%E3%81%86%E3%81%AE%E3%81%8B"><i class="fa fa-link"></i></a>なぜ使うのか</h1>

<p>システムコールから先のカーネルのどこでボトルネックになっているかなどを知りたい場合</p>

<h1>
<span id="導入" class="fragment"></span><a href="#%E5%B0%8E%E5%85%A5"><i class="fa fa-link"></i></a>導入</h1>

<p>yumでサクッとインストールできる。</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>yum <span class="nb">install </span>perf
</code></pre></div></div>

<h1>
<span id="使い方" class="fragment"></span><a href="#%E4%BD%BF%E3%81%84%E6%96%B9"><i class="fa fa-link"></i></a>使い方</h1>

<ul>
<li>
<p>プロファイルの実行</p>

<ul>
<li><code>perf record -ag</code></li>
</ul>
</li>
<li><p>結果を保存</p></li>
<li>
<p>結果の確認</p>

<ul>
<li><code>perf report -g -G --stdio</code></li>
</ul>
</li>
</ul>

<h1>
<span id="コマンド" class="fragment"></span><a href="#%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89"><i class="fa fa-link"></i></a>コマンド</h1>

<p>perf [サブコマンド]</p>

<h1>
<span id="サブコマンド" class="fragment"></span><a href="#%E3%82%B5%E3%83%96%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89"><i class="fa fa-link"></i></a>サブコマンド</h1>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>perf-stat<span class="o">(</span>1<span class="o">)</span>, perf-top<span class="o">(</span>1<span class="o">)</span>, perf-record<span class="o">(</span>1<span class="o">)</span>, perf-report<span class="o">(</span>1<span class="o">)</span>, perf-list<span class="o">(</span>1<span class="o">)</span>
</code></pre></div></div>

<p><code>man perf-サブコマンド</code>でmanが見れる</p>

<h1>
<span id="コマンド使ってみる" class="fragment"></span><a href="#%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B"><i class="fa fa-link"></i></a>コマンド使ってみる</h1>

<h2>
<span id="perf-top" class="fragment"></span><a href="#perf-top"><i class="fa fa-link"></i></a>perf top</h2>

<ul>
<li>関数単位でcpu使用率を閲覧</li>
<li>共有ライブラリのシンボルは16進数で読めない。<code>kernel-debuginfo</code>などインストールしていないがカーネルシンボルが読める。共有ライブラリもシンボルが見れるものがある、なぜでしょうか＞＜？？？？？</li>
</ul>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>Samples: 72K of event <span class="s1">'cpu-clock'</span>, Event count <span class="o">(</span>approx.<span class="o">)</span>: 2471353254
Overhead  Shared Object             Symbol
   3.76%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] find_vma
   3.56%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] __d_lookup
   2.44%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] avc_has_perm_noaudit
   2.42%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] __link_path_walk
   2.39%  libjvm.so                 <span class="o">[</span>.] 0x00000000004743a3
   1.89%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] prof_syscall_enter
   1.72%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] inode_has_perm
   1.64%  libc-2.12.so              <span class="o">[</span>.] <span class="nb">mkfifo
   </span>1.34%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] selinux_inode_permission
   1.23%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] finish_task_switch
   1.04%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] kmem_cache_alloc
   0.87%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] system_call
   0.84%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] syscall_trace_enter
   0.80%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] strncpy_from_user
   0.74%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] __do_softirq
   0.66%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] acl_permission_check
   0.61%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] do_lookup
   0.54%  libjvm.so                 <span class="o">[</span>.] 0x000000000065af65
   0.53%  libc-2.12.so              <span class="o">[</span>.] memcpy
   0.51%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] follow_managed
   0.47%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] audit_syscall_entry
   0.44%  libjvm.so                 <span class="o">[</span>.] 0x00000000009ff88c
   0.43%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] dput
   0.43%  libjvm.so                 <span class="o">[</span>.] 0x00000000006c1c56
   0.42%  <span class="o">[</span>kernel]                  <span class="o">[</span>k] _atomic_dec_and_lock
   0.41%  perf                      <span class="o">[</span>.] hists__output_resort
   0.41%  libjvm.so                 <span class="o">[</span>.] 0x000000000032ef1e
</code></pre></div></div>

<h2>
<span id="perf-list" class="fragment"></span><a href="#perf-list"><i class="fa fa-link"></i></a>perf list</h2>

<ul>
<li>調査可能なイベント一覧</li>
<li>出力されたイベントは他のサブコマンドの-eオプションで指定できる</li>
</ul>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code># perf list | more

List of pre-defined events (to be used in -e):

  alignment-faults                                   [Software event]
  context-switches OR cs                             [Software event]
  cpu-clock                                          [Software event]
  cpu-migrations OR migrations                       [Software event]
  dummy                                              [Software event]
  emulation-faults                                   [Software event]
  major-faults                                       [Software event]
  minor-faults                                       [Software event]
  page-faults OR faults                              [Software event]
  task-clock                                         [Software event]

  rNNN                                               [Raw hardware event descriptor]
  cpu/t1=v1[,t2=v2,t3 ...]/modifier                  [Raw hardware event descriptor]
   (see 'man perf-list' on how to encode it)

  block:block_bio_backmerge                          [Tracepoint event]
</code></pre></div></div>

<ul>
<li>他のコマンドで<code>-e block:block_bio_backmerge</code>みたいに指定してパフォーマンスを測定できる。</li>
<li><code>perf stat -e block:block_bio_backmerge -p プロセス番号</code></li>
<li>
<a href="http://www.brendangregg.com/perf.html" rel="nofollow noopener" target="_blank">perf Examples</a> にイベントの詳しい一覧図がある</li>
<li>イベントをピンポイントで計測可能。負荷調査などで大体のボトルネックの箇所がわかっていて、ピンポイントで調べたいときに便利そう</li>
<li>詳しく使ってないのでなんともですが、他のコマンドでは測定できない箇所を調べられるのがよさそう</li>
</ul>

<h2>
<span id="perf-stat" class="fragment"></span><a href="#perf-stat"><i class="fa fa-link"></i></a>perf stat</h2>

<p><code>perf-stat - Run a command and gather performance counter statistics</code><br>
システムコールをイベント指定して使ってみた</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="nv">$ </span>perf <span class="nb">stat</span> <span class="nt">-e</span> <span class="s1">'syscalls:sys_enter_gettimeofday'</span> <span class="nt">-p</span> 3887
^C
 Performance counter stats <span class="k">for </span>process <span class="nb">id</span> <span class="s1">'3887'</span>:

               592      syscalls:sys_enter_gettimeofday

       0.772927115 seconds <span class="nb">time </span>elapsed
</code></pre></div></div>

<p>ハードウェアイベント関連</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>perf <span class="nb">stat</span> <span class="nt">-e</span> cycles,instructions,cache-references,cache-misses,bus-cycles <span class="nt">-a</span> <span class="nb">sleep </span>10

 Performance counter stats <span class="k">for</span> <span class="s1">'system wide'</span>:

    12,660,287,860      cycles                                                        <span class="o">(</span>100.00%<span class="o">)</span>
     6,503,412,662      instructions              <span class="c">#    0.51  insns per cycle          (100.00%)</span>
       239,947,605      cache-references                                              <span class="o">(</span>100.00%<span class="o">)</span>
         9,235,423      cache-misses              <span class="c">#    3.849 % of all cache refs      (100.00%)</span>
       435,088,963      bus-cycles

      10.000614024 seconds <span class="nb">time </span>elapsed
</code></pre></div></div>

<ul>
<li>利用できるカウンタは、プロセッサのアーキテクチャによって決まり、プロセッサのマニュアル(たとえば、Interlの「ソフトウェアデベロッパーズ・マニュアル」にドキュメントされている。)</li>
</ul>

<p>KVM上のハードウェア関連のイベントをいくつか試したが<code>not supprot</code>。なぜだろう？</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="nv">$ </span>perf <span class="nb">stat</span> <span class="nt">-e</span> cycles,instructions,cache-references,cache-misses,bus-cycles <span class="nt">-a</span> <span class="nb">sleep </span>10

 Performance counter stats <span class="k">for</span> <span class="s1">'system wide'</span>:

   &lt;not supported&gt;      cycles
   &lt;not supported&gt;      instructions
   &lt;not supported&gt;      cache-references
   &lt;not supported&gt;      cache-misses
   &lt;not supported&gt;      bus-cycles

      10.011931754 seconds <span class="nb">time </span>elapsed

</code></pre></div></div>

<h1>
<span id="linuxパフォーマンスを記録してみる" class="fragment"></span><a href="#linux%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E3%82%92%E8%A8%98%E9%8C%B2%E3%81%97%E3%81%A6%E3%81%BF%E3%82%8B"><i class="fa fa-link"></i></a>Linuxパフォーマンスを記録してみる</h1>

<p>システム全体を調査</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>perf record <span class="nt">-ag</span>
</code></pre></div></div>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="nt">-a</span>, <span class="nt">--all-cpus</span>
          System-wide collection from all CPUs.
<span class="nt">-g</span>, <span class="nt">--call-graph</span>
          Do call-graph <span class="o">(</span>stack chain/backtrace<span class="o">)</span> recording.
</code></pre></div></div>

<ul>
<li>デフォルトだとカレントディレクトリに<code>perf.data</code>として保存される</li>
</ul>

<h3>
<span id="コマンドも指定できる" class="fragment"></span><a href="#%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%82%E6%8C%87%E5%AE%9A%E3%81%A7%E3%81%8D%E3%82%8B"><i class="fa fa-link"></i></a>コマンドも指定できる</h3>

<p>個々のプロセスを対象にすることもできる</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>perf record <span class="nt">--</span> <span class="o">[</span>コマンド]
</code></pre></div></div>

<h1>
<span id="結果の確認" class="fragment"></span><a href="#%E7%B5%90%E6%9E%9C%E3%81%AE%E7%A2%BA%E8%AA%8D"><i class="fa fa-link"></i></a>結果の確認</h1>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>perf report <span class="nt">-g</span> <span class="nt">-G</span> <span class="nt">--stdio</span>
</code></pre></div></div>

<ul>
<li>-Gをつけないと関数名が16進数表示になる</li>
<li>--stdioで標準出力</li>
<li>-gは今回だと特につけてもつけなくても変わらないように見えた。値を指定すると変わるのか、今度試す。</li>
</ul>

<p>結果</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="c"># To display the perf.data header info, please use --header/--header-only options.</span>
<span class="c">#</span>
<span class="c"># Samples: 5K of event 'cpu-clock'</span>
<span class="c"># Event count (approx.): 59969696370</span>
<span class="c">#</span>
<span class="c"># Children      Self  Command          Shared Object       Symbol</span>
<span class="c"># ........  ........  ...............  ..................  .......................................</span>
<span class="c">#</span>
    48.02%    48.02%  swapper          <span class="o">[</span>kernel.vmlinux]    <span class="o">[</span>k] native_safe_halt
                    |
                    <span class="nt">---native_safe_halt</span>

     6.30%     0.35%  java             libc-2.12.so        <span class="o">[</span>.] <span class="nb">mkfifo</span>
                       |
                       <span class="nt">---mkfifo</span>
                          |
                          |--16.04%-- __d_lookup
                          |
                          |--12.83%-- avc_has_perm_noaudit
                          |
                          |--9.09%-- __link_path_walk
                          |
                          |--5.88%-- inode_has_perm
                          |
                          |--4.01%-- acl_permission_check
</code></pre></div></div>

<h1>
<span id="フレームグラフ" class="fragment"></span><a href="#%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%82%B0%E3%83%A9%E3%83%95"><i class="fa fa-link"></i></a>フレームグラフ</h1>

<ul>
<li>perf実行結果からスタックフレームをグラフにできる。視覚化され、CPUの使用状況を素早く明確に理解できる</li>
<li>グラフの見方など <a href="http://d.hatena.ne.jp/yohei-a/20150706/1436208007" rel="nofollow noopener" target="_blank">perf + Flame Graphs で Linux カーネル内のボトルネックを特定する</a>
</li>
</ul>

<p><a href="https://camo.qiitausercontent.com/bbb6103c26481ab8e0cf7fe2022921e2a0f5cbb3/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f39313732392f34626662373932652d343037612d363961362d303535612d3366316261326136386531362e706e67" target="_blank" rel="nofollow noopener"><img src="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F91729%2F4bfb792e-407a-69a6-055a-3f1ba2a68e16.png?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;s=418e35ca999a191496f7e04de8a27843" alt="image" data-canonical-src="https://qiita-image-store.s3.amazonaws.com/0/91729/4bfb792e-407a-69a6-055a-3f1ba2a68e16.png" srcset="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F91729%2F4bfb792e-407a-69a6-055a-3f1ba2a68e16.png?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;w=1400&amp;fit=max&amp;s=f7cd0da0e8f7a06ef03149b8f236eeb7 1x" loading="lazy"></a></p>

<h3>
<span id="フレームグラフ作成方法" class="fragment"></span><a href="#%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%82%B0%E3%83%A9%E3%83%95%E4%BD%9C%E6%88%90%E6%96%B9%E6%B3%95"><i class="fa fa-link"></i></a>フレームグラフ作成方法</h3>

<p>以下にperfとsystemtapでのCPUフレームグラフの作成方法が載ってた<br>
<a href="http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html" rel="nofollow noopener" target="_blank">CPU Flame Graphs</a></p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="c"># git clone https://github.com/brendangregg/FlameGraph  # or download it from github</span>
<span class="c"># cd FlameGraph</span>
<span class="c"># perf record -F 99 -a -g -- sleep 60</span>
<span class="c"># perf script | ./stackcollapse-perf.pl &gt; out.perf-folded</span>
<span class="c"># ./flamegraph.pl out.perf-folded &gt; perf-kernel.svg</span>
</code></pre></div></div>

<h1>
<span id="まとめ" class="fragment"></span><a href="#%E3%81%BE%E3%81%A8%E3%82%81"><i class="fa fa-link"></i></a>まとめ</h1>

<p><code>vmstat</code>などで負荷調査。SystemのCPU使用率高いー<br>
↓<br>
<code>strace</code>でシステムコールみてみる。あーなんか沢山時間使ってるシステムコールあるー。でもシステムコールから先のカーネルのどこで時間使ってるかわからないー。でも知りたいー。<br>
↓<br>
私には<code>perf</code>がある!!<br>
↓<br>
<code>perf top</code>でどのカーネル関数がCPU上で沢山使われてるのかー<br>
↓<br>
<code>perf record</code>と<code>perf repot</code>で詳しいコールグラフみて、どの流れでCPU沢山つかっているんやろーを把握。問題となる関数を把握。<br>
↓<br>
カーネルソース見ながらもくもく<code>静的解析</code>して原因究明。対策実施。</p>

<p>次はSystemTap</p>


perf使ってみた

# 概要
何回も忘れるのでメモ

# 参考1
http://hacktux.com/bashrc-bash_profile/
http://qiita.com/incep/items/7e5760de0c2c748296aa

# シェルの種類
# ログインシェル
* OSログインした後に起動するシェルがログインシェル
* GUIでログインするとOSログインのタイミングでログインシェルが起動している(端末クリック無し)。そして端末クリックは対話シェルが起動。~~GUIでログインした場合は、内部的にログインシェルが起動していて、端末アイコンなどをクリックしたらそのログインシェルから対話シェルが生成されている、はず。~~

**↓↓↓もログインシェル起動する**

* su - [user]
* bash --login 
* ssh user@host (ssh接続した先でシェル起動しているので対話シェルも起動している)
* macOS Terminal.app 新規ウインドウ/タブ 
* tmux 新規ウインドウ 


# 対話シェル(~/.bash_profileは読み込まない)
* GUIの端末アイコンクリックから生成するシェル
* su [user] 
* bash (ssh後など)
* ssh user@host /path/to/command

## ログインシェルの設定ファイル読み込み

以下順番で読み込む。CentOSの場合は「.bash_profile」が存在する場合は、他の2つの設定ファイルを無視するみたい。自分のCentOS6.9には無かったので、CentOSの場合そもそもデフォルトでは存在しないみたい。

* /etc/profile
* ~/.bash_profile
  - ~/.bash_login (自分のCentOS6.9には無かった)
  - ~/.profile　　(自分のCentOS6.9には無かった)
* ~/.bashrc (対話シェルはこれだけ読み込む)
* /etc/bashrc(~/.bashrc から読み込まれる)

## 対話シェルの設定ファイル読み込み
* ~/.bashrc (対話シェルはこれだけ読み込む)
* /etc/bashrc(~/.bashrc から読み込まれる)

## 各設定ファイル
### /etc/profile
* ログインシェルが読み込む
* `全ユーザ`の全プロセスで利用したい設定を書く。環境変数は受け継がれるので。
* シェル変数はそのシェルだけ有効なので、全ユーザがログインシェルだけを想定した利用のみ有効にしたい変数はここにシェル変数を書く。そんなのある？
* 環境変数と起動プログラムが記述されてる

### ~/.bash_profile
* ログインシェルが読み込む
* `各ユーザ`の全プロセスに利用したい設定を書く。環境変数は受け継がれる。
* シェル変数はそのシェルだけのみなので、ログインシェルだけを想定した利用のみ有効にしたい変数はここにシェル変数を書く。そんなのある？
* /.bashrcをよみこんでいる。例えばssh接続の場合、~/.bashrcも同時に読み込む。

```bash

$ cat ~/.bash_profile 
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH
```

### ~/.bashrc
* 対話シェル、ログインシェル読み込み
* ~/.bash_profileから読み込まれる(ログインシェル起動経由でも読み込まれる)
* 対話シェル起動の場合はこれだけ読み込まれる。
* `各ユーザ`の対話シェルで利用したい設定を書く。環境変数だとこの対話シェルから起動したプロセスにも受け継ぐ。シェル変数はそのプロセスのみ。
* シェル変数はそのシェルだけ有効なので、対話シェルだけを想定した利用のみ有効にしたい変数はここにシェル変数を書く
* がしかし、環境変数で設定してもこの対話シェルで有効になるしこの対話シェルから生成するシェルなど想定しない時がほとんどなので環境変数をここに書く


### /etc/bashrc
* 対話シェル、ログインシェル読み込み
* `全ユーザ`の対話シェルで利用したい設定を書く。環境変数だとこの対話シェルから起動したプロセスにも受け継ぐ。シェル変数は対話プロセスのみ。
* シェルを起動した環境ごとのプロンプトが定義。ファイルやディレクトリを新規作成した場合にどのようなパーミッションが設定されるかが記述

存在したら読み込まれるみたい

```bash

$ cat ~/.bashrc 
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# User specific aliases and functions
```

## 参考2
http://itpro.nikkeibp.co.jp/article/Keyword/20070831/280849/
http://oxynotes.com/?p=5418:embed:cite



<h1>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h1>

<p>何回も忘れるのでメモ</p>

<h1>
<span id="参考1" class="fragment"></span><a href="#%E5%8F%82%E8%80%831"><i class="fa fa-link"></i></a>参考1</h1>

<p><a href="http://hacktux.com/bashrc-bash_profile/" class="autolink" rel="nofollow noopener" target="_blank">http://hacktux.com/bashrc-bash_profile/</a><br>
<a href="http://qiita.com/incep/items/7e5760de0c2c748296aa" class="autolink" id="reference-983f4c1b17a2c187f236">http://qiita.com/incep/items/7e5760de0c2c748296aa</a></p>

<h1>
<span id="シェルの種類" class="fragment"></span><a href="#%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AE%E7%A8%AE%E9%A1%9E"><i class="fa fa-link"></i></a>シェルの種類</h1>

<h1>
<span id="ログインシェル" class="fragment"></span><a href="#%E3%83%AD%E3%82%B0%E3%82%A4%E3%83%B3%E3%82%B7%E3%82%A7%E3%83%AB"><i class="fa fa-link"></i></a>ログインシェル</h1>

<ul>
<li>OSログインした後に起動するシェルがログインシェル</li>
<li>GUIでログインするとOSログインのタイミングでログインシェルが起動している(端末クリック無し)。そして端末クリックは対話シェルが起動。<del>GUIでログインした場合は、内部的にログインシェルが起動していて、端末アイコンなどをクリックしたらそのログインシェルから対話シェルが生成されている、はず。</del>
</li>
</ul>

<p><strong>↓↓↓もログインシェル起動する</strong></p>

<ul>
<li>su - [user]</li>
<li>bash --login </li>
<li>ssh user@host (ssh接続した先でシェル起動しているので対話シェルも起動している)</li>
<li>macOS Terminal.app 新規ウインドウ/タブ </li>
<li>tmux 新規ウインドウ </li>
</ul>

<h1>
<span id="対話シェルbash_profileは読み込まない" class="fragment"></span><a href="#%E5%AF%BE%E8%A9%B1%E3%82%B7%E3%82%A7%E3%83%ABbash_profile%E3%81%AF%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BE%E3%81%AA%E3%81%84"><i class="fa fa-link"></i></a>対話シェル(~/.bash_profileは読み込まない)</h1>

<ul>
<li>GUIの端末アイコンクリックから生成するシェル</li>
<li>su [user] </li>
<li>bash (ssh後など)</li>
<li>ssh user@host /path/to/command</li>
</ul>

<h2>
<span id="ログインシェルの設定ファイル読み込み" class="fragment"></span><a href="#%E3%83%AD%E3%82%B0%E3%82%A4%E3%83%B3%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF"><i class="fa fa-link"></i></a>ログインシェルの設定ファイル読み込み</h2>

<p>以下順番で読み込む。CentOSの場合は「.bash_profile」が存在する場合は、他の2つの設定ファイルを無視するみたい。自分のCentOS6.9には無かったので、CentOSの場合そもそもデフォルトでは存在しないみたい。</p>

<ul>
<li>/etc/profile</li>
<li>~/.bash_profile

<ul>
<li>~/.bash_login (自分のCentOS6.9には無かった)</li>
<li>~/.profile　　(自分のCentOS6.9には無かった)</li>
</ul>
</li>
<li>~/.bashrc (対話シェルはこれだけ読み込む)</li>
<li>/etc/bashrc(~/.bashrc から読み込まれる)</li>
</ul>

<h2>
<span id="対話シェルの設定ファイル読み込み" class="fragment"></span><a href="#%E5%AF%BE%E8%A9%B1%E3%82%B7%E3%82%A7%E3%83%AB%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF"><i class="fa fa-link"></i></a>対話シェルの設定ファイル読み込み</h2>

<ul>
<li>~/.bashrc (対話シェルはこれだけ読み込む)</li>
<li>/etc/bashrc(~/.bashrc から読み込まれる)</li>
</ul>

<h2>
<span id="各設定ファイル" class="fragment"></span><a href="#%E5%90%84%E8%A8%AD%E5%AE%9A%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB"><i class="fa fa-link"></i></a>各設定ファイル</h2>

<h3>
<span id="etcprofile" class="fragment"></span><a href="#etcprofile"><i class="fa fa-link"></i></a>/etc/profile</h3>

<ul>
<li>ログインシェルが読み込む</li>
<li>
<code>全ユーザ</code>の全プロセスで利用したい設定を書く。環境変数は受け継がれるので。</li>
<li>シェル変数はそのシェルだけ有効なので、全ユーザがログインシェルだけを想定した利用のみ有効にしたい変数はここにシェル変数を書く。そんなのある？</li>
<li>環境変数と起動プログラムが記述されてる</li>
</ul>

<h3>
<span id="bash_profile" class="fragment"></span><a href="#bash_profile"><i class="fa fa-link"></i></a>~/.bash_profile</h3>

<ul>
<li>ログインシェルが読み込む</li>
<li>
<code>各ユーザ</code>の全プロセスに利用したい設定を書く。環境変数は受け継がれる。</li>
<li>シェル変数はそのシェルだけのみなので、ログインシェルだけを想定した利用のみ有効にしたい変数はここにシェル変数を書く。そんなのある？</li>
<li>/.bashrcをよみこんでいる。例えばssh接続の場合、~/.bashrcも同時に読み込む。</li>
</ul>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>
<span class="nv">$ </span><span class="nb">cat</span> ~/.bash_profile 
<span class="c"># .bash_profile</span>

<span class="c"># Get the aliases and functions</span>
<span class="k">if</span> <span class="o">[</span> <span class="nt">-f</span> ~/.bashrc <span class="o">]</span><span class="p">;</span> <span class="k">then</span>
        <span class="nb">.</span> ~/.bashrc
<span class="k">fi</span>

<span class="c"># User specific environment and startup programs</span>

<span class="nv">PATH</span><span class="o">=</span><span class="nv">$PATH</span>:<span class="nv">$HOME</span>/bin

<span class="nb">export </span>PATH
</code></pre></div></div>

<h3>
<span id="bashrc" class="fragment"></span><a href="#bashrc"><i class="fa fa-link"></i></a>~/.bashrc</h3>

<ul>
<li>対話シェル、ログインシェル読み込み</li>
<li>~/.bash_profileから読み込まれる(ログインシェル起動経由でも読み込まれる)</li>
<li>対話シェル起動の場合はこれだけ読み込まれる。</li>
<li>
<code>各ユーザ</code>の対話シェルで利用したい設定を書く。環境変数だとこの対話シェルから起動したプロセスにも受け継ぐ。シェル変数はそのプロセスのみ。</li>
<li>シェル変数はそのシェルだけ有効なので、対話シェルだけを想定した利用のみ有効にしたい変数はここにシェル変数を書く</li>
<li>がしかし、環境変数で設定してもこの対話シェルで有効になるしこの対話シェルから生成するシェルなど想定しない時がほとんどなので環境変数をここに書く</li>
</ul>

<h3>
<span id="etcbashrc" class="fragment"></span><a href="#etcbashrc"><i class="fa fa-link"></i></a>/etc/bashrc</h3>

<ul>
<li>対話シェル、ログインシェル読み込み</li>
<li>
<code>全ユーザ</code>の対話シェルで利用したい設定を書く。環境変数だとこの対話シェルから起動したプロセスにも受け継ぐ。シェル変数は対話プロセスのみ。</li>
<li>シェルを起動した環境ごとのプロンプトが定義。ファイルやディレクトリを新規作成した場合にどのようなパーミッションが設定されるかが記述</li>
</ul>

<p>存在したら読み込まれるみたい</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>
<span class="nv">$ </span><span class="nb">cat</span> ~/.bashrc 
<span class="c"># .bashrc</span>

<span class="c"># Source global definitions</span>
<span class="k">if</span> <span class="o">[</span> <span class="nt">-f</span> /etc/bashrc <span class="o">]</span><span class="p">;</span> <span class="k">then</span>
        <span class="nb">.</span> /etc/bashrc
<span class="k">fi</span>

<span class="c"># User specific aliases and functions</span>
</code></pre></div></div>

<h2>
<span id="参考2" class="fragment"></span><a href="#%E5%8F%82%E8%80%832"><i class="fa fa-link"></i></a>参考2</h2>

<p><a href="http://itpro.nikkeibp.co.jp/article/Keyword/20070831/280849/" class="autolink" rel="nofollow noopener" target="_blank">http://itpro.nikkeibp.co.jp/article/Keyword/20070831/280849/</a><br>
<a href="http://oxynotes.com/?p=5418:embed:cite" class="autolink" rel="nofollow noopener" target="_blank">http://oxynotes.com/?p=5418:embed:cite</a></p>


シェルの設定ファイル(bash)

## 概要
IO待ちについて自分で調べた自分めも。

## vmstat wa列
[絵で見てわかるシステムパフォーマンスの仕組み ](https://www.amazon.co.jp/%E7%B5%B5%E3%81%A7%E8%A6%8B%E3%81%A6%E3%82%8F%E3%81%8B%E3%82%8B%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF-%E5%B0%8F%E7%94%B0-%E5%9C%AD%E4%BA%8C-ebook/dp/B00LHFOTF4/ref=sr_1_2?ie=UTF8&qid=1491439593&sr=8-2&keywords=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9)より
>    - ディスクIO待ちのwaはCPU使用率が上がると自然と減ってしまうものです。I/O待ちについてはb列を活用しましょう。
   - waはあくまでもCPUがアイドルであり、そのCPUに紐付くI/O待ちスレッドがあるときにカウントされる
   - wa列は要注意です。一般にI/O待ちの指標と思われていますが、I/O待ちが増えるとwa列が上がる傾向があるものの、必ずしも上がるとは限らない情報だからです

[絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている (DB Magazine Selection)](https://www.amazon.co.jp/%E7%B5%B5%E3%81%A7%E8%A6%8B%E3%81%A6%E3%82%8F%E3%81%8B%E3%82%8BOS-%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8-%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF-%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AF%E3%81%93%E3%81%86%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B-Magazine-Selection/dp/479811703X/ref=sr_1_1?s=books&ie=UTF8&qid=1491445240&sr=1-1&keywords=OS%E3%80%80%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%80%80%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF) より
>スリープしているプロセスの中には、I/O待ちをしているものもある。その場合、「wa(waitI/O)」として現れることが多い。多くのOSでは、CPUがアイドル(id)であり、かつそのCPUから発行されたI/Oがある場合、「wa(waitI/O)」となる

*[ iowait について](http://d.hatena.ne.jp/yohei-a/20120201/1328108666) より
>システムコール発行したらコンテキストスイッチが発生してスリープし、TASK_UNINTERRUPTIBLE で Disk Sleep する。CPU が空いてるのに、I/O要求が残っている場合に iowait としてカウントされるということだと思う。

[プロセスアカウンティング処理を見てみる](http://qiita.com/saikoro-steak/items/30cc061804326c72e9e9)

この辺りの説明でカバーできていそう。たぶん。
↓
>R(TASK_RUNNING)が多い場合、D(TASK_UNINTERRUPTIB)プロセスがたくさん存在していてもwaには反映されない。なのでIO待ちの具合を調べるのはb列を確認するのが確実そう。
I/O wait時間の統計
カレントプロセスがswapperプロセスの場合に(TASK_RUNNNINGなプロセスが存在しない場合)、IO待ちのプロセスが一つでも存在すればIOwait時間として足し込まれます。

## IO待ち時間
[詳解 システム・パフォーマンスより](https://www.amazon.co.jp/%E8%A9%B3%E8%A7%A3-%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0-%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9-Brendan-Gregg/dp/4873117909/ref=sr_1_1?ie=UTF8&qid=1492663507&sr=8-1&keywords=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9)
>I/O待ち時間は非常に誤解を招きやすい指標だ。CPUを酷使するプロセスがほかにやってくると、I/O待ち時間の値は下がる。するべき仕事ができたので、CPUはアイドル状態で待っていなくてよいのである。しかし、I/O待ち時間の数値が下がっても、同じディスクI/Oがなくなったわけでも、スレッドをブロックしなくなったわけでもない。逆もありうる。
LinuxではI/O待ち時間は今でもよく使われている指標であり、混乱を招く性質を持ちながら、あるタイプのディスクのボトルネック、つまりCPUがアイドルでディスクがビジーになっている状態を見つけ出すことができている。I/O待ち時間の一つの解釈方法は,I/O待ち時間が存在することをシステムにボトルネックがある兆候と捉え、例え高いCPU使用率とI/O待ち時間が両立している場合でも、I/O待ち時間を最小限に抑えるようにシステムをチューニングするというものである。



## IO待ち多数による影響
[ load average ってなんじゃい？](http://d.hatena.ne.jp/yohei-a/20100816/1281943286)より
>load average が高いと、CPU がなかなか割り当てられないので、「ターミナルエミュレータを使って ssh などでログインしてコマンドを打ってもレスポンスが帰ってくるのが遅い」というような状況になっているときだと思う。

>* TASK_RUNNING
    - 実行中もしくは実行可能でCPU割り当てを待っている状態。
    - vmstat で `r 列`に表示されるのがこの状態のプロセスの数。
* TASK_UNINTERRUPTIBLE
    - 割り込み不可能な待ち状態。ディスクI/O待ちなど短い事象。
    - vmstat で `b 列`に表示されるのがこの状態のプロセスの数。

ディスクI/O待ちなど`短い`事象。

[ [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)](https://www.amazon.co.jp/24%E6%99%82%E9%96%93365%E6%97%A5-%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%A9%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3-%E3%83%8F%E3%82%A4%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9-%E7%9C%81%E5%8A%9B%E9%81%8B%E7%94%A8-PRESS-plus%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA/dp/4774135666/ref=sr_1_1?s=books&ie=UTF8&qid=1491444604&sr=1-1&keywords=%E3%82%B5%E3%83%BC%E3%83%90%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93) より
>ロードアベレージが報告する負荷の正体
* CPuの実行権限が与えられるのを待っているプロセス
* ディスクI/Oが完了するのを待っているプロセス

>これはたしかに、直感と一致します。
ディスクからデータを大量に読み出している間は、システムの反応がにぶくなったりします。

## まとめ
* CPU使用率(us+sy)が高いとwa列が低くてもIO待ち少ないとは言い切れなさそう。ただ、waの値が高い状態は、そのまま単純にIO待ちが多いということを表している。
* io待ちはvmstatの`b列`でみていくのもよさそう。waの値が低い場合にIO待ちは少ないとは言いきれないので。
* CPU使用率が高いプロセスがいると待ち行列が長くなる確率が高くなる。
* Load averageが高いとCPUがなかなか割り当てられない。
    - カーネルがプロセスをスケジューリング対象とするランキューには`TASK_RUNNING`しか存在せず、IO待ちプロセスは別のキューに存在するが、`TASK_UNINTERRUPTIBLE`状態が解除され、都度？ランキューに入り込んでくるので？その分のスケジューリング対象が増えCPUがなかなか割り当てられないことが増える？ので一見IO待ちが増えてもCPUはidleなのでシステムに負荷かかっていないように見えるが、LAが高いと(IO待ち含む)とCPUがなかなか割り当てられないので負荷がかかっているといえる？





<h2>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h2>

<p>IO待ちについて自分で調べた自分めも。</p>

<h2>
<span id="vmstat-wa列" class="fragment"></span><a href="#vmstat-wa%E5%88%97"><i class="fa fa-link"></i></a>vmstat wa列</h2>

<p><a href="https://www.amazon.co.jp/%E7%B5%B5%E3%81%A7%E8%A6%8B%E3%81%A6%E3%82%8F%E3%81%8B%E3%82%8B%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF-%E5%B0%8F%E7%94%B0-%E5%9C%AD%E4%BA%8C-ebook/dp/B00LHFOTF4/ref=sr_1_2?ie=UTF8&amp;qid=1491439593&amp;sr=8-2&amp;keywords=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9" rel="nofollow noopener" target="_blank">絵で見てわかるシステムパフォーマンスの仕組み </a>より</p>

<blockquote>
<ul>
<li>ディスクIO待ちのwaはCPU使用率が上がると自然と減ってしまうものです。I/O待ちについてはb列を活用しましょう。</li>
<li>waはあくまでもCPUがアイドルであり、そのCPUに紐付くI/O待ちスレッドがあるときにカウントされる</li>
<li>wa列は要注意です。一般にI/O待ちの指標と思われていますが、I/O待ちが増えるとwa列が上がる傾向があるものの、必ずしも上がるとは限らない情報だからです</li>
</ul>
</blockquote>

<p><a href="https://www.amazon.co.jp/%E7%B5%B5%E3%81%A7%E8%A6%8B%E3%81%A6%E3%82%8F%E3%81%8B%E3%82%8BOS-%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8-%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF-%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AF%E3%81%93%E3%81%86%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B-Magazine-Selection/dp/479811703X/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1491445240&amp;sr=1-1&amp;keywords=OS%E3%80%80%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%80%80%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF" rel="nofollow noopener" target="_blank">絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている (DB Magazine Selection)</a> より</p>

<blockquote>
<p>スリープしているプロセスの中には、I/O待ちをしているものもある。その場合、「wa(waitI/O)」として現れることが多い。多くのOSでは、CPUがアイドル(id)であり、かつそのCPUから発行されたI/Oがある場合、「wa(waitI/O)」となる</p>
</blockquote>

<p>*<a href="http://d.hatena.ne.jp/yohei-a/20120201/1328108666" rel="nofollow noopener" target="_blank"> iowait について</a> より</p>

<blockquote>
<p>システムコール発行したらコンテキストスイッチが発生してスリープし、TASK_UNINTERRUPTIBLE で Disk Sleep する。CPU が空いてるのに、I/O要求が残っている場合に iowait としてカウントされるということだと思う。</p>
</blockquote>

<p><a href="http://qiita.com/saikoro-steak/items/30cc061804326c72e9e9" id="reference-5932d90120896ad3ae8b">プロセスアカウンティング処理を見てみる</a></p>

<p>この辺りの説明でカバーできていそう。たぶん。<br>
↓</p>

<blockquote>
<p>R(TASK_RUNNING)が多い場合、D(TASK_UNINTERRUPTIB)プロセスがたくさん存在していてもwaには反映されない。なのでIO待ちの具合を調べるのはb列を確認するのが確実そう。<br>
I/O wait時間の統計<br>
カレントプロセスがswapperプロセスの場合に(TASK_RUNNNINGなプロセスが存在しない場合)、IO待ちのプロセスが一つでも存在すればIOwait時間として足し込まれます。</p>
</blockquote>

<h2>
<span id="io待ち時間" class="fragment"></span><a href="#io%E5%BE%85%E3%81%A1%E6%99%82%E9%96%93"><i class="fa fa-link"></i></a>IO待ち時間</h2>

<p><a href="https://www.amazon.co.jp/%E8%A9%B3%E8%A7%A3-%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0-%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9-Brendan-Gregg/dp/4873117909/ref=sr_1_1?ie=UTF8&amp;qid=1492663507&amp;sr=8-1&amp;keywords=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9" rel="nofollow noopener" target="_blank">詳解 システム・パフォーマンスより</a></p>

<blockquote>
<p>I/O待ち時間は非常に誤解を招きやすい指標だ。CPUを酷使するプロセスがほかにやってくると、I/O待ち時間の値は下がる。するべき仕事ができたので、CPUはアイドル状態で待っていなくてよいのである。しかし、I/O待ち時間の数値が下がっても、同じディスクI/Oがなくなったわけでも、スレッドをブロックしなくなったわけでもない。逆もありうる。<br>
LinuxではI/O待ち時間は今でもよく使われている指標であり、混乱を招く性質を持ちながら、あるタイプのディスクのボトルネック、つまりCPUがアイドルでディスクがビジーになっている状態を見つけ出すことができている。I/O待ち時間の一つの解釈方法は,I/O待ち時間が存在することをシステムにボトルネックがある兆候と捉え、例え高いCPU使用率とI/O待ち時間が両立している場合でも、I/O待ち時間を最小限に抑えるようにシステムをチューニングするというものである。</p>
</blockquote>

<h2>
<span id="io待ち多数による影響" class="fragment"></span><a href="#io%E5%BE%85%E3%81%A1%E5%A4%9A%E6%95%B0%E3%81%AB%E3%82%88%E3%82%8B%E5%BD%B1%E9%9F%BF"><i class="fa fa-link"></i></a>IO待ち多数による影響</h2>

<p><a href="http://d.hatena.ne.jp/yohei-a/20100816/1281943286" rel="nofollow noopener" target="_blank"> load average ってなんじゃい？</a>より</p>

<blockquote>
<p>load average が高いと、CPU がなかなか割り当てられないので、「ターミナルエミュレータを使って ssh などでログインしてコマンドを打ってもレスポンスが帰ってくるのが遅い」というような状況になっているときだと思う。</p>

<ul>
<li>TASK_RUNNING

<ul>
<li>実行中もしくは実行可能でCPU割り当てを待っている状態。</li>
<li>vmstat で <code>r 列</code>に表示されるのがこの状態のプロセスの数。</li>
</ul>
</li>
<li>TASK_UNINTERRUPTIBLE

<ul>
<li>割り込み不可能な待ち状態。ディスクI/O待ちなど短い事象。</li>
<li>vmstat で <code>b 列</code>に表示されるのがこの状態のプロセスの数。</li>
</ul>
</li>
</ul>
</blockquote>

<p>ディスクI/O待ちなど<code>短い</code>事象。</p>

<p><a href="https://www.amazon.co.jp/24%E6%99%82%E9%96%93365%E6%97%A5-%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%A9%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3-%E3%83%8F%E3%82%A4%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9-%E7%9C%81%E5%8A%9B%E9%81%8B%E7%94%A8-PRESS-plus%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA/dp/4774135666/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1491444604&amp;sr=1-1&amp;keywords=%E3%82%B5%E3%83%BC%E3%83%90%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93" rel="nofollow noopener" target="_blank"> [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)</a> より</p>

<blockquote>
<p>ロードアベレージが報告する負荷の正体<br>
* CPuの実行権限が与えられるのを待っているプロセス<br>
* ディスクI/Oが完了するのを待っているプロセス</p>

<p>これはたしかに、直感と一致します。<br>
ディスクからデータを大量に読み出している間は、システムの反応がにぶくなったりします。</p>
</blockquote>

<h2>
<span id="まとめ" class="fragment"></span><a href="#%E3%81%BE%E3%81%A8%E3%82%81"><i class="fa fa-link"></i></a>まとめ</h2>

<ul>
<li>CPU使用率(us+sy)が高いとwa列が低くてもIO待ち少ないとは言い切れなさそう。ただ、waの値が高い状態は、そのまま単純にIO待ちが多いということを表している。</li>
<li>io待ちはvmstatの<code>b列</code>でみていくのもよさそう。waの値が低い場合にIO待ちは少ないとは言いきれないので。</li>
<li>CPU使用率が高いプロセスがいると待ち行列が長くなる確率が高くなる。</li>
<li>Load averageが高いとCPUがなかなか割り当てられない。

<ul>
<li>カーネルがプロセスをスケジューリング対象とするランキューには<code>TASK_RUNNING</code>しか存在せず、IO待ちプロセスは別のキューに存在するが、<code>TASK_UNINTERRUPTIBLE</code>状態が解除され、都度？ランキューに入り込んでくるので？その分のスケジューリング対象が増えCPUがなかなか割り当てられないことが増える？ので一見IO待ちが増えてもCPUはidleなのでシステムに負荷かかっていないように見えるが、LAが高いと(IO待ち含む)とCPUがなかなか割り当てられないので負荷がかかっているといえる？</li>
</ul>
</li>
</ul>


IO待ちメモ

## 概要
`kernel-headers`と`kernel-devel`を簡単に調べてみたので自分めも。

## まず
とあるCentOS6.8の初期minimalインストール後

```
# rpm -qa | grep kernel
dracut-kernel-004-409.el6_8.2.noarch
kernel-2.6.32-642.15.1.el6.x86_64
kernel-headers-2.6.32-642.15.1.el6.x86_64
kernel-firmware-2.6.32-642.15.1.el6.noarch
kernel-2.6.32-642.el6.x86_64
```


## kernel-headres
`rpm -qa | grep kernel`よりkernel-headersは最初からインストールされている

```
$ rpm -qi kernel-headers
・
・
Description :
Kernel-headers includes the C header files that specify the interface
between the Linux kernel and userspace libraries and programs.  The
header files define structures and constants that are needed for
building most standard programs and are also needed for rebuilding the
glibc package.
```
```
$ rpm -ql kernel-headers | more
/usr/include/asm
/usr/include/asm-generic
/usr/include/asm-generic/auxvec.h
/usr/include/asm-generic/bitsperlong.h
/usr/include/asm-generic/errno-base.h
/usr/include/asm-generic/errno.h
/usr/include/asm-generic/fcntl.h
/usr/include/asm-generic/int-l64.h
/usr/include/asm-generic/int-ll64.h
/usr/include/asm-generic/ioctl.h
/usr/include/asm-generic/ioctls.h
/usr/include/asm-generic/ipcbuf.h
・
・
```

/usr/includeに配置されている。説明通り/usr/include以下はユーザ側に提供しているファイルの集合。

### こんな感じ
* /usr/include
  - glibcから提供のヘッダファイル
* /usr/include/linux
  - カーネルソースコード由来のヘッダファイル
* /usr/include/sys
  - カーネルから提供(システムコールなど)
* /usr/include/net
  - ネットワーク関連

## kernel-devel
自分でインストールする必要あり

```
$ rpm -qi kernel-devel
・
・
Description :
This package provides kernel headers and makefiles sufficient to build modules
against the kernel package.
```
説明通りカーネルモジュールを作成するための十分なヘッダとmakeファイルがはいっている。.cも入っていたけど、これはカーネルソースとはまた異なるっぽい。kernel orgなどからダウンロードできるカーネルソース一式とは異なる。カーネルモジュールを作成ためのもの。




















<h2>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h2>

<p><code>kernel-headers</code>と<code>kernel-devel</code>を簡単に調べてみたので自分めも。</p>

<h2>
<span id="まず" class="fragment"></span><a href="#%E3%81%BE%E3%81%9A"><i class="fa fa-link"></i></a>まず</h2>

<p>とあるCentOS6.8の初期minimalインストール後</p>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code># rpm -qa | grep kernel
dracut-kernel-004-409.el6_8.2.noarch
kernel-2.6.32-642.15.1.el6.x86_64
kernel-headers-2.6.32-642.15.1.el6.x86_64
kernel-firmware-2.6.32-642.15.1.el6.noarch
kernel-2.6.32-642.el6.x86_64
</code></pre></div></div>

<h2>
<span id="kernel-headres" class="fragment"></span><a href="#kernel-headres"><i class="fa fa-link"></i></a>kernel-headres</h2>

<p><code>rpm -qa | grep kernel</code>よりkernel-headersは最初からインストールされている</p>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>$ rpm -qi kernel-headers
・
・
Description :
Kernel-headers includes the C header files that specify the interface
between the Linux kernel and userspace libraries and programs.  The
header files define structures and constants that are needed for
building most standard programs and are also needed for rebuilding the
glibc package.
</code></pre></div></div>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>$ rpm -ql kernel-headers | more
/usr/include/asm
/usr/include/asm-generic
/usr/include/asm-generic/auxvec.h
/usr/include/asm-generic/bitsperlong.h
/usr/include/asm-generic/errno-base.h
/usr/include/asm-generic/errno.h
/usr/include/asm-generic/fcntl.h
/usr/include/asm-generic/int-l64.h
/usr/include/asm-generic/int-ll64.h
/usr/include/asm-generic/ioctl.h
/usr/include/asm-generic/ioctls.h
/usr/include/asm-generic/ipcbuf.h
・
・
</code></pre></div></div>

<p>/usr/includeに配置されている。説明通り/usr/include以下はユーザ側に提供しているファイルの集合。</p>

<h3>
<span id="こんな感じ" class="fragment"></span><a href="#%E3%81%93%E3%82%93%E3%81%AA%E6%84%9F%E3%81%98"><i class="fa fa-link"></i></a>こんな感じ</h3>

<ul>
<li>/usr/include

<ul>
<li>glibcから提供のヘッダファイル</li>
</ul>
</li>
<li>/usr/include/linux

<ul>
<li>カーネルソースコード由来のヘッダファイル</li>
</ul>
</li>
<li>/usr/include/sys

<ul>
<li>カーネルから提供(システムコールなど)</li>
</ul>
</li>
<li>/usr/include/net

<ul>
<li>ネットワーク関連</li>
</ul>
</li>
</ul>

<h2>
<span id="kernel-devel" class="fragment"></span><a href="#kernel-devel"><i class="fa fa-link"></i></a>kernel-devel</h2>

<p>自分でインストールする必要あり</p>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>$ rpm -qi kernel-devel
・
・
Description :
This package provides kernel headers and makefiles sufficient to build modules
against the kernel package.
</code></pre></div></div>

<p>説明通りカーネルモジュールを作成するための十分なヘッダとmakeファイルがはいっている。.cも入っていたけど、これはカーネルソースとはまた異なるっぽい。kernel orgなどからダウンロードできるカーネルソース一式とは異なる。カーネルモジュールを作成ためのもの。</p>


kernel-headersとkernel-devel

VMSTATで表示される各時間の詳細を調べてみた

# 概要
pingの実装を通してプロセスの権限を勉強した備忘録。

# 疑問
pingコマンドはset-user-IDされているので一般ユーザーで実行した場合でも実効IDがrootで実行されるはずだと思っていた。ところがpsコマンドで確認したならば以下の様な結果になった。そう、実効IDが一般ユーザーで実行されていた。なぜだろう・・？

## /bin/ping
~~~
[root@localhost iputils-s20071127]# ll /bin/ping
-rwsr-xr-x. 1 root root 40760  9月 26 14:35 2013 /bin/ping
~~~
set-user-IDがセットされている。これを実行すると実効IDがrootでpingが実行されるはずだと思っていた・・

~~~
[vagrant@localhost ~]$ id
uid=500(vagrant) gid=500(vagrant) 所属グループ=500(vagrant)

[vagrant@localhost ~]$ /bin/ping 192.168.33.20
PING 192.168.33.20 (192.168.33.20) 56(84) bytes of data.
64 bytes from 192.168.33.20: icmp_seq=1 ttl=64 time=0.021 ms
64 bytes from 192.168.33.20: icmp_seq=2 ttl=64 time=0.034 ms
~~~
ping実行したまま、以下を実行

~~~
[vagrant@localhost net]$ ps -eo uid,euid,fuid,suid,command  | grep [p]ing
  500   500   500   500 ping 192.168.33.10
~~~
各IDを確認するとすべてvagrantユーザーの値に。pingはset-user-IDされたプログラムなのでrootの値になっているはず、しかしvagrantユーザーの値。なぜだろう？

## 試した環境
* Vagrant on Mac
* pingのソースコードが入っているsrpmを取得。

~~~sh
[root@localhost iputils-s20071127]# cat /etc/redhat-release
CentOS release 6.5 (Final)
[root@localhost iputils-s20071127]# which ping
/bin/ping
[root@localhost iputils-s20071127]# rpm -qf /bin/ping
iputils-20071127-17.el6_4.2.x86_64
[root@localhost iputils-s20071127]#
~~~

#　処理みてみた
pingのソースコード

```ping.c

int main(int argc, char **argv)
{
  .
  .
  . 
  icmp_sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);

  socket_errno = errno;

  uid = getuid();
  if (setuid(uid)) {
    perror("ping: setuid");
    exit(-1);
  }
  .
  .
  .
```

ソースコードを見ればわかりました。socketシステムコールを実行した後にgetuidで自プロセスの実ユーザーIDを取得して、setuidで自プロセスの実効ユーザーIDを変更しています。よってpsコマンドではsetuidされた後の値(vagrantユーザー)が見えていたわけです。

## CentOS7のPing
~~~
[root@localhost iputils-s20121221]# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
[root@localhost iputils-s20121221]# uname -r
3.10.0-229.el7.x86_64
[root@localhost iputils-s20121221]# which ping
/bin/ping
[root@localhost iputils-s20121221]# ll /bin/ping
-rwxr-xr-x. 1 root root 44896  6月 10  2014 /bin/ping
~~~

他にもcentos7の環境で見てみました。するとcentos7のping実行ファイルにはではケーパビリティのチェックをしていました。

~~~ping.c
        limit_capabilities();

#ifdef USE_IDN
        setlocale(LC_ALL, "");
#endif

        enable_capability_raw();

        icmp_sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);
        socket_errno = errno;

        disable_capability_raw();
~~~

socketシステムコールを実行するまえにenable_capability_raw()でCAP_NET_RAW権限だけを与えて、socketシステムコール後にdisable_capability_raw()で権限をクリアしていました。よってset-user-IDしていない実行ファイルでもsocketシステムコールを実行できているようです。しかしなぜcent6とcent7でpingの作りが違うのでしょうか？？んー、なぜでしょうか。両者を見るとcent７のほうが権限を最小化できているのでセキュリティ的に望ましいといえます。





# 関係ありそうなカーネルの処理をみてみた
カーネル:linux-2.6.32

## set-user-IDを実行ファイルから取得している箇所
sys_execve() → do_execve からの先で呼ばれている。

~~~fs/exec.c
/*
 * Fill the binprm structure from the inode.
 * Check permissions, then read the first 128 (BINPRM_BUF_SIZE) bytes
 *
 * This may be called multiple times for binary chains (scripts for example).
 */
int prepare_binprm(struct linux_binprm *bprm)
{
        umode_t mode;
        struct inode * inode = bprm->file->f_path.dentry->d_inode;
        int retval;

        mode = inode->i_mode;
        if (bprm->file->f_op == NULL)
                return -EACCES;

        /* clear any previous set[ug]id data from a previous binary */
        bprm->cred->euid = current_euid();
        bprm->cred->egid = current_egid();

        if (!(bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)) {
                /* Set-uid? */
                if (mode & S_ISUID) {
                        bprm->per_clear |= PER_CLEAR_ON_SETID;
                        bprm->cred->euid = inode->i_uid;
                }

                /* Set-gid? */
                /*
                 * If setgid is set but no group execute bit then this
                 * is a candidate for mandatory locking, not a setgid
                 * executable.
                 */
                if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
                        bprm->per_clear |= PER_CLEAR_ON_SETID;
                        bprm->cred->egid = inode->i_gid;
                }
        }

        /* fill in binprm security blob */
        retval = security_bprm_set_creds(bprm);
        if (retval)
                return retval;
        bprm->cred_prepared = 1;

        memset(bprm->buf, 0, BINPRM_BUF_SIZE);
        return kernel_read(bprm->file, 0, bprm->buf, BINPRM_BUF_SIZE);
}
~~~

linux_binprm

~~~include/linux/binfmts.h
/*
 * This structure is used to hold the arguments that are used when loading binaries.
 */
struct linux_binprm{
        char buf[BINPRM_BUF_SIZE];
#ifdef CONFIG_MMU
        struct vm_area_struct *vma;
#else
# define MAX_ARG_PAGES  32
        struct page *page[MAX_ARG_PAGES];
#endif
        struct mm_struct *mm;
        unsigned long p; /* current top of mem */
        unsigned int
                cred_prepared:1,/* true if creds already prepared (multiple
                                 * preps happen for interpreters) */
                cap_effective:1;/* true if has elevated effective capabilities,
                                 * false if not; except for init which inherits
                                 * its parent's caps anyway */
#ifdef __alpha__
        unsigned int taso:1;
#endif
        unsigned int recursion_depth;
        struct file * file;
        struct cred *cred;      /* new credentials */
        int unsafe;             /* how unsafe this exec is (mask of LSM_UNSAFE_*) */
        unsigned int per_clear; /* bits to clear in current->personality */
        int argc, envc;
        char * filename;        /* Name of binary as seen by procps */
        char * interp;          /* Name of the binary really executed. Most
                                   of the time same as filename, but could be
                                   different for binfmt_{misc,script} */
        unsigned interp_flags;
        unsigned interp_data;
        unsigned long loader, exec;
};
~~~
set-user-IDの値を取得してlinux_binprmの構造体に値を入れているようです。linux_binprmはコメントにかかれているように、execveする時の各種情報を入れる構造体みたいです。その後にsecurity_bprm_set_credsで権限のチェックをしているみたいでした(ケーパビリティも含む)。この先で通常ユーザーの実効IDをset-user-IDの値で権現の上書きをしているんでしょうか？？？security_bprm_set_credsの先はいつか読んでみたいと思います。

他にも関係ありそうな箇所を見てみました。

task_struc構造体からひも付く各ID。

~~~include/linux/cred.h
struct cred {
・
・
・
        uid_t           uid;            /* real UID of the task */
        gid_t           gid;            /* real GID of the task */
        uid_t           suid;           /* saved UID of the task */
        gid_t           sgid;           /* saved GID of the task */
        uid_t           euid;           /* effective UID of the task */
        gid_t           egid;           /* effective GID of the task */
        uid_t           fsuid;          /* UID for VFS ops */
        gid_t           fsgid;          /* GID for VFS ops */
        unsigned        securebits;     /* SUID-less security management 
・
・
・
}
~~~

どこかで使われていないかなーと思ってみてみました。do_execve()のさらに先でELF実行ファイルの場合にELFをメモリにロードする処理の途中で何か権限を挿入している処理がありました。

~~~fs/binfmt_elf.c
static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
                unsigned long load_addr, unsigned long interp_load_addr)
{
・
・
・
/* Create the ELF interpreter info */
        elf_info = (elf_addr_t *)current->mm->saved_auxv;
        /* update AT_VECTOR_SIZE_BASE if the number of NEW_AUX_ENT() changes */
#define NEW_AUX_ENT(id, val) \
        do { \
                elf_info[ei_index++] = id; \
                elf_info[ei_index++] = val; \
        } while (0)

#ifdef ARCH_DLINFO
        /*
         * ARCH_DLINFO must come first so PPC can do its special alignment of
         * AUXV.
         * update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT() in
         * ARCH_DLINFO changes
         */
        ARCH_DLINFO;
#endif
        NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
        NEW_AUX_ENT(AT_PAGESZ, ELF_EXEC_PAGESIZE);
        NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
        NEW_AUX_ENT(AT_PHDR, load_addr + exec->e_phoff);
        NEW_AUX_ENT(AT_PHENT, sizeof(struct elf_phdr));
        NEW_AUX_ENT(AT_PHNUM, exec->e_phnum);
        NEW_AUX_ENT(AT_BASE, interp_load_addr);
        NEW_AUX_ENT(AT_FLAGS, 0);
        NEW_AUX_ENT(AT_ENTRY, exec->e_entry);
        NEW_AUX_ENT(AT_UID, cred->uid);
        NEW_AUX_ENT(AT_EUID, cred->euid);
        NEW_AUX_ENT(AT_GID, cred->gid);
        NEW_AUX_ENT(AT_EGID, cred->egid);
        NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
        NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
        NEW_AUX_ENT(AT_EXECFN, bprm->exec);
・
・
・
}
~~~
ELF interpreter infoにNEW_AUX_ENTマクロを使用して各IDを挿入していました。この領域はユーザースタックの環境変数へのポインタが入っている配列の直前に置かれるようです。これは一体なんなのでしょうか？？実はプログラムを実行する時カーネルでexec処理するんですが最終的にカーネルではIPの値としてその実行ファイルの動的リンカのエントリポイントが挿入されます。動的リンカが実行ファイルの共有ライブラリをリンクして、実行ファイルのエントリポイントを設定する流れです。色々調べると動的リンカがこの領域を取得しているようでした。わざわざ各IDもここに挿入されているということはきっと何かに使われているのだと思います。何に使われているのかは調べていません。いつか調べられたらと思います。









プロセス権限

## 概要
macbookにCentOS7 in Vagrant環境を構築してそのCentOSの中でdockerを試してみた。普段GHEで業務しているのでDockerHubとかの関連性は理解しやすかったです。

## やったこと
### dockerHubの登録
* https://hub.docker.com/
* パブリックリポジトリ作成

### いろいろDockerコマンド叩く
#### いろいろ
* リポジトリの検索
  - `docker search 検索名`
  - webのdockerhubから検索してくれる
* リポジトリのDL
  - `docker pull -a username/リポジトリ`
  - aはすべてのバージョンをダウンロード
* ローカルにあるリポジトリ一覧
  - `docker images`
  - ダウンロードしたり作成したリポジトリの一覧
*  スナップショットの複製
  - `docker commit コンテナ名 username/リポジトリ名:tag`
* dockerHubへのログイン
  - `docker login`
* dockerHubへのpush 
  - `docker push username/リポジトリ名`
* コンテナ情報の表示。停止中も含む。  
  - `docker ps -a`

#### コンテナー
* コンテナイメージ作成
  - `docker build -t username/リポジトリ名:tag Dockerfileの場所`
* コンテナの起動
  - `docker run -it --name コンテナの名前 username/リポジトリ:tag シェル`
  - コンテナ起動時にスナップショットを作成するみたい。このスナップショットがルートファイル・システムだと理解
* コンテナ接続
  - `docker attach コンテナ名`
* コンテナ停止
  - `docker stop コンテナ名`
* コンテナの再起動
  - `docker start コンテナ名`
* コンテナ破棄
  - `docker rm コンテナ名`

#### コマンド実行
* コンテナに接続しないでコマンドを実行
  - `docker exec コンテナ名 実行したいコマンド`

#### プライベートリポジトリ作成
  * 複製でプライベートリポジトリ用を作成
    - `docker commit コンテナ名 IP:Port/username/リポジトリ名:tag`

#### Dockerfile
  * コンテナイメージの作成手順を記載したファイル
  * これと合わせて実際にコンテナで使用するファイルを準備して、Dockerfileと同じディレクトリに入れる必要がある。

#### わかったこと
* コンテナイメージはコンテナのルートファイル・システムになる
* DockerHubはコンテナイメージを管理。各ユーザのリポジトリにはコンテナイメージの複数のバージョンがある。各バージョンにはタグ名で管理されている。
* 上で作成したコンテナではシェルしか動いていなかった。OSなしどころかシェルのみ。このあたりはDockerが各プロセスの名前空間をうまく使用して管理しているはず。
* 参照
  - [PID名前空間](http://qiita.com/saikoro-steak/items/382152b09d90507612f0)
  - [マウントと名前空間めもめも](http://qiita.com/saikoro-steak/items/b36129bdf79645c91fe7)
* 図↓みたいなかんじ
![image](https://qiita-image-store.s3.amazonaws.com/0/91729/15a9a1d8-3d53-d292-fdba-fcc62e9d6a72.png)



<h2>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h2>

<p>macbookにCentOS7 in Vagrant環境を構築してそのCentOSの中でdockerを試してみた。普段GHEで業務しているのでDockerHubとかの関連性は理解しやすかったです。</p>

<h2>
<span id="やったこと" class="fragment"></span><a href="#%E3%82%84%E3%81%A3%E3%81%9F%E3%81%93%E3%81%A8"><i class="fa fa-link"></i></a>やったこと</h2>

<h3>
<span id="dockerhubの登録" class="fragment"></span><a href="#dockerhub%E3%81%AE%E7%99%BB%E9%8C%B2"><i class="fa fa-link"></i></a>dockerHubの登録</h3>

<ul>
<li><a href="https://hub.docker.com/" class="autolink" rel="nofollow noopener" target="_blank">https://hub.docker.com/</a></li>
<li>パブリックリポジトリ作成</li>
</ul>

<h3>
<span id="いろいろdockerコマンド叩く" class="fragment"></span><a href="#%E3%81%84%E3%82%8D%E3%81%84%E3%82%8Ddocker%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E5%8F%A9%E3%81%8F"><i class="fa fa-link"></i></a>いろいろDockerコマンド叩く</h3>

<h4>
<span id="いろいろ" class="fragment"></span><a href="#%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D"><i class="fa fa-link"></i></a>いろいろ</h4>

<ul>
<li>リポジトリの検索

<ul>
<li><code>docker search 検索名</code></li>
<li>webのdockerhubから検索してくれる</li>
</ul>
</li>
<li>リポジトリのDL

<ul>
<li><code>docker pull -a username/リポジトリ</code></li>
<li>aはすべてのバージョンをダウンロード</li>
</ul>
</li>
<li>ローカルにあるリポジトリ一覧

<ul>
<li><code>docker images</code></li>
<li>ダウンロードしたり作成したリポジトリの一覧</li>
</ul>
</li>
<li> スナップショットの複製

<ul>
<li><code>docker commit コンテナ名 username/リポジトリ名:tag</code></li>
</ul>
</li>
<li>dockerHubへのログイン

<ul>
<li><code>docker login</code></li>
</ul>
</li>
<li>dockerHubへのpush 

<ul>
<li><code>docker push username/リポジトリ名</code></li>
</ul>
</li>
<li>コンテナ情報の表示。停止中も含む。<br>

<ul>
<li><code>docker ps -a</code></li>
</ul>
</li>
</ul>

<h4>
<span id="コンテナー" class="fragment"></span><a href="#%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%83%BC"><i class="fa fa-link"></i></a>コンテナー</h4>

<ul>
<li>コンテナイメージ作成

<ul>
<li><code>docker build -t username/リポジトリ名:tag Dockerfileの場所</code></li>
</ul>
</li>
<li>コンテナの起動

<ul>
<li><code>docker run -it --name コンテナの名前 username/リポジトリ:tag シェル</code></li>
<li>コンテナ起動時にスナップショットを作成するみたい。このスナップショットがルートファイル・システムだと理解</li>
</ul>
</li>
<li>コンテナ接続

<ul>
<li><code>docker attach コンテナ名</code></li>
</ul>
</li>
<li>コンテナ停止

<ul>
<li><code>docker stop コンテナ名</code></li>
</ul>
</li>
<li>コンテナの再起動

<ul>
<li><code>docker start コンテナ名</code></li>
</ul>
</li>
<li>コンテナ破棄

<ul>
<li><code>docker rm コンテナ名</code></li>
</ul>
</li>
</ul>

<h4>
<span id="コマンド実行" class="fragment"></span><a href="#%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E5%AE%9F%E8%A1%8C"><i class="fa fa-link"></i></a>コマンド実行</h4>

<ul>
<li>コンテナに接続しないでコマンドを実行

<ul>
<li><code>docker exec コンテナ名 実行したいコマンド</code></li>
</ul>
</li>
</ul>

<h4>
<span id="プライベートリポジトリ作成" class="fragment"></span><a href="#%E3%83%97%E3%83%A9%E3%82%A4%E3%83%99%E3%83%BC%E3%83%88%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E4%BD%9C%E6%88%90"><i class="fa fa-link"></i></a>プライベートリポジトリ作成</h4>

<ul>
<li>複製でプライベートリポジトリ用を作成

<ul>
<li><code>docker commit コンテナ名 IP:Port/username/リポジトリ名:tag</code></li>
</ul>
</li>
</ul>

<h4>
<span id="dockerfile" class="fragment"></span><a href="#dockerfile"><i class="fa fa-link"></i></a>Dockerfile</h4>

<ul>
<li>コンテナイメージの作成手順を記載したファイル</li>
<li>これと合わせて実際にコンテナで使用するファイルを準備して、Dockerfileと同じディレクトリに入れる必要がある。</li>
</ul>

<h4>
<span id="わかったこと" class="fragment"></span><a href="#%E3%82%8F%E3%81%8B%E3%81%A3%E3%81%9F%E3%81%93%E3%81%A8"><i class="fa fa-link"></i></a>わかったこと</h4>

<ul>
<li>コンテナイメージはコンテナのルートファイル・システムになる</li>
<li>DockerHubはコンテナイメージを管理。各ユーザのリポジトリにはコンテナイメージの複数のバージョンがある。各バージョンにはタグ名で管理されている。</li>
<li>上で作成したコンテナではシェルしか動いていなかった。OSなしどころかシェルのみ。このあたりはDockerが各プロセスの名前空間をうまく使用して管理しているはず。</li>
<li>参照

<ul>
<li><a href="http://qiita.com/saikoro-steak/items/382152b09d90507612f0" id="reference-3a07f691b125785b8564">PID名前空間</a></li>
<li><a href="http://qiita.com/saikoro-steak/items/b36129bdf79645c91fe7" id="reference-54259101ebc6a5af66fb">マウントと名前空間めもめも</a></li>
</ul>
</li>
<li>図↓みたいなかんじ
<a href="https://camo.qiitausercontent.com/843e94de012790794ccb7869d665c756c711f0de/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f39313732392f31356139613164382d336435332d643239322d666462612d6663633632653964366137322e706e67" target="_blank" rel="nofollow noopener"><img src="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F91729%2F15a9a1d8-3d53-d292-fdba-fcc62e9d6a72.png?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;s=92bd8a5bd3a9e192807e9593b16279e8" alt="image" data-canonical-src="https://qiita-image-store.s3.amazonaws.com/0/91729/15a9a1d8-3d53-d292-fdba-fcc62e9d6a72.png" srcset="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F91729%2F15a9a1d8-3d53-d292-fdba-fcc62e9d6a72.png?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;w=1400&amp;fit=max&amp;s=029a7ef9ae6ec463b701b72cf98c5a63 1x" loading="lazy"></a>
</li>
</ul>


Dockerを触ってみた

### 概要
cgroupのことについて調べたら、PID名前空間ってどこにあるんだろうって思って調べた自分メモメモ。なーんとなくしかわかっていないと思われるが、あたらずとも遠からずかなぁm(_ _)m。

#### pidとupid
プロセスIDは1234みたいにプロセスを一意に識別するただの番号に思えるが意外と単純でなく、カーネルでは多様なメンバで構成された構造体(pidとupid)の関連で表現されている。
↓
[pidとupid](http://lxr.free-electrons.com/source/include/linux/pid.h#L50)

~~~include/linux/pid.h
 50 struct upid {
 51         /* Try to keep pid_chain in the same cacheline as nr for find_vpid */
 52         int nr;
 53         struct pid_namespace *ns;
 54         struct hlist_node pid_chain;
 55 };
 56 
 57 struct pid
 58 {
 59         atomic_t count;
 60         unsigned int level;
 61         /* lists of tasks that use this pid */
 62         struct hlist_head tasks[PIDTYPE_MAX];
 63         struct rcu_head rcu;
 64         struct upid numbers[1];
 65 };
~~~

task_strcut->pidから辿れる。upid->nrがプロセス番号。pid->numbers[1]は可変配列みたいになっていて拡張可能でここが`プロセスの階層を表わしている`ようだ(たぶｎ)。これのMAXはどこかでdefineされていて32個まで名前空間の階層は作成できるみたい。なのでプロセスの名前空間は32個しかもてない？プロセスはどこかの階層に属していてこの階層が親子の上下関係を表わしているでいいのかな？？
[ネストされた名前空間](https://linuxjm.osdn.jp/html/LDP_man-pages/man7/pid_namespaces.7.html)
>プロセスは、所属する PID 名前空間の他のプロセスから見える。また、 root PID 名>前空間に向かう直径の先祖の各 PID 名前空間のプロセスからも見える。 この場合、「見える」とは、 あるプロセスが、 他のプロセスがプロセス ID を指定するシステムコール>を使う際に操作の対象にできることを意味する。 逆に、子供 PID 名前空間のプロセスか>ら親や先祖の名前空間のプロセスは見えない。 

[pidとupidの初期化](http://lxr.free-electrons.com/source/kernel/pid.c?v=4.1#L312)はこのalloc_pid()でしていて、後述するtask_struct->nsproxy->pid_namespace(自分が所属している名前空間)からlevel(階層)を取得してそこから上に向かって各階層で自分のプロセス番号を設定している。すべての階層で自分のプロセス番号を取得して設定するが、結果として返すプロセス番号(nr)は自分が所属しているプロセス空間のプロセス番号(nr)になる。このプロセス番号はこの階層でしか一意でなく、よって他の階層だとプロセス番号はかぶることがある。

#### pid_namespace

~~~Linux/include/linux/pid_namespace.h
 24 struct pid_namespace {
 25         struct kref kref;
 26         struct pidmap pidmap[PIDMAP_ENTRIES];
 27         struct rcu_head rcu;
 28         int last_pid;
 29         unsigned int nr_hashed;
 30         struct task_struct *child_reaper;
 31         struct kmem_cache *pid_cachep;
 32         unsigned int level;
 33         struct pid_namespace *parent;
 34 #ifdef CONFIG_PROC_FS
 35         struct vfsmount *proc_mnt;
 36         struct dentry *proc_self;
 37         struct dentry *proc_thread_self;
 38 #endif
 39 #ifdef CONFIG_BSD_PROCESS_ACCT
 40         struct fs_pin *bacct;
 41 #endif
 42         struct user_namespace *user_ns;
 43         struct work_struct proc_work;
 44         kgid_t pid_gid;
 45         int hide_pid;
 46         int reboot;     /* group exit code if this pidns was rebooted */
 47         struct ns_common ns;
 48 };
~~~
[task_strcut->nsproxy](http://lxr.free-electrons.com/source/include/linux/sched.h#L1562)から上記のpid_namespaceが辿れてプロセスを生成するときに初期化されるようだ。初期化するときにcloneで`CLONE_NEWPID`が指定されていると、このnsproxyが新規のものにとって変わられる[ここで](http://lxr.free-electrons.com/source/kernel/nsproxy.c?v=4.1#L124)。
task_struct->nsproxy->pid_namespaceはこのプロセスが所属している名前空間を表わしている。`pid_namespace->level`は階層。前述したpid->numbers[level]と対応している(たぶん)。

#### 順番
まず、プロセスを生成するときにtask_struct->nsproxyを初期化して、自分の所属する名前空間を割り出して(level)、そこを起点として上にたどっていきtask_struct->pid->upidを初期化する。

#### 参考
詳しくは[こちら](http://kernhack.hatenablog.com/entry/2016/01/11/163152)をご参照ください






<h3>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h3>

<p>cgroupのことについて調べたら、PID名前空間ってどこにあるんだろうって思って調べた自分メモメモ。なーんとなくしかわかっていないと思われるが、あたらずとも遠からずかなぁm(_ _)m。</p>

<h4>
<span id="pidとupid" class="fragment"></span><a href="#pid%E3%81%A8upid"><i class="fa fa-link"></i></a>pidとupid</h4>

<p>プロセスIDは1234みたいにプロセスを一意に識別するただの番号に思えるが意外と単純でなく、カーネルでは多様なメンバで構成された構造体(pidとupid)の関連で表現されている。<br>
↓<br>
<a href="http://lxr.free-electrons.com/source/include/linux/pid.h#L50" rel="nofollow noopener" target="_blank">pidとupid</a></p>

<div class="code-frame" data-lang="c">
<div class="code-lang"><span class="bold">include/linux/pid.h</span></div>
<div class="highlight"><pre><code> <span class="mi">50</span> <span class="k">struct</span> <span class="n">upid</span> <span class="p">{</span>
 <span class="mi">51</span>         <span class="cm">/* Try to keep pid_chain in the same cacheline as nr for find_vpid */</span>
 <span class="mi">52</span>         <span class="kt">int</span> <span class="n">nr</span><span class="p">;</span>
 <span class="mi">53</span>         <span class="k">struct</span> <span class="n">pid_namespace</span> <span class="o">*</span><span class="n">ns</span><span class="p">;</span>
 <span class="mi">54</span>         <span class="k">struct</span> <span class="n">hlist_node</span> <span class="n">pid_chain</span><span class="p">;</span>
 <span class="mi">55</span> <span class="p">};</span>
 <span class="mi">56</span> 
 <span class="mi">57</span> <span class="k">struct</span> <span class="n">pid</span>
 <span class="mi">58</span> <span class="p">{</span>
 <span class="mi">59</span>         <span class="n">atomic_t</span> <span class="n">count</span><span class="p">;</span>
 <span class="mi">60</span>         <span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">level</span><span class="p">;</span>
 <span class="mi">61</span>         <span class="cm">/* lists of tasks that use this pid */</span>
 <span class="mi">62</span>         <span class="k">struct</span> <span class="n">hlist_head</span> <span class="n">tasks</span><span class="p">[</span><span class="n">PIDTYPE_MAX</span><span class="p">];</span>
 <span class="mi">63</span>         <span class="k">struct</span> <span class="n">rcu_head</span> <span class="n">rcu</span><span class="p">;</span>
 <span class="mi">64</span>         <span class="k">struct</span> <span class="n">upid</span> <span class="n">numbers</span><span class="p">[</span><span class="mi">1</span><span class="p">];</span>
 <span class="mi">65</span> <span class="p">};</span>
</code></pre></div>
</div>

<p>task_strcut-&gt;pidから辿れる。upid-&gt;nrがプロセス番号。pid-&gt;numbers[1]は可変配列みたいになっていて拡張可能でここが<code>プロセスの階層を表わしている</code>ようだ(たぶｎ)。これのMAXはどこかでdefineされていて32個まで名前空間の階層は作成できるみたい。なのでプロセスの名前空間は32個しかもてない？プロセスはどこかの階層に属していてこの階層が親子の上下関係を表わしているでいいのかな？？<br>
<a href="https://linuxjm.osdn.jp/html/LDP_man-pages/man7/pid_namespaces.7.html" rel="nofollow noopener" target="_blank">ネストされた名前空間</a></p>

<blockquote>
<p>プロセスは、所属する PID 名前空間の他のプロセスから見える。また、 root PID 名&gt;前空間に向かう直径の先祖の各 PID 名前空間のプロセスからも見える。 この場合、「見える」とは、 あるプロセスが、 他のプロセスがプロセス ID を指定するシステムコール&gt;を使う際に操作の対象にできることを意味する。 逆に、子供 PID 名前空間のプロセスか&gt;ら親や先祖の名前空間のプロセスは見えない。 </p>
</blockquote>

<p><a href="http://lxr.free-electrons.com/source/kernel/pid.c?v=4.1#L312" rel="nofollow noopener" target="_blank">pidとupidの初期化</a>はこのalloc_pid()でしていて、後述するtask_struct-&gt;nsproxy-&gt;pid_namespace(自分が所属している名前空間)からlevel(階層)を取得してそこから上に向かって各階層で自分のプロセス番号を設定している。すべての階層で自分のプロセス番号を取得して設定するが、結果として返すプロセス番号(nr)は自分が所属しているプロセス空間のプロセス番号(nr)になる。このプロセス番号はこの階層でしか一意でなく、よって他の階層だとプロセス番号はかぶることがある。</p>

<h4>
<span id="pid_namespace" class="fragment"></span><a href="#pid_namespace"><i class="fa fa-link"></i></a>pid_namespace</h4>

<div class="code-frame" data-lang="c">
<div class="code-lang"><span class="bold">Linux/include/linux/pid_namespace.h</span></div>
<div class="highlight"><pre><code> <span class="mi">24</span> <span class="k">struct</span> <span class="n">pid_namespace</span> <span class="p">{</span>
 <span class="mi">25</span>         <span class="k">struct</span> <span class="n">kref</span> <span class="n">kref</span><span class="p">;</span>
 <span class="mi">26</span>         <span class="k">struct</span> <span class="n">pidmap</span> <span class="n">pidmap</span><span class="p">[</span><span class="n">PIDMAP_ENTRIES</span><span class="p">];</span>
 <span class="mi">27</span>         <span class="k">struct</span> <span class="n">rcu_head</span> <span class="n">rcu</span><span class="p">;</span>
 <span class="mi">28</span>         <span class="kt">int</span> <span class="n">last_pid</span><span class="p">;</span>
 <span class="mi">29</span>         <span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">nr_hashed</span><span class="p">;</span>
 <span class="mi">30</span>         <span class="k">struct</span> <span class="n">task_struct</span> <span class="o">*</span><span class="n">child_reaper</span><span class="p">;</span>
 <span class="mi">31</span>         <span class="k">struct</span> <span class="n">kmem_cache</span> <span class="o">*</span><span class="n">pid_cachep</span><span class="p">;</span>
 <span class="mi">32</span>         <span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">level</span><span class="p">;</span>
 <span class="mi">33</span>         <span class="k">struct</span> <span class="n">pid_namespace</span> <span class="o">*</span><span class="n">parent</span><span class="p">;</span>
 <span class="mi">34</span> <span class="err">#</span><span class="n">ifdef</span> <span class="n">CONFIG_PROC_FS</span>
 <span class="mi">35</span>         <span class="k">struct</span> <span class="n">vfsmount</span> <span class="o">*</span><span class="n">proc_mnt</span><span class="p">;</span>
 <span class="mi">36</span>         <span class="k">struct</span> <span class="n">dentry</span> <span class="o">*</span><span class="n">proc_self</span><span class="p">;</span>
 <span class="mi">37</span>         <span class="k">struct</span> <span class="n">dentry</span> <span class="o">*</span><span class="n">proc_thread_self</span><span class="p">;</span>
 <span class="mi">38</span> <span class="err">#</span><span class="n">endif</span>
 <span class="mi">39</span> <span class="err">#</span><span class="n">ifdef</span> <span class="n">CONFIG_BSD_PROCESS_ACCT</span>
 <span class="mi">40</span>         <span class="k">struct</span> <span class="n">fs_pin</span> <span class="o">*</span><span class="n">bacct</span><span class="p">;</span>
 <span class="mi">41</span> <span class="err">#</span><span class="n">endif</span>
 <span class="mi">42</span>         <span class="k">struct</span> <span class="n">user_namespace</span> <span class="o">*</span><span class="n">user_ns</span><span class="p">;</span>
 <span class="mi">43</span>         <span class="k">struct</span> <span class="n">work_struct</span> <span class="n">proc_work</span><span class="p">;</span>
 <span class="mi">44</span>         <span class="n">kgid_t</span> <span class="n">pid_gid</span><span class="p">;</span>
 <span class="mi">45</span>         <span class="kt">int</span> <span class="n">hide_pid</span><span class="p">;</span>
 <span class="mi">46</span>         <span class="kt">int</span> <span class="n">reboot</span><span class="p">;</span>     <span class="cm">/* group exit code if this pidns was rebooted */</span>
 <span class="mi">47</span>         <span class="k">struct</span> <span class="n">ns_common</span> <span class="n">ns</span><span class="p">;</span>
 <span class="mi">48</span> <span class="p">};</span>
</code></pre></div>
</div>

<p><a href="http://lxr.free-electrons.com/source/include/linux/sched.h#L1562" rel="nofollow noopener" target="_blank">task_strcut-&gt;nsproxy</a>から上記のpid_namespaceが辿れてプロセスを生成するときに初期化されるようだ。初期化するときにcloneで<code>CLONE_NEWPID</code>が指定されていると、このnsproxyが新規のものにとって変わられる<a href="http://lxr.free-electrons.com/source/kernel/nsproxy.c?v=4.1#L124" rel="nofollow noopener" target="_blank">ここで</a>。<br>
task_struct-&gt;nsproxy-&gt;pid_namespaceはこのプロセスが所属している名前空間を表わしている。<code>pid_namespace-&gt;level</code>は階層。前述したpid-&gt;numbers[level]と対応している(たぶん)。</p>

<h4>
<span id="順番" class="fragment"></span><a href="#%E9%A0%86%E7%95%AA"><i class="fa fa-link"></i></a>順番</h4>

<p>まず、プロセスを生成するときにtask_struct-&gt;nsproxyを初期化して、自分の所属する名前空間を割り出して(level)、そこを起点として上にたどっていきtask_struct-&gt;pid-&gt;upidを初期化する。</p>

<h4>
<span id="参考" class="fragment"></span><a href="#%E5%8F%82%E8%80%83"><i class="fa fa-link"></i></a>参考</h4>

<p>詳しくは<a href="http://kernhack.hatenablog.com/entry/2016/01/11/163152" rel="nofollow noopener" target="_blank">こちら</a>をご参照ください</p>


PID名前空間

#### 概要
curlでhttps通信したときに、そういえばhttps通信ってどういう仕組みだったっけー忘れたーと思ったのでいろいろ思い出してみたので簡単にめもめも。

#### 登場人物
* 認証局(CA)
* サーバー
* クライアント

#### いろいろ用語
* SSL
  - 米ネットスケープ社が開発
* TLS
  - SSLが普及しだした時にIETFがSSLを元にしてTLSとして標準仕様にする
  - SSLが先に普及したので、TLSのことをSSLと表記したりSSL/TLSと併記したりする
* サーバー証明書
  - 証明書データを`CAの秘密鍵でハッシュ化された署名`が含まれている
  - サーバーの`公開鍵`が含まれている。
* 認証局(CA)
  - 電子商取引事業者などに、暗号通信などで必要となるデジタル証明書を発行する機関
* CA証明書
  - ブラウザには最初っから入っている。CAの公開鍵が含まれている
* クライアント
  - 主にブラウザなど
  - ブラウザには主要な認証局の証明書(公開鍵)が登録されている。

#### 通信の流れ
* サーバー準備
  - サーバーはCAに申請してサーバーの公開鍵が含まれたサーバー証明書を作成してもらう。
* サーバー認証
  - クライアントから通信くると上で作成したサーバー証明書をクライアントに送付
  - クライアントではサーバー証明書に含まれる署名からCA証明書の公開鍵でハッシュ値を抽出してサーバー証明書データのハッシュ値と比較する。値が同じであれば信頼のあるCAから生成されたサーバー証明書であり、そこで発行されたサーバー証明書は正当なものだと判断できサーバー証明書に含まれている`サーバーの公開鍵`の信頼性が担保される。
* 通信内容の暗号化
  - 公開鍵と秘密鍵から生成したお互いしか知り得ない`共通鍵`で通信
* 完全性の確認
  - [電子証明書](http://esac.jipdec.or.jp/intro/shikumi.html)のような仕組みで改ざんがないかチェックする

#### おわり
最初だけ`公開鍵`と`秘密鍵`(公開鍵暗号)を使用して通信自体は`共通鍵`(共通鍵暗号)で行う。なぜかというと、公開鍵暗号のほうが負荷が大きいので。公開鍵暗号は認証などの場面でしか使用されない。




<h4>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h4>

<p>curlでhttps通信したときに、そういえばhttps通信ってどういう仕組みだったっけー忘れたーと思ったのでいろいろ思い出してみたので簡単にめもめも。</p>

<h4>
<span id="登場人物" class="fragment"></span><a href="#%E7%99%BB%E5%A0%B4%E4%BA%BA%E7%89%A9"><i class="fa fa-link"></i></a>登場人物</h4>

<ul>
<li>認証局(CA)</li>
<li>サーバー</li>
<li>クライアント</li>
</ul>

<h4>
<span id="いろいろ用語" class="fragment"></span><a href="#%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%94%A8%E8%AA%9E"><i class="fa fa-link"></i></a>いろいろ用語</h4>

<ul>
<li>SSL

<ul>
<li>米ネットスケープ社が開発</li>
</ul>
</li>
<li>TLS

<ul>
<li>SSLが普及しだした時にIETFがSSLを元にしてTLSとして標準仕様にする</li>
<li>SSLが先に普及したので、TLSのことをSSLと表記したりSSL/TLSと併記したりする</li>
</ul>
</li>
<li>サーバー証明書

<ul>
<li>証明書データを<code>CAの秘密鍵でハッシュ化された署名</code>が含まれている</li>
<li>サーバーの<code>公開鍵</code>が含まれている。</li>
</ul>
</li>
<li>認証局(CA)

<ul>
<li>電子商取引事業者などに、暗号通信などで必要となるデジタル証明書を発行する機関</li>
</ul>
</li>
<li>CA証明書

<ul>
<li>ブラウザには最初っから入っている。CAの公開鍵が含まれている</li>
</ul>
</li>
<li>クライアント

<ul>
<li>主にブラウザなど</li>
<li>ブラウザには主要な認証局の証明書(公開鍵)が登録されている。</li>
</ul>
</li>
</ul>

<h4>
<span id="通信の流れ" class="fragment"></span><a href="#%E9%80%9A%E4%BF%A1%E3%81%AE%E6%B5%81%E3%82%8C"><i class="fa fa-link"></i></a>通信の流れ</h4>

<ul>
<li>サーバー準備

<ul>
<li>サーバーはCAに申請してサーバーの公開鍵が含まれたサーバー証明書を作成してもらう。</li>
</ul>
</li>
<li>サーバー認証

<ul>
<li>クライアントから通信くると上で作成したサーバー証明書をクライアントに送付</li>
<li>クライアントではサーバー証明書に含まれる署名からCA証明書の公開鍵でハッシュ値を抽出してサーバー証明書データのハッシュ値と比較する。値が同じであれば信頼のあるCAから生成されたサーバー証明書であり、そこで発行されたサーバー証明書は正当なものだと判断できサーバー証明書に含まれている<code>サーバーの公開鍵</code>の信頼性が担保される。</li>
</ul>
</li>
<li>通信内容の暗号化

<ul>
<li>公開鍵と秘密鍵から生成したお互いしか知り得ない<code>共通鍵</code>で通信</li>
</ul>
</li>
<li>完全性の確認

<ul>
<li>
<a href="http://esac.jipdec.or.jp/intro/shikumi.html" rel="nofollow noopener" target="_blank">電子証明書</a>のような仕組みで改ざんがないかチェックする</li>
</ul>
</li>
</ul>

<h4>
<span id="おわり" class="fragment"></span><a href="#%E3%81%8A%E3%82%8F%E3%82%8A"><i class="fa fa-link"></i></a>おわり</h4>

<p>最初だけ<code>公開鍵</code>と<code>秘密鍵</code>(公開鍵暗号)を使用して通信自体は<code>共通鍵</code>(共通鍵暗号)で行う。なぜかというと、公開鍵暗号のほうが負荷が大きいので。公開鍵暗号は認証などの場面でしか使用されない。</p>


httpsのサーバー認証

# 概要
* システムコールをいろいろ調べてみたので、自分の言葉で用語をまとめてみた。
* **修正しました(2017/4/25)**

# システムコール
## 種類
* i386
    - AMD
        - INT $0x80/iret
        - syscall/sysret(古いと使えないものもある)
    - Intel
        - INT $0x80/iret
        - sysenter/sysexit(古いと使えないものもある)
* x86_64
    - AMD
        - INT $0x80/iret
        - syscall/sysret 
    - Intel
        - INT $0x80/iret
        - sysenter/sysexit
        - syscall/sysret

## 特徴
+ INT $0x80/iret
    * ソフトウェア割り込み発生させる。システムコールに特化していないのでsysenter、syscallよりオーバーヘッドがある
    * 昔からある方法なのでほとんどのCPUは対応している？？
+ sysenter/sysexitとsyscall/sysret
    * システムコール専用に特化していてint命令より負荷は軽い。

**x86_64の場合、カーネルはsyscall命令を使うだけでよい。i386の場合、カーネルはCPUの種別によって`INT $0x80/iret`、`sysenter/sysexit`、`syscall/sysret`を選択しなければいけない**




# システムコール呼び出し詳細
## i386
* ユーザプログラム → glibc(**__kernel_vsyscall**)　→ **VDSO**(vsyscallの番地にCPU種別にあったシステムコール命令が配置されている) → **カーネル**
* ユーザプログラム → glibc → **VDSO**(gettimeofday、time、getcpu、clock_gettime)

ユーザプログラムは__kernel_vsyscallという関数を使うようになっています。

VDSOの初期化中にvsyscallの中身を設定しているので、vsyscallもVDSOの仕組みの一つとして解釈しています。**すみません、よくわかっていません。。**以降もその体で説明しています。

vsyscallは固定アドレスに配置してあり、vdsoは毎回ランダムな番地に配置されるようです。

```bash
# cat /proc/2227/maps | tail
7f3f48570000-7f3f4859e000 rw-p 003a1000 fd:00 2361898                    /usr/libexec/qemu-kvm
7f3f4859e000-7f3f48985000 rw-p 00000000 00:00 0 
7f3f49dac000-7f3f4da0f000 rw-p 00000000 00:00 0 
7f3f4da0f000-7f3f4da1f000 rw-p 00000000 00:00 0 
7f3f4da1f000-7f3f4da39000 rw-p 00000000 00:00 0 
7f3f4da39000-7f3f4da49000 rw-p 00000000 00:00 0 
7f3f4da49000-7f3f5e3d4000 rw-p 00000000 00:00 0 
7fffd139f000-7fffd13b4000 rw-p 00000000 00:00 0                          [stack]
7fffd13c0000-7fffd13c1000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
```


http://postd.cc/the-definitive-guide-to-linux-system-calls/#kernelvsyscall-internals
> 結局、__kernel_vsyscallは、プログラムがユーザ空間でカーネルのコードを実行できるようにするために存在している仮想動的共有オブジェクト（vDSO）と呼ばれるものの一部なのです。


__kernel_vsyscallは、の一部。

リンカスクリプト。

```arch/x86/vdso/vdso32/vdso32.lds.S
/*
 * Linker script for 32-bit vDSO.
 * We #include the file to define the layout details.
 * Here we only choose the prelinked virtual address.
 *
 * This file defines the version script giving the user-exported symbols in
 * the DSO.  We can define local symbols here called VDSO* to make their
 * values visible using the asm-x86/vdso.h macros from the kernel proper.
 */

#define VDSO_PRELINK 0
#include "../vdso-layout.lds.S"

/* The ELF entry point can be used to set the AT_SYSINFO value.  */
ENTRY(__kernel_vsyscall);

/*
 * This controls what userland symbols we export from the vDSO.
 */
VERSION
{
        LINUX_2.5 {
        global:
                __kernel_vsyscall;
                __kernel_sigreturn;
                __kernel_rt_sigreturn;
        local: *;
        };
}

/*
 * Symbols we define here called VDSO* get their values into vdso32-syms.h.
 */
VDSO32_PRELINK          = VDSO_PRELINK;
VDSO32_vsyscall         = __kernel_vsyscall;
VDSO32_sigreturn        = __kernel_sigreturn;
VDSO32_rt_sigreturn     = __kernel_rt_sigreturn;
```

glibcは**__kernel_vsyscall**の番地を知る必要がある。x86_64と同様にユーザースタックから取ってきている様子。glibcはその番地を取得してcallしている。



## x86_64
* ユーザプログラム → glibc(直接SYSCALL命令) → **カーネル**
* ユーザプログラム → glibc → **VDSO**(gettimeofday、time、getcpu、clock_gettime)


vdso(ELF)のリンカスクリプト。やはり**gettimeofday、time、getcpu、clock_gettime**がvdso内に配置しようとすることが確認できる。

```arch/x86/vdso/vdso.lds.S
/*
 * Linker script for 64-bit vDSO.
 * We #include the file to define the layout details.
 * Here we only choose the prelinked virtual address.
 *
 * This file defines the version script giving the user-exported symbols in
 * the DSO.  We can define local symbols here called VDSO* to make their
 * values visible using the asm-x86/vdso.h macros from the kernel proper.
 */

#define VDSO_PRELINK 0xffffffffff700000
#include "vdso-layout.lds.S"

/*
 * This controls what userland symbols we export from the vDSO.
 */
VERSION {
        LINUX_2.6 {
        global:
                clock_gettime;
                __vdso_clock_gettime;
                gettimeofday;
                __vdso_gettimeofday;
                getcpu;
                __vdso_getcpu;
                time;
                __vdso_time;
        local: *;
        };
}

VDSO64_PRELINK = VDSO_PRELINK;
```

カーネルがvdsoの配置を決めていて、アプリケーション側はその上記システムコールのシンボルの番地を知る必要がある。カーネルがプログラムを実行する際に、そのプロセスのユーザースタック上のインタープリタテーブルの**AT_SYSINFO_EHDR** に**current->mm->context.vdso**の値を代入するので、glibc側でこれを調べるようになっている。

AT_SYSINFO_EHDRの確認

```bash

$ gdb ./hello -q
Reading symbols from /root/hello...done.
(gdb) b main
Breakpoint 1 at 0x4004d3: file hello.c, line 5.
(gdb) run
Starting program: /root/hello 

Breakpoint 1, main (argc=1, args=0x7fffffffe658) at hello.c:5
5           printf("Hello, world!\n");
(gdb) info auxv
33   AT_SYSINFO_EHDR      System-supplied DSO's ELF header 0x7ffff7ffa000
16   AT_HWCAP             Machine-dependent CPU capability hints 0xbfebfbff
6    AT_PAGESZ            System page size               4096
17   AT_CLKTCK            Frequency of times()           100
3    AT_PHDR              Program headers for program    0x400040
4    AT_PHENT             Size of program header entry   56
5    AT_PHNUM             Number of program headers      8
7    AT_BASE              Base address of interpreter    0x7ffff7ddc000
8    AT_FLAGS             Flags                          0x0
9    AT_ENTRY             Entry point of program         0x4003e0
11   AT_UID               Real user ID                   0
12   AT_EUID              Effective user ID              0
13   AT_GID               Real group ID                  0
14   AT_EGID              Effective group ID             0
23   AT_SECURE            Boolean, was exec setuid-like? 0
25   AT_RANDOM            Address of 16 random bytes     0x7fffffffe879
31   AT_EXECFN            File name of executable        0x7fffffffefec "/root/hello"
15   AT_PLATFORM          String identifying platform    0x7fffffffe889 "x86_64"
0    AT_NULL              End of vector                  0x0
```

\_dl_vdso_vsym で調べている。この条件演算子は[GNU拡張のようです](http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Conditionals.html)。

```c:sysdeps/unix/sysv/linux/x86_64/gettimeofday.cの抜粋
void *gettimeofday_ifunc (void) __asm__ ("__gettimeofday");
 
void *
gettimeofday_ifunc (void)
{
  PREPARE_VERSION (linux26, "LINUX_2.6", 61765110);
 
  /* If the vDSO is not available we fall back on the old vsyscall.  */
  return (_dl_vdso_vsym ("gettimeofday", &linux26)
          ?: (void *) VSYSCALL_ADDR_vgettimeofday);
}
__asm (".type __gettimeofday, %gnu_indirect_function");
```


# Virtual Dynamic Shared Object(VDSO)とは
* **ユーザープロセスのメモリ空間の一部**にカーネルのメモリを読み取り専用でマップしている
* ここにgettimeofday、time、getcpu、clock_gettimeを実現するコードが読み込み専用でマップされている、ここを利用することでシステムコールが**ユーザーモード内だけで完結**して実行速度が向上。
* カーネルモードに切り替えることなくアクセスできるようにするしくみ。
* 通常の**共有ライブラリと同じELF形式**。よって、呼び方は共有ライブラリと同じ。関数を普通に呼び出し、動的リンカがアドレスを見つけ出す。
* **VDSOを初期化する中のsysenter_setup()でvsyscallの設定もしている**
* vsyscallもvdsoの枠組の一つの仕組みで、固定の番地に配置される

## VDSO(i386の場合)
全てのシステムコールがVDSO or vsyscallを利用する

## VDSO(x86_64の場合)
* gettimeofday、time、getcpu、clock_gettimeだけが利用する。
* それ以外のシステムコールはglibcからsyscall命令が実行される

#  VirtualSystemCall(vsyscall) 
## vsyscall(i386の場合)
[Linuxカーネル2.6解読室](https://www.amazon.co.jp/Linux%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB2-6%E8%A7%A3%E8%AA%AD%E5%AE%A4-%E9%AB%98%E6%A9%8B%E6%B5%A9%E5%92%8C/dp/4797338261/ref=sr_1_10?ie=UTF8&qid=1493093409&sr=8-10&keywords=%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB+linux)
>カーネルが定義した実行コードをユーザー空間から参照できるようにして、ライブラリから実行させるものです。システムコールを発行するために、ライブラリはカーネルから指定されたアドレスを呼び出し、カーネルが定義したコードを実行します。

* ユーザー空間にあるCPU種別によって適切なシステムコールが配置された番地のシンボルみたいなもののはず
* そのシンボル名は32ビットLinuxでは`__kernel_vsyscall`で、64ビットLinuxでは`vsyscall`があるようだ
* `int \$0x80`、`sysenter/syscall`はVDSO(共有ライブラリ)の枠組みの中にあり、(VDSOを初期化する中のsysenter_setup()でvsyscallの設定もしている)__kernel_vsyscallというシンボルの番地に配置されている。
* glibcからは`__kernelvsyscall`を呼ぶだけでその環境にあった`int $0x80`、`sysenter/syscall`が呼ばれると思われる。透過的に扱えるので`VirtualSystemCall`と呼ばれている。
 
## vsyscall(x86_64の場合)
環境によるシステムコールの差異を考慮しなくてよいのでglibcから直接システムコール命令を使う。vsyscall領域は使用されなくなったが、32bitアプリケーションなどのためにまだ残っている様子。


# glibcからの呼び出し

動的にリンクする場合は**__vdso_gettimeofday**。静的にリンクする場合は**VSYSCALL_ADDR_vgettimeofday**。64bitの場合でも静的な場合はvsyscallの領域を使用するようでした。


```asm:glibc-2.12-2-gc4ccff1/sysdeps/unix/sysv/linux/x86_64/gettimeofday.S
/* For the calculation see asm/vsyscall.h.  */
#define VSYSCALL_ADDR_vgettimeofday     0xffffffffff600000


ENTRY (__gettimeofday)
        /* Align stack.  */
        sub     $0x8, %rsp
        cfi_adjust_cfa_offset(8)
#ifdef SHARED
        movq    __vdso_gettimeofday(%rip), %rax
        PTR_DEMANGLE (%rax)
#else
        movq    $VSYSCALL_ADDR_vgettimeofday, %rax
#endif
        callq   *%rax
        /* Check error return.  */
        cmpl    $-4095, %eax
        jae     SYSCALL_ERROR_LABEL
```

# その他メモ
## GNU C Library(glibc)
* GNUプロジェクトによる標準Cライブラリ実装。ベル研が作ったlibcと互換がある。
* カーネルのシステムコールを呼び出す処理が実際に書かれている。
* ユーザープログラムではここで定義されている関数を呼ぶだけ。write()、read()などなど。

## Application Binary Interface (ABI)
* システムコールの呼び出しかた(カーネルとCPUからみた視点)
* OSとCPUの種類分ABIはある
* Linux/x86のABI
  - 引数にレジスタ、int $0x80命令を使うなど。

## Application Programming Interface(API)
* システムコールを呼び出しかた(ユーザからみた視点)
* 例）ssize_t write(int fd , const void * buf , size_t count );
* POSIX準拠だとAPIが同じ。OSが異なっていてもPOSIX準拠であればABIが異なった場合でもそのユーザープログラムはコンパイルし直せば実行できる。

## 具体的なシステムコールの呼び出しかた
* INT 0x80命令の場合
  - CPUに対して例外(ソフトウェア割り込み)を発生させてCPUがIDTRレジスタからカーネルのIDTをみにいってそこに登録されているカーネル処理(ハンドラ)に飛びその処理を実行すること。
  - 処理の最初に現在のレジスタをスタックに入れる。最後にスタックからその値をレジスタに戻す。
  - [スタックの使い方](http://qiita.com/saikoro-steak/items/78d5abe7bc3ea6556eda)
* [sysenterの場合](http://blog.yuryu.jp/2014/06/x86-linux-sysenter.html)


## sysenter_setup()
カーネル起動時に、CPUを判別してVDSO内にCPUに適したシステムコールを最初から埋め込んでいる。
埋め込んでいる箇所
↓
http://lxr.free-electrons.com/source/arch/x86/vdso/vdso32-setup.c?v=3.13#L277


## システムコール x86_64
### 通常のシステムコール
* glibc
    - レジスタにシステムコール番号
    - syscall命令

↓

* system_call (入り口) (arch/x86/kernel/entry_64.S)

↓

* システムコールテーブル (/arch/x86/syscalls/syscall_64.tbl)
    * /arch/x86/kernel/syscall_64.cで配列に各システムコールの関数ポインタを設定。


↓

* システムコールテーブルの各関数(sys_システムコール名)に飛ぶ。

### カーネルでのシステムコール定義
* SYSCALL_DEFINE0～6マクロで定義されている
* fork()はなかった

http://kernhack.hatenablog.com/entry/20100314/1268573016↑
>システムコールを実装している関数だからと言って、これを必ず使ってるわけでも無いみたいです。sys_fork()とか・・

* 例えば、3.3.4にはなかった。4.3にはSYSCALL_DEFINEでforkが定義されていた。なんでだろ。。


### カーネル内でシステムコールの定義箇所を探すには
* SYSCALLとシステムコール名でgrep すると良い。
* だいたいSYSCALL_DEFINE0～6マクロで検索ヒットするっぽい。

# 参考
http://softwaretechnique.jp/Linux/SystemCall/sc_01.html
Software Design 2014年8月号


システムコールめもめも

# 概要
[カーネル探検(rest_init()からプロセス番号1生成まで)](http://qiita.com/saikoro-steak/items/e8121afdd5f294e14c43)
の続きのメモ。詳細はリンク元を見たほうがよい。

# カーネルスレッド生成
## kernel_thread()
カーネルスレッドを生成する入口。引数にスレッドの用の値を渡している？なのでプロセスというよりスレッドを生成する。

### kernel_thread()で何している
* do_fork()
  - task_strcutのコピーを作り実行可能プロセスのリストに登録する。**プロセスディスクリプタからポインタしている各資源は親と共有している。**
  - **EAX、SP、IPは子プロセス独自のもの。**
  - IPはkernel_thread_helperを設定
     * カーネルスレッド関数をcallするやつ。カーネルスレッドの処理が終わったらここに戻りdo_exitする。
  
カーネルスレッド生成する際は**execはしていないので**、ユーザーモードにならずカーネルスレッドとして生成される。親と各資源を共有してスタックやIPなどは別の箇所を指しているスレッド。

# kernel_init()について
  - kernel_thread()で生成されたカーネルスレッド。
  - initramfsを使っている場合はramfsの/initを起動させる。

## /init
* kernel_init()の中でinitramfsの/initを実行する。
* 親がカーネルスレッドだが特別でユーザプロセスに変身する

# /initがユーザプロセスとして生成されるまでの流れ
* run_init_process()
  - kernel_init()が呼び出す。このとき大概はinitramfs使用しているので引数には/init
* kernel_execve()
  - sys_execve()を呼び出す。
* sys_execve()
  - exec系システムコールの入り口にもなっている。
  - 実行ファイルをメモリにマッピング
  - **カーネルスレッド(kernel_init)から/initプロセスを生成するとき**にはカーネルスタックのカーネルモードの値をユーザーモードの値に上書きしてユーザープロセスに変身させるみたい
         + ユーザーモードを表す__USER_CS, __USER_DSの値が使用されている。
         + なのでこのsys_execveを使うとユーザーモードのプロセスが生成される。
         + /initプロセス生成はこれを利用して親がカーネルモードプロセスだがユーザーモードプロセスになる

#### スタックの上書き
* EIP 動的リンカの開始ポイント(共有ライブラリをリンクしているので)
* ESP ユーザーモードのスタックポインタ
* DS  \_\_USER_DS
* ES  \_\_USER_DS
* SS  \_\_USER_DS
* CS  \_\_USER_CS

システムコールの割り込み処理から戻るときにCPUがカーネルモードからユーザモードに移行したことを感知する。(CSが変化したのを感知する)なので、最初にシステムコールした時にはEFLAGS、CS、EIPしか積まないが、システムコールから復帰するときに特権の移行が発生するのでユザーモードに上書きされたSS,ESPもpopされる。よってユーザーモードになる。カーネルモードからユーザーモードのプロセスを生成するのはこれだけ？？？

* CPUがシステムコールの時に自動でスタックにpush/pop
  - 特権移行なし
     + EFLAGS、CS、EIP
  - 特権移行あり
     + SS、ESP、EFLAGS、CS、EIP

# メモメモ
## ユーザープロセス生成
- fork()してexec()する。
  + do_fork()
    - ユーザーモードのプロセスコピーはipはret_from_fork()に設定?
    - **ここではプロセスディスクリプタからポインタしている各資源は親と共有している。**
- exec系システムコール
  + 親と共有している資源を自分独自のものにする、mmの切り替え。

## カーネルスタックの場所
- 親プロセスのtask_structをコピーするときに作成されるthread_info構造体のとこにある

## ユーザーモードスタックの場所
- リンカスクリプトに書かれている\_stack(メモリ番地を表す)みたいなのがユーザーモードスタックの開始場所。execしてメモリディスクリプタを新規で作成するときにその情報が書かれるはず(start\_stackとか)。

## 特権レベル移行のスタック動作
### カーネルモード →　カーネルモード
特権の移行なし。割り込み後はそのまま今使用しているカーネルスタックを使用する。

### ユーザーモード　→　カーネルモード
例：ユーザプログラムでシステムコール

* TSSからそのプロセスのカーネルモードのSP、SSが保存されているよう(プロセス生成時、スケジュールされた時にいれてる？)。
* なのでここから各種カーネルモードの値を取り出して設定。そしてそこでカーネルスタックにユーザーモードのレジスタをいれてカーネルモードの動作をする。終わったら、ユーザーモードのレジスタを取り出してユーザーモードに戻る。



<h1>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h1>

<p><a href="http://qiita.com/saikoro-steak/items/e8121afdd5f294e14c43" id="reference-6fafa50c1c844933d274">カーネル探検(rest_init()からプロセス番号1生成まで)</a><br>
の続きのメモ。詳細はリンク元を見たほうがよい。</p>

<h1>
<span id="カーネルスレッド生成" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89%E7%94%9F%E6%88%90"><i class="fa fa-link"></i></a>カーネルスレッド生成</h1>

<h2>
<span id="kernel_thread" class="fragment"></span><a href="#kernel_thread"><i class="fa fa-link"></i></a>kernel_thread()</h2>

<p>カーネルスレッドを生成する入口。引数にスレッドの用の値を渡している？なのでプロセスというよりスレッドを生成する。</p>

<h3>
<span id="kernel_threadで何している" class="fragment"></span><a href="#kernel_thread%E3%81%A7%E4%BD%95%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B"><i class="fa fa-link"></i></a>kernel_thread()で何している</h3>

<ul>
<li>do_fork()

<ul>
<li>task_strcutのコピーを作り実行可能プロセスのリストに登録する。<strong>プロセスディスクリプタからポインタしている各資源は親と共有している。</strong>
</li>
<li><strong>EAX、SP、IPは子プロセス独自のもの。</strong></li>
<li>IPはkernel_thread_helperを設定

<ul>
<li>カーネルスレッド関数をcallするやつ。カーネルスレッドの処理が終わったらここに戻りdo_exitする。</li>
</ul>
</li>
</ul>
</li>
</ul>

<p>カーネルスレッド生成する際は<strong>execはしていないので</strong>、ユーザーモードにならずカーネルスレッドとして生成される。親と各資源を共有してスタックやIPなどは別の箇所を指しているスレッド。</p>

<h1>
<span id="kernel_initについて" class="fragment"></span><a href="#kernel_init%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><i class="fa fa-link"></i></a>kernel_init()について</h1>

<ul>
<li>kernel_thread()で生成されたカーネルスレッド。</li>
<li>initramfsを使っている場合はramfsの/initを起動させる。</li>
</ul>

<h2>
<span id="init" class="fragment"></span><a href="#init"><i class="fa fa-link"></i></a>/init</h2>

<ul>
<li>kernel_init()の中でinitramfsの/initを実行する。</li>
<li>親がカーネルスレッドだが特別でユーザプロセスに変身する</li>
</ul>

<h1>
<span id="initがユーザプロセスとして生成されるまでの流れ" class="fragment"></span><a href="#init%E3%81%8C%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%A8%E3%81%97%E3%81%A6%E7%94%9F%E6%88%90%E3%81%95%E3%82%8C%E3%82%8B%E3%81%BE%E3%81%A7%E3%81%AE%E6%B5%81%E3%82%8C"><i class="fa fa-link"></i></a>/initがユーザプロセスとして生成されるまでの流れ</h1>

<ul>
<li>run_init_process()

<ul>
<li>kernel_init()が呼び出す。このとき大概はinitramfs使用しているので引数には/init</li>
</ul>
</li>
<li>kernel_execve()

<ul>
<li>sys_execve()を呼び出す。</li>
</ul>
</li>
<li>sys_execve()

<ul>
<li>exec系システムコールの入り口にもなっている。</li>
<li>実行ファイルをメモリにマッピング</li>
<li>
<strong>カーネルスレッド(kernel_init)から/initプロセスを生成するとき</strong>にはカーネルスタックのカーネルモードの値をユーザーモードの値に上書きしてユーザープロセスに変身させるみたい

<ul>
<li>ユーザーモードを表す__USER_CS, __USER_DSの値が使用されている。</li>
<li>なのでこのsys_execveを使うとユーザーモードのプロセスが生成される。</li>
<li>/initプロセス生成はこれを利用して親がカーネルモードプロセスだがユーザーモードプロセスになる</li>
</ul>
</li>
</ul>
</li>
</ul>

<h4>
<span id="スタックの上書き" class="fragment"></span><a href="#%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E3%81%AE%E4%B8%8A%E6%9B%B8%E3%81%8D"><i class="fa fa-link"></i></a>スタックの上書き</h4>

<ul>
<li>EIP 動的リンカの開始ポイント(共有ライブラリをリンクしているので)</li>
<li>ESP ユーザーモードのスタックポインタ</li>
<li>DS  __USER_DS</li>
<li>ES  __USER_DS</li>
<li>SS  __USER_DS</li>
<li>CS  __USER_CS</li>
</ul>

<p>システムコールの割り込み処理から戻るときにCPUがカーネルモードからユーザモードに移行したことを感知する。(CSが変化したのを感知する)なので、最初にシステムコールした時にはEFLAGS、CS、EIPしか積まないが、システムコールから復帰するときに特権の移行が発生するのでユザーモードに上書きされたSS,ESPもpopされる。よってユーザーモードになる。カーネルモードからユーザーモードのプロセスを生成するのはこれだけ？？？</p>

<ul>
<li>CPUがシステムコールの時に自動でスタックにpush/pop

<ul>
<li>特権移行なし

<ul>
<li>EFLAGS、CS、EIP</li>
</ul>
</li>
<li>特権移行あり

<ul>
<li>SS、ESP、EFLAGS、CS、EIP</li>
</ul>
</li>
</ul>
</li>
</ul>

<h1>
<span id="メモメモ" class="fragment"></span><a href="#%E3%83%A1%E3%83%A2%E3%83%A1%E3%83%A2"><i class="fa fa-link"></i></a>メモメモ</h1>

<h2>
<span id="ユーザープロセス生成" class="fragment"></span><a href="#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E7%94%9F%E6%88%90"><i class="fa fa-link"></i></a>ユーザープロセス生成</h2>

<ul>
<li>fork()してexec()する。

<ul>
<li>do_fork()</li>
<li>ユーザーモードのプロセスコピーはipはret_from_fork()に設定?</li>
<li><strong>ここではプロセスディスクリプタからポインタしている各資源は親と共有している。</strong></li>
</ul>
</li>
<li>exec系システムコール

<ul>
<li>親と共有している資源を自分独自のものにする、mmの切り替え。</li>
</ul>
</li>
</ul>

<h2>
<span id="カーネルスタックの場所" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E3%81%AE%E5%A0%B4%E6%89%80"><i class="fa fa-link"></i></a>カーネルスタックの場所</h2>

<ul>
<li>親プロセスのtask_structをコピーするときに作成されるthread_info構造体のとこにある</li>
</ul>

<h2>
<span id="ユーザーモードスタックの場所" class="fragment"></span><a href="#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%83%A2%E3%83%BC%E3%83%89%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E3%81%AE%E5%A0%B4%E6%89%80"><i class="fa fa-link"></i></a>ユーザーモードスタックの場所</h2>

<ul>
<li>リンカスクリプトに書かれている_stack(メモリ番地を表す)みたいなのがユーザーモードスタックの開始場所。execしてメモリディスクリプタを新規で作成するときにその情報が書かれるはず(start_stackとか)。</li>
</ul>

<h2>
<span id="特権レベル移行のスタック動作" class="fragment"></span><a href="#%E7%89%B9%E6%A8%A9%E3%83%AC%E3%83%99%E3%83%AB%E7%A7%BB%E8%A1%8C%E3%81%AE%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E5%8B%95%E4%BD%9C"><i class="fa fa-link"></i></a>特権レベル移行のスタック動作</h2>

<h3>
<span id="カーネルモード-カーネルモード" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%83%A2%E3%83%BC%E3%83%89-%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%83%A2%E3%83%BC%E3%83%89"><i class="fa fa-link"></i></a>カーネルモード →　カーネルモード</h3>

<p>特権の移行なし。割り込み後はそのまま今使用しているカーネルスタックを使用する。</p>

<h3>
<span id="ユーザーモードカーネルモード" class="fragment"></span><a href="#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%83%A2%E3%83%BC%E3%83%89%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%83%A2%E3%83%BC%E3%83%89"><i class="fa fa-link"></i></a>ユーザーモード　→　カーネルモード</h3>

<p>例：ユーザプログラムでシステムコール</p>

<ul>
<li>TSSからそのプロセスのカーネルモードのSP、SSが保存されているよう(プロセス生成時、スケジュールされた時にいれてる？)。</li>
<li>なのでここから各種カーネルモードの値を取り出して設定。そしてそこでカーネルスタックにユーザーモードのレジスタをいれてカーネルモードの動作をする。終わったら、ユーザーモードのレジスタを取り出してユーザーモードに戻る。</li>
</ul>


カーネルスレッド生成&ユーザーモードプロセス生成

### 概要
コンテナ(LXC)について調べようと思っていろいろ見ていたら、いろいろ脱線してカーネルのことについて復習したのでその時の自分めもめも。

### 用語メモメモ
#### マウント

##### マウントコマンド

~~~zsh
mount -t <タイプ> -o <オプション> <デバイスファイル> <マウントポイント>
~~~

##### マウントとは
* ファイル・システム(super_block)をシステムのディレクトリツリー(マウントポイント)に関連づけること。関連づけるとはvfsmount構造体、mount構造体に対してマウントポイント、スーパーブロックなどを設定すること。
* ファイルシステム≒デバイス
* ファイルシステムとファイルシステムを結びつける

##### ファイルシステムの実体
  
  * [super_block構造体](http://lxr.free-electrons.com/source/include/linux/fs.h#L1289)
    - s_inodesかコメントに書かれているようにすべてのinodeリストに繋がっている。

OSをインストールするときに各パーティションに対してファイル・システムを決定してシステムのディレクトリツリーを割り当てる。OS起動するとメモリ上ではそのファイル・システム(システムの各部分)をシステムの対応するディレクトリツリーにマウントする。

#### マウントの関連性を表している構造体
  * [vfs_mount構造体](http://lxr.free-electrons.com/source/include/linux/mount.h#L66)

  * [mount構造体](http://lxr.free-electrons.com/source/fs/mount.h#L30)
    - struct vfsmount mntでvfsmountと関連している。
    - マウントポイントなどなど

これがメモリ上で構築されているのでマウント状態がわかる。

#### 名前空間(namespace)
* カーネル2.6から導入された
* task_struct構造体(プロセスの実体)から->namespaceで辿れる。(2.6系ではあるみたいだけど、それ以降はどうもnsporxyからたどるみたい？)
* vfsmount構造体はnamespace構造体から知ることができる。

##### 名前空間の使用
各プロセス(task_struct)はnamespace構造体を保持している。そのプロセスからforkする場合、forkされたプロセス(task_strcut)はnamespace構造体を共有する。共有せずに新たな名前空間を使用したい場合clone(CLONE_NEWSNSフラグ指定)を使用する。するとnamespase構造体は共有せずに別に独立して獲得されるみたい。
なのでunshareコマンドなんかは内部でcloneしてCLONE_NEWSNSフラグが指定されているのではないのかなぁ。

##### 名前空間まとめ
マウントはvfsmount構造体、mount構造体に対してマウントポイントなどを設定することなので、cloneを使用して名前空間が異なるプロセスがあった場合、一つの名前空間でマウントなどを実行した場合は、もう一つの名前空間のプロセスのマウントには影響を与えない(vfsmount構造体などは独立しているので)。
なるほどー、コンテナで名前空間を使ってる意味が見えたきがします。



<h3>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h3>

<p>コンテナ(LXC)について調べようと思っていろいろ見ていたら、いろいろ脱線してカーネルのことについて復習したのでその時の自分めもめも。</p>

<h3>
<span id="用語メモメモ" class="fragment"></span><a href="#%E7%94%A8%E8%AA%9E%E3%83%A1%E3%83%A2%E3%83%A1%E3%83%A2"><i class="fa fa-link"></i></a>用語メモメモ</h3>

<h4>
<span id="マウント" class="fragment"></span><a href="#%E3%83%9E%E3%82%A6%E3%83%B3%E3%83%88"><i class="fa fa-link"></i></a>マウント</h4>

<h5>
<span id="マウントコマンド" class="fragment"></span><a href="#%E3%83%9E%E3%82%A6%E3%83%B3%E3%83%88%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89"><i class="fa fa-link"></i></a>マウントコマンド</h5>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>mount <span class="nt">-t</span> &lt;タイプ&gt; <span class="nt">-o</span> &lt;オプション&gt; &lt;デバイスファイル&gt; &lt;マウントポイント&gt;
</code></pre></div></div>

<h5>
<span id="マウントとは" class="fragment"></span><a href="#%E3%83%9E%E3%82%A6%E3%83%B3%E3%83%88%E3%81%A8%E3%81%AF"><i class="fa fa-link"></i></a>マウントとは</h5>

<ul>
<li>ファイル・システム(super_block)をシステムのディレクトリツリー(マウントポイント)に関連づけること。関連づけるとはvfsmount構造体、mount構造体に対してマウントポイント、スーパーブロックなどを設定すること。</li>
<li>ファイルシステム≒デバイス</li>
<li>ファイルシステムとファイルシステムを結びつける</li>
</ul>

<h5>
<span id="ファイルシステムの実体" class="fragment"></span><a href="#%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E5%AE%9F%E4%BD%93"><i class="fa fa-link"></i></a>ファイルシステムの実体</h5>

<ul>
<li>
<a href="http://lxr.free-electrons.com/source/include/linux/fs.h#L1289" rel="nofollow noopener" target="_blank">super_block構造体</a>

<ul>
<li>s_inodesかコメントに書かれているようにすべてのinodeリストに繋がっている。</li>
</ul>
</li>
</ul>

<p>OSをインストールするときに各パーティションに対してファイル・システムを決定してシステムのディレクトリツリーを割り当てる。OS起動するとメモリ上ではそのファイル・システム(システムの各部分)をシステムの対応するディレクトリツリーにマウントする。</p>

<h4>
<span id="マウントの関連性を表している構造体" class="fragment"></span><a href="#%E3%83%9E%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AE%E9%96%A2%E9%80%A3%E6%80%A7%E3%82%92%E8%A1%A8%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E6%A7%8B%E9%80%A0%E4%BD%93"><i class="fa fa-link"></i></a>マウントの関連性を表している構造体</h4>

<ul>
<li><p><a href="http://lxr.free-electrons.com/source/include/linux/mount.h#L66" rel="nofollow noopener" target="_blank">vfs_mount構造体</a></p></li>
<li>
<p><a href="http://lxr.free-electrons.com/source/fs/mount.h#L30" rel="nofollow noopener" target="_blank">mount構造体</a></p>

<ul>
<li>struct vfsmount mntでvfsmountと関連している。</li>
<li>マウントポイントなどなど</li>
</ul>
</li>
</ul>

<p>これがメモリ上で構築されているのでマウント状態がわかる。</p>

<h4>
<span id="名前空間namespace" class="fragment"></span><a href="#%E5%90%8D%E5%89%8D%E7%A9%BA%E9%96%93namespace"><i class="fa fa-link"></i></a>名前空間(namespace)</h4>

<ul>
<li>カーネル2.6から導入された</li>
<li>task_struct構造体(プロセスの実体)から-&gt;namespaceで辿れる。(2.6系ではあるみたいだけど、それ以降はどうもnsporxyからたどるみたい？)</li>
<li>vfsmount構造体はnamespace構造体から知ることができる。</li>
</ul>

<h5>
<span id="名前空間の使用" class="fragment"></span><a href="#%E5%90%8D%E5%89%8D%E7%A9%BA%E9%96%93%E3%81%AE%E4%BD%BF%E7%94%A8"><i class="fa fa-link"></i></a>名前空間の使用</h5>

<p>各プロセス(task_struct)はnamespace構造体を保持している。そのプロセスからforkする場合、forkされたプロセス(task_strcut)はnamespace構造体を共有する。共有せずに新たな名前空間を使用したい場合clone(CLONE_NEWSNSフラグ指定)を使用する。するとnamespase構造体は共有せずに別に独立して獲得されるみたい。<br>
なのでunshareコマンドなんかは内部でcloneしてCLONE_NEWSNSフラグが指定されているのではないのかなぁ。</p>

<h5>
<span id="名前空間まとめ" class="fragment"></span><a href="#%E5%90%8D%E5%89%8D%E7%A9%BA%E9%96%93%E3%81%BE%E3%81%A8%E3%82%81"><i class="fa fa-link"></i></a>名前空間まとめ</h5>

<p>マウントはvfsmount構造体、mount構造体に対してマウントポイントなどを設定することなので、cloneを使用して名前空間が異なるプロセスがあった場合、一つの名前空間でマウントなどを実行した場合は、もう一つの名前空間のプロセスのマウントには影響を与えない(vfsmount構造体などは独立しているので)。<br>
なるほどー、コンテナで名前空間を使ってる意味が見えたきがします。</p>


マウントと名前空間めもめも

# 参考
https://www.amazon.co.jp/%E3%83%AA%E3%83%B3%E3%82%AB%E3%83%BB%E3%83%AD%E3%83%BC%E3%83%80%E5%AE%9F%E8%B7%B5%E9%96%8B%E7%99%BA%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E2%80%95%E5%AE%9F%E8%A1%8C%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB%E5%BF%85%E9%A0%88%E3%81%AE%E6%8A%80%E8%A1%93-COMPUTER-TECHNOLOGY-%E5%9D%82%E4%BA%95-%E5%BC%98%E4%BA%AE/dp/4789838072/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=%E3%83%AA%E3%83%B3%E3%82%AB%E3%83%AD%E3%83%BC%E3%83%80&qid=1620031612&sr=8-1

# 概要
リンカ＆ローダーの仕組みについて上記本を見ながら学習した備忘録です

# 用語など
## リンクとは
* アセンブラされた複数のオブジェクトファイル(.o)を結合する作業のこと。**結合時にオブジェクトファイルの関数呼び出し箇所を実際の関数呼び出しのメモリ番地に置換する(結合するまでは関数呼び出しなどは関数呼び出ししますよのマークがされた状態になっている)**。リンクすることで実行形式ファイルが作成される。
* リンクを行うアプリケーションのことをリンカと呼ぶ

## ロードとは
* 実行形式を読み込み、プログラムヘッダをに従ってメモリ上に配置(仮想メモリにマッピング)
* BSS領域のゼロクリア
* レジスタやスタック、引数の設定
* エントリポイントにジャンプ(プログラムカウントをエントリポイントに設定)
* ロードを行うアプリケーションのことをローダと呼ぶ

リンカもローダもOSの機能

## オブジェクトファイル(.o)
* アセンブルされたバイナリでELF形式
* .text、.rodata、.data、.bssセクションなどなどのセクションをもつ。アセンブラでは各セクションを作成する役割がある。自分でアセンブラプログラミングする時は明示的に指定するセクションは.text、.rodata、.data、.bssセクションくらいだと思っている。他セクションはアセンブラが作成してくれる。各セクションの情報を持つセクションヘッダをもつ。
* 各オブジェクトファイルをリンクすることで実行形式が作成される

## リンカスクリプト
* .text .dataなど各領域のメモリ配置の情報が書かれている
* リンカが実行形式を作成する際に参照して、実行形式のプログラムヘッダなどを作成する
* GNUldでは実行時にリンカスクリプトを指定しないとldをビルドする時に組み込まれたデフォルトのリンカスクリプトが利用される。ld --verboseで確認できる。通常何も指定しないので下のデフォルトのリンカスクリプトを利用している。

~~~sh
# ld --verbose
GNU ld version 2.23.52.0.1-30.el7_1.2 20130226
  サポートされているエミュレーション:
   elf_x86_64
   elf32_x86_64
   elf_i386
   i386linux
   elf_l1om
   elf_k1om
内部リンカスクリプトを使用しています:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",
              "elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)
ENTRY(_start)
SEARCH_DIR("/usr/x86_64-redhat-linux/lib64"); SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/x86_64-redhat-linux/lib"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000)); . = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;
  .interp         : { *(.interp) }
  .note.gnu.build-id : { *(.note.gnu.build-id) }
  .hash           : { *(.hash) }
  .gnu.hash       : { *(.gnu.hash) }
・
・
・
~~~


## 実行形式(.out)
* ELF形式
* 各オブジェクトファイルのセクションがセグメントにマージされる
* プログラムヘッダに記載される情報(一部)
  - ロード対象フラグ
  - ロード先の仮想アドレス
  - セグメントのサイズ など
* ローダはプログラムヘッダを見て、各セグメントを仮想メモリにマッピングしていく

# リンカについて
## リンク動作順番
1. 各オブジェクトファイルのセクションをマージしてまとめる。そしてマージしたセクション同士を意味のある単位でセグメント(ローダーがメモリにロードする単位)にまとめる。
2. 関数、変数の実体が存在する各セクションをメモリのどの番地に配置されるかリンカスクリプトを参照してプログラムヘッダを作成する。結果、変数、関数の番地が決定する(再配置)
3. 変数、関数のアドレスが決まったのでシンボルテーブル(.symtabセクション)の各変数、関数のアドレス欄を埋める。
4. シンボルテーブルを元に各セクションで`空欄`(再配置情報)になっていた箇所に`アドレスを補充`。 (名前解決=シンボル解決)
5. 実行形式として出力する。

# ローダー
リンカが作成した実行形式をメモリ上に展開する(仮想メモリにマッピング)

# 補足
## シンボルテーブル(.symtabセクション)
関数・変数が配置されるメモリ上のアドレスとシンボル名の表。オブジェクトファイルはシンボルを管理するシンボルテーブルを持っている。.symtabセクションに入っている。

実行形式のシンボルテーブル

~~~sh
# nm a.out 
・
・
0000000000400440 T _start
0000000000601034 b completed.6337
0000000000601030 W data_start
0000000000400470 t deregister_tm_clones
0000000000400500 t frame_dummy
0000000000400530 T main
                 U printf@@GLIBC_2.2.5
00000000004004a0 t register_tm_clones
~~~
リンク後はmainにアドレスが割り当てられていて、printは共有ライブラリで実行時にアドレスが決定するので空欄。
 
#### 再配置情報
オブジェクトファイルはリンク前の段階なので変数、関数を参照する箇所は空欄になっている(リンク前でアドレスを決められないので)。この空欄のことを`再配置情報`と呼ぶ。.relxxx＆.relaxxxに入ってる。xxxは各セクション名。この二つは再配置情報の格納方法が異るみたい。

* 再配置情報は空欄ごとにあるので、関数や変数を参照する数だけある。
* `シンボルテーブル`は関数、変数の定義の数だけ。

再配置情報を見てみる

~~~sh
# readelf -r hello.o

再配置セクション '.rela.text' (オフセット 0x600) は 10 個のエントリから構成されています:
  オフセット      情報           型             シンボル値    シンボル名 + 加数
000000000023  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
00000000002d  000a00000002 R_X86_64_PC32     0000000000000000 printf - 4
000000000037  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
000000000041  000a00000002 R_X86_64_PC32     0000000000000000 printf - 4
00000000004b  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
000000000055  000a00000002 R_X86_64_PC32     0000000000000000 printf - 4
00000000005f  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
000000000069  000a00000002 R_X86_64_PC32     0000000000000000 printf - 4
00000000006e  00050000000a R_X86_64_32       0000000000000000 .rodata + 3
000000000078  000a00000002 R_X86_64_PC32     0000000000000000 printf - 4
~~~

printfが複数ある。printfを参照している数だけある。

~~~sh
# nm hello.o
0000000000000000 T main
                 U printf
~~~
シンボルテーブルは定義の数のみ。

## リンカの実体
[ソースコードから実行形式を作成するまでの流れ](http://qiita.com/saikoro-steak/items/a9d1576d9c14706bdde6)で書いたように、CentOS7のGCCの場合だと`/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/collect2`ただcollcect2はGNUのldである`/usr/bin/ld`を使っている。LinuxではGNUのldが一般的みたい。ただし、リンカはOSに強く依存するものなのでOS毎にリンカが存在している。Microsoftではlink、solarisならsolarisのld。なのでGCCは環境に応じてリンカを使い分けるので、collect2はその共通のラッパーになっている。


## 実行形式のプログラムヘッダ
これもELF形式。各セクションを意味的にまとめたプログラムヘッダが作られる。プログラムヘッダをみてみた。

~~~sh
# readelf -l a.out 

Elf ファイルタイプは EXEC (実行可能ファイル) です
エントリポイント 0x400440
9 個のプログラムヘッダ、始点オフセット 64

プログラムヘッダ:
  タイプ        オフセット          仮想Addr           物理Addr
            ファイルサイズ        メモリサイズ         フラグ 整列
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [要求されるプログラムインタプリタ: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000077c 0x000000000000077c  R E    200000
  LOAD           0x0000000000000e10 0x0000000000600e10 0x0000000000600e10
                 0x0000000000000224 0x0000000000000228  RW     200000
  DYNAMIC        0x0000000000000e28 0x0000000000600e28 0x0000000000600e28
                 0x00000000000001d0 0x00000000000001d0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x0000000000000654 0x0000000000400654 0x0000000000400654
                 0x0000000000000034 0x0000000000000034  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x0000000000000e10 0x0000000000600e10 0x0000000000600e10
                 0x00000000000001f0 0x00000000000001f0  R      1

 セグメントマッピングへのセクション:
  セグメントセクション...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag .note.gnu.build-id 
   06     .eh_frame_hdr 
   07     
   08     .init_array .fini_array .jcr .dynamic .got
~~~

00~08が各セクションを意味的にまとめている番号。上と下は順番が対応している。LOADはローダーがメモリにロードする箇所。オフセットはELFの先頭からの位置。





<h1>
<span id="参考" class="fragment"></span><a href="#%E5%8F%82%E8%80%83"><i class="fa fa-link"></i></a>参考</h1>

<p><qiita-embed-ogp src="https://www.amazon.co.jp/%E3%83%AA%E3%83%B3%E3%82%AB%E3%83%BB%E3%83%AD%E3%83%BC%E3%83%80%E5%AE%9F%E8%B7%B5%E9%96%8B%E7%99%BA%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E2%80%95%E5%AE%9F%E8%A1%8C%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB%E5%BF%85%E9%A0%88%E3%81%AE%E6%8A%80%E8%A1%93-COMPUTER-TECHNOLOGY-%E5%9D%82%E4%BA%95-%E5%BC%98%E4%BA%AE/dp/4789838072/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&amp;dchild=1&amp;keywords=%E3%83%AA%E3%83%B3%E3%82%AB%E3%83%AD%E3%83%BC%E3%83%80&amp;qid=1620031612&amp;sr=8-1"></qiita-embed-ogp></p>

<h1>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h1>

<p>リンカ＆ローダーの仕組みについて上記本を見ながら学習した備忘録です</p>

<h1>
<span id="用語など" class="fragment"></span><a href="#%E7%94%A8%E8%AA%9E%E3%81%AA%E3%81%A9"><i class="fa fa-link"></i></a>用語など</h1>

<h2>
<span id="リンクとは" class="fragment"></span><a href="#%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%A8%E3%81%AF"><i class="fa fa-link"></i></a>リンクとは</h2>

<ul>
<li>アセンブラされた複数のオブジェクトファイル(.o)を結合する作業のこと。<strong>結合時にオブジェクトファイルの関数呼び出し箇所を実際の関数呼び出しのメモリ番地に置換する(結合するまでは関数呼び出しなどは関数呼び出ししますよのマークがされた状態になっている)</strong>。リンクすることで実行形式ファイルが作成される。</li>
<li>リンクを行うアプリケーションのことをリンカと呼ぶ</li>
</ul>

<h2>
<span id="ロードとは" class="fragment"></span><a href="#%E3%83%AD%E3%83%BC%E3%83%89%E3%81%A8%E3%81%AF"><i class="fa fa-link"></i></a>ロードとは</h2>

<ul>
<li>実行形式を読み込み、プログラムヘッダをに従ってメモリ上に配置(仮想メモリにマッピング)</li>
<li>BSS領域のゼロクリア</li>
<li>レジスタやスタック、引数の設定</li>
<li>エントリポイントにジャンプ(プログラムカウントをエントリポイントに設定)</li>
<li>ロードを行うアプリケーションのことをローダと呼ぶ</li>
</ul>

<p>リンカもローダもOSの機能</p>

<h2>
<span id="オブジェクトファイルo" class="fragment"></span><a href="#%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%ABo"><i class="fa fa-link"></i></a>オブジェクトファイル(.o)</h2>

<ul>
<li>アセンブルされたバイナリでELF形式</li>
<li>.text、.rodata、.data、.bssセクションなどなどのセクションをもつ。アセンブラでは各セクションを作成する役割がある。自分でアセンブラプログラミングする時は明示的に指定するセクションは.text、.rodata、.data、.bssセクションくらいだと思っている。他セクションはアセンブラが作成してくれる。各セクションの情報を持つセクションヘッダをもつ。</li>
<li>各オブジェクトファイルをリンクすることで実行形式が作成される</li>
</ul>

<h2>
<span id="リンカスクリプト" class="fragment"></span><a href="#%E3%83%AA%E3%83%B3%E3%82%AB%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88"><i class="fa fa-link"></i></a>リンカスクリプト</h2>

<ul>
<li>.text .dataなど各領域のメモリ配置の情報が書かれている</li>
<li>リンカが実行形式を作成する際に参照して、実行形式のプログラムヘッダなどを作成する</li>
<li>GNUldでは実行時にリンカスクリプトを指定しないとldをビルドする時に組み込まれたデフォルトのリンカスクリプトが利用される。ld --verboseで確認できる。通常何も指定しないので下のデフォルトのリンカスクリプトを利用している。</li>
</ul>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="c"># ld --verbose</span>
GNU ld version 2.23.52.0.1-30.el7_1.2 20130226
  サポートされているエミュレーション:
   elf_x86_64
   elf32_x86_64
   elf_i386
   i386linux
   elf_l1om
   elf_k1om
内部リンカスクリプトを使用しています:
<span class="o">==================================================</span>
/<span class="k">*</span> Script <span class="k">for</span> <span class="nt">-z</span> combreloc: combine and <span class="nb">sort </span>reloc sections <span class="k">*</span>/
OUTPUT_FORMAT<span class="o">(</span><span class="s2">"elf64-x86-64"</span>, <span class="s2">"elf64-x86-64"</span>,
              <span class="s2">"elf64-x86-64"</span><span class="o">)</span>
OUTPUT_ARCH<span class="o">(</span>i386:x86-64<span class="o">)</span>
ENTRY<span class="o">(</span>_start<span class="o">)</span>
SEARCH_DIR<span class="o">(</span><span class="s2">"/usr/x86_64-redhat-linux/lib64"</span><span class="o">)</span><span class="p">;</span> SEARCH_DIR<span class="o">(</span><span class="s2">"/usr/local/lib64"</span><span class="o">)</span><span class="p">;</span> SEARCH_DIR<span class="o">(</span><span class="s2">"/lib64"</span><span class="o">)</span><span class="p">;</span> SEARCH_DIR<span class="o">(</span><span class="s2">"/usr/lib64"</span><span class="o">)</span><span class="p">;</span> SEARCH_DIR<span class="o">(</span><span class="s2">"/usr/x86_64-redhat-linux/lib"</span><span class="o">)</span><span class="p">;</span> SEARCH_DIR<span class="o">(</span><span class="s2">"/usr/lib64"</span><span class="o">)</span><span class="p">;</span> SEARCH_DIR<span class="o">(</span><span class="s2">"/usr/local/lib"</span><span class="o">)</span><span class="p">;</span> SEARCH_DIR<span class="o">(</span><span class="s2">"/lib"</span><span class="o">)</span><span class="p">;</span> SEARCH_DIR<span class="o">(</span><span class="s2">"/usr/lib"</span><span class="o">)</span><span class="p">;</span>
SECTIONS
<span class="o">{</span>
  /<span class="k">*</span> Read-only sections, merged into text segment: <span class="k">*</span>/
  PROVIDE <span class="o">(</span>__executable_start <span class="o">=</span> SEGMENT_START<span class="o">(</span><span class="s2">"text-segment"</span>, 0x400000<span class="o">))</span><span class="p">;</span> <span class="nb">.</span> <span class="o">=</span> SEGMENT_START<span class="o">(</span><span class="s2">"text-segment"</span>, 0x400000<span class="o">)</span> + SIZEOF_HEADERS<span class="p">;</span>
  .interp         : <span class="o">{</span> <span class="k">*</span><span class="o">(</span>.interp<span class="o">)</span> <span class="o">}</span>
  .note.gnu.build-id : <span class="o">{</span> <span class="k">*</span><span class="o">(</span>.note.gnu.build-id<span class="o">)</span> <span class="o">}</span>
  .hash           : <span class="o">{</span> <span class="k">*</span><span class="o">(</span>.hash<span class="o">)</span> <span class="o">}</span>
  .gnu.hash       : <span class="o">{</span> <span class="k">*</span><span class="o">(</span>.gnu.hash<span class="o">)</span> <span class="o">}</span>
・
・
・
</code></pre></div></div>

<h2>
<span id="実行形式out" class="fragment"></span><a href="#%E5%AE%9F%E8%A1%8C%E5%BD%A2%E5%BC%8Fout"><i class="fa fa-link"></i></a>実行形式(.out)</h2>

<ul>
<li>ELF形式</li>
<li>各オブジェクトファイルのセクションがセグメントにマージされる</li>
<li>プログラムヘッダに記載される情報(一部)

<ul>
<li>ロード対象フラグ</li>
<li>ロード先の仮想アドレス</li>
<li>セグメントのサイズ など</li>
</ul>
</li>
<li>ローダはプログラムヘッダを見て、各セグメントを仮想メモリにマッピングしていく</li>
</ul>

<h1>
<span id="リンカについて" class="fragment"></span><a href="#%E3%83%AA%E3%83%B3%E3%82%AB%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><i class="fa fa-link"></i></a>リンカについて</h1>

<h2>
<span id="リンク動作順番" class="fragment"></span><a href="#%E3%83%AA%E3%83%B3%E3%82%AF%E5%8B%95%E4%BD%9C%E9%A0%86%E7%95%AA"><i class="fa fa-link"></i></a>リンク動作順番</h2>

<ol>
<li>各オブジェクトファイルのセクションをマージしてまとめる。そしてマージしたセクション同士を意味のある単位でセグメント(ローダーがメモリにロードする単位)にまとめる。</li>
<li>関数、変数の実体が存在する各セクションをメモリのどの番地に配置されるかリンカスクリプトを参照してプログラムヘッダを作成する。結果、変数、関数の番地が決定する(再配置)</li>
<li>変数、関数のアドレスが決まったのでシンボルテーブル(.symtabセクション)の各変数、関数のアドレス欄を埋める。</li>
<li>シンボルテーブルを元に各セクションで<code>空欄</code>(再配置情報)になっていた箇所に<code>アドレスを補充</code>。 (名前解決=シンボル解決)</li>
<li>実行形式として出力する。</li>
</ol>

<h1>
<span id="ローダー" class="fragment"></span><a href="#%E3%83%AD%E3%83%BC%E3%83%80%E3%83%BC"><i class="fa fa-link"></i></a>ローダー</h1>

<p>リンカが作成した実行形式をメモリ上に展開する(仮想メモリにマッピング)</p>

<h1>
<span id="補足" class="fragment"></span><a href="#%E8%A3%9C%E8%B6%B3"><i class="fa fa-link"></i></a>補足</h1>

<h2>
<span id="シンボルテーブルsymtabセクション" class="fragment"></span><a href="#%E3%82%B7%E3%83%B3%E3%83%9C%E3%83%AB%E3%83%86%E3%83%BC%E3%83%96%E3%83%ABsymtab%E3%82%BB%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3"><i class="fa fa-link"></i></a>シンボルテーブル(.symtabセクション)</h2>

<p>関数・変数が配置されるメモリ上のアドレスとシンボル名の表。オブジェクトファイルはシンボルを管理するシンボルテーブルを持っている。.symtabセクションに入っている。</p>

<p>実行形式のシンボルテーブル</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="c"># nm a.out </span>
・
・
0000000000400440 T _start
0000000000601034 b completed.6337
0000000000601030 W data_start
0000000000400470 t deregister_tm_clones
0000000000400500 t frame_dummy
0000000000400530 T main
                 U <span class="nb">printf</span>@@GLIBC_2.2.5
00000000004004a0 t register_tm_clones
</code></pre></div></div>

<p>リンク後はmainにアドレスが割り当てられていて、printは共有ライブラリで実行時にアドレスが決定するので空欄。</p>

<h4>
<span id="再配置情報" class="fragment"></span><a href="#%E5%86%8D%E9%85%8D%E7%BD%AE%E6%83%85%E5%A0%B1"><i class="fa fa-link"></i></a>再配置情報</h4>

<p>オブジェクトファイルはリンク前の段階なので変数、関数を参照する箇所は空欄になっている(リンク前でアドレスを決められないので)。この空欄のことを<code>再配置情報</code>と呼ぶ。.relxxx＆.relaxxxに入ってる。xxxは各セクション名。この二つは再配置情報の格納方法が異るみたい。</p>

<ul>
<li>再配置情報は空欄ごとにあるので、関数や変数を参照する数だけある。</li>
<li>
<code>シンボルテーブル</code>は関数、変数の定義の数だけ。</li>
</ul>

<p>再配置情報を見てみる</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="c"># readelf -r hello.o</span>

再配置セクション <span class="s1">'.rela.text'</span> <span class="o">(</span>オフセット 0x600<span class="o">)</span> は 10 個のエントリから構成されています:
  オフセット      情報           型             シンボル値    シンボル名 + 加数
000000000023  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
00000000002d  000a00000002 R_X86_64_PC32     0000000000000000 <span class="nb">printf</span> - 4
000000000037  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
000000000041  000a00000002 R_X86_64_PC32     0000000000000000 <span class="nb">printf</span> - 4
00000000004b  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
000000000055  000a00000002 R_X86_64_PC32     0000000000000000 <span class="nb">printf</span> - 4
00000000005f  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
000000000069  000a00000002 R_X86_64_PC32     0000000000000000 <span class="nb">printf</span> - 4
00000000006e  00050000000a R_X86_64_32       0000000000000000 .rodata + 3
000000000078  000a00000002 R_X86_64_PC32     0000000000000000 <span class="nb">printf</span> - 4
</code></pre></div></div>

<p>printfが複数ある。printfを参照している数だけある。</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="c"># nm hello.o</span>
0000000000000000 T main
                 U <span class="nb">printf</span>
</code></pre></div></div>

<p>シンボルテーブルは定義の数のみ。</p>

<h2>
<span id="リンカの実体" class="fragment"></span><a href="#%E3%83%AA%E3%83%B3%E3%82%AB%E3%81%AE%E5%AE%9F%E4%BD%93"><i class="fa fa-link"></i></a>リンカの実体</h2>

<p><a href="http://qiita.com/saikoro-steak/items/a9d1576d9c14706bdde6" id="reference-0b8821a95f1ca759c171">ソースコードから実行形式を作成するまでの流れ</a>で書いたように、CentOS7のGCCの場合だと<code>/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/collect2</code>ただcollcect2はGNUのldである<code>/usr/bin/ld</code>を使っている。LinuxではGNUのldが一般的みたい。ただし、リンカはOSに強く依存するものなのでOS毎にリンカが存在している。Microsoftではlink、solarisならsolarisのld。なのでGCCは環境に応じてリンカを使い分けるので、collect2はその共通のラッパーになっている。</p>

<h2>
<span id="実行形式のプログラムヘッダ" class="fragment"></span><a href="#%E5%AE%9F%E8%A1%8C%E5%BD%A2%E5%BC%8F%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%83%98%E3%83%83%E3%83%80"><i class="fa fa-link"></i></a>実行形式のプログラムヘッダ</h2>

<p>これもELF形式。各セクションを意味的にまとめたプログラムヘッダが作られる。プログラムヘッダをみてみた。</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="c"># readelf -l a.out </span>

Elf ファイルタイプは EXEC <span class="o">(</span>実行可能ファイル<span class="o">)</span> です
エントリポイント 0x400440
9 個のプログラムヘッダ、始点オフセット 64

プログラムヘッダ:
  タイプ        オフセット          仮想Addr           物理Addr
            ファイルサイズ        メモリサイズ         フラグ 整列
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      <span class="o">[</span>要求されるプログラムインタプリタ: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000077c 0x000000000000077c  R E    200000
  LOAD           0x0000000000000e10 0x0000000000600e10 0x0000000000600e10
                 0x0000000000000224 0x0000000000000228  RW     200000
  DYNAMIC        0x0000000000000e28 0x0000000000600e28 0x0000000000600e28
                 0x00000000000001d0 0x00000000000001d0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x0000000000000654 0x0000000000400654 0x0000000000400654
                 0x0000000000000034 0x0000000000000034  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x0000000000000e10 0x0000000000600e10 0x0000000000600e10
                 0x00000000000001f0 0x00000000000001f0  R      1

 セグメントマッピングへのセクション:
  セグメントセクション...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag .note.gnu.build-id 
   06     .eh_frame_hdr 
   07     
   08     .init_array .fini_array .jcr .dynamic .got
</code></pre></div></div>

<p>00~08が各セクションを意味的にまとめている番号。上と下は順番が対応している。LOADはローダーがメモリにロードする箇所。オフセットはELFの先頭からの位置。</p>


リンカ＆ローダーの役割 自分メモメモ

### 概要
GCCを使ってソースコードから実行形式を作成するまでの流れをみてみた。

### 環境
x86_64
centos7
gcc4.8.3

### helloWorld

~~~hello.c
#include <stdio.h>

int main(){
    printf("Hello world!!");
}
~~~
### GCC
コンパイルしてみる

~~~sh
# gcc hello.c -Wall -v
組み込み spec を使用しています。
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
ターゲット: x86_64-redhat-linux
configure 設定: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
スレッドモデル: posix
gcc バージョン 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) 
COLLECT_GCC_OPTIONS='-Wall' '-v' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.3/cc1 -quiet -v hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -Wall -version -o /tmp/ccyCCZPY.s
GNU C (GCC) version 4.8.3 20140911 (Red Hat 4.8.3-9) (x86_64-redhat-linux)
        compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-9), GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1
warning: GMP header version 5.1.1 differs from library version 6.0.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
存在しないディレクトリ "/usr/lib/gcc/x86_64-redhat-linux/4.8.3/include-fixed" を無視します
存在しないディレクトリ "/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../x86_64-redhat-linux/include" を無視します
#include "..." の探索はここから始まります:
#include <...> の探索はここから始まります:
 /usr/lib/gcc/x86_64-redhat-linux/4.8.3/include
 /usr/local/include
 /usr/include
探索リストの終わりです。
GNU C (GCC) version 4.8.3 20140911 (Red Hat 4.8.3-9) (x86_64-redhat-linux)
        compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-9), GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1
warning: GMP header version 5.1.1 differs from library version 6.0.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0cfa3e41c61de51fe5b3d2388f47f98a
hello.c: 関数 ‘main’ 内:
hello.c:5:1: 警告: 制御が非 void 関数の終りに到達しました [-Wreturn-type]
 }
 ^
COLLECT_GCC_OPTIONS='-Wall' '-v' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccYhWWtz.o /tmp/ccyCCZPY.s
GNU アセンブラ バージョン 2.23.52.0.1 (x86_64-redhat-linux)、BFD バージョン version 2.23.52.0.1-30.el7_1.2 20130226 を使用
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/:/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.8.3/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.8.3/:/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-Wall' '-v' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.3/collect2 --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 
-dynamic-linker /lib64/ld-linux-x86-64.so.2 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crt1.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crti.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtbegin.o 
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.3
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64 
-L/lib/../lib64 
-L/usr/lib/../lib64 
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../.. 
/tmp/ccYhWWtz.o 
-lgcc --as-needed -lgcc_s --no-as-needed 
-lc 
-lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtend.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crtn.o
~~~

#### 組み込みスペック
[組み込みスペックとは](http://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file)
>A specs file is plain text used to control the default behavior for the "gcc" front-end.

普通内部に持って行て、外部で持てば上書きできるみたい。そういうものみたい。

#### COLLECT_LTO_WRAPPER
GCCが使うプラグインで、作業を効率的にするために内部で使用しているみたい。

#### configure 設定:
GCCをビルドした時のconfigureの設定がみれるみたい。

#### コンパイル
`/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/cc1`がコンパイラの実体。-oで指定されている`/tmp/ccyCCZPY.s`にコンパイルされたアセンブラが出力される。

~~~sh
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.3/cc1 
-quiet -v hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -Wall -version -o /tmp/ccyCCZPY.s
~~~

#### アセンブラ
コンパイルで出力されたアセンブラファイル`/tmp/ccyCCZPY.s`を入力値としてオブジェクトファイル`/tmp/ccYhWWtz.o`
を出力する。

~~~sh
as -v --64 -o /tmp/ccYhWWtz.o /tmp/ccyCCZPY.s
~~~


#### リンカ
`/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/collect2`がリンカの実体。
アセンぶりしたオブジェクトファイル`/tmp/ccYhWWtz.o`と様々なオブジェクトとリンクして実行形式を作成する。

#### ダイナミックリンカ指定
GCCは特に何も指定しなければ、共有ライブラリをダイナミックリンクする。なのでプログラム実行時にリンクしてくれるダイナミックリンカを指定している。-staticを指定すれば共有ライブラリも静的にリンクする。ダイナミックリンク→[動的なリンカ](http://qiita.com/saikoro-steak/items/5d90ae34b61c16f6b3cf)
`-dynamic-linker /lib64/ld-linux-x86-64.so.2`

##### 暗黙的にリンクするやつ
下のこれらがCのmainの前に呼ばれて色々準備したり、プログラムが終了するまえに呼ばれて後始末する。これは普通に静的にリンクされるはず。

1. crtn.o
2. crtend.o
3. crtbegin.o
4. crti.o
5. crt1.o

##### 他にもライブラリをリンクする
#### -l
-lの後についたxxxを取り出してダイナミックリンクの場合はlibxxx.soを静的リンクの場合はlibxxx.aをリンクする。ダイナミックリンクの場合でもsoがなければ.aを探すみたい。
今回xxxはcでダイナミックリンクなので`libc.so`(標準Cライブラリ)をリンクする
したみたいな感じ。(動的リンクされるはず)

~~~sh
ldd a.out 
    linux-gate.so.1 =>  (0xb776e000)
    libc.so.6 => /lib/libc.so.6 (0x49cbd000)
    /lib/ld-linux.so.2 (0x49c95000)
~~~

#### -L
ライブラリの検索場所を指定

### まとめ
コンパイラは以下の順番で実行形式を作成している。(んープリプロセッサの指定がないような。。)
1. プリプロセス
2. コンパイル
3. アセンブル
4. リンク

GCCは内部で様々な作業をしてくれる。コンパイラ狭義の意味としての実体はcc1になる。ただしリンクまで行うことをコンパイルとも呼ぶし、ビルドとも呼ぶ。helloworldするだけのCをコンパイルするだけでも様々なオブジェクトをリンクしていることがわかる。



<h3>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h3>

<p>GCCを使ってソースコードから実行形式を作成するまでの流れをみてみた。</p>

<h3>
<span id="環境" class="fragment"></span><a href="#%E7%92%B0%E5%A2%83"><i class="fa fa-link"></i></a>環境</h3>

<p>x86_64<br>
centos7<br>
gcc4.8.3</p>

<h3>
<span id="helloworld" class="fragment"></span><a href="#helloworld"><i class="fa fa-link"></i></a>helloWorld</h3>

<div class="code-frame" data-lang="c">
<div class="code-lang"><span class="bold">hello.c</span></div>
<div class="highlight"><pre><code><span class="cp">#include &lt;stdio.h&gt;
</span>
<span class="kt">int</span> <span class="nf">main</span><span class="p">(){</span>
    <span class="n">printf</span><span class="p">(</span><span class="s">"Hello world!!"</span><span class="p">);</span>
<span class="p">}</span>
</code></pre></div>
</div>

<h3>
<span id="gcc" class="fragment"></span><a href="#gcc"><i class="fa fa-link"></i></a>GCC</h3>

<p>コンパイルしてみる</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="c"># gcc hello.c -Wall -v</span>
組み込み spec を使用しています。
<span class="nv">COLLECT_GCC</span><span class="o">=</span>gcc
<span class="nv">COLLECT_LTO_WRAPPER</span><span class="o">=</span>/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
ターゲット: x86_64-redhat-linux
configure 設定: ../configure <span class="nt">--prefix</span><span class="o">=</span>/usr <span class="nt">--mandir</span><span class="o">=</span>/usr/share/man <span class="nt">--infodir</span><span class="o">=</span>/usr/share/info <span class="nt">--with-bugurl</span><span class="o">=</span>http://bugzilla.redhat.com/bugzilla <span class="nt">--enable-bootstrap</span> <span class="nt">--enable-shared</span> <span class="nt">--enable-threads</span><span class="o">=</span>posix <span class="nt">--enable-checking</span><span class="o">=</span>release <span class="nt">--with-system-zlib</span> <span class="nt">--enable-__cxa_atexit</span> <span class="nt">--disable-libunwind-exceptions</span> <span class="nt">--enable-gnu-unique-object</span> <span class="nt">--enable-linker-build-id</span> <span class="nt">--with-linker-hash-style</span><span class="o">=</span>gnu <span class="nt">--enable-languages</span><span class="o">=</span>c,c++,objc,obj-c++,java,fortran,ada,go,lto <span class="nt">--enable-plugin</span> <span class="nt">--enable-initfini-array</span> <span class="nt">--disable-libgcj</span> <span class="nt">--with-isl</span><span class="o">=</span>/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install <span class="nt">--with-cloog</span><span class="o">=</span>/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install <span class="nt">--enable-gnu-indirect-function</span> <span class="nt">--with-tune</span><span class="o">=</span>generic <span class="nt">--with-arch_32</span><span class="o">=</span>x86-64 <span class="nt">--build</span><span class="o">=</span>x86_64-redhat-linux
スレッドモデル: posix
gcc バージョン 4.8.3 20140911 <span class="o">(</span>Red Hat 4.8.3-9<span class="o">)</span> <span class="o">(</span>GCC<span class="o">)</span> 
<span class="nv">COLLECT_GCC_OPTIONS</span><span class="o">=</span><span class="s1">'-Wall'</span> <span class="s1">'-v'</span> <span class="s1">'-mtune=generic'</span> <span class="s1">'-march=x86-64'</span>
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.3/cc1 <span class="nt">-quiet</span> <span class="nt">-v</span> hello.c <span class="nt">-quiet</span> <span class="nt">-dumpbase</span> hello.c <span class="nt">-mtune</span><span class="o">=</span>generic <span class="nt">-march</span><span class="o">=</span>x86-64 <span class="nt">-auxbase</span> hello <span class="nt">-Wall</span> <span class="nt">-version</span> <span class="nt">-o</span> /tmp/ccyCCZPY.s
GNU C <span class="o">(</span>GCC<span class="o">)</span> version 4.8.3 20140911 <span class="o">(</span>Red Hat 4.8.3-9<span class="o">)</span> <span class="o">(</span>x86_64-redhat-linux<span class="o">)</span>
        compiled by GNU C version 4.8.3 20140911 <span class="o">(</span>Red Hat 4.8.3-9<span class="o">)</span>, GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1
warning: GMP header version 5.1.1 differs from library version 6.0.0.
GGC heuristics: <span class="nt">--param</span> ggc-min-expand<span class="o">=</span>100 <span class="nt">--param</span> ggc-min-heapsize<span class="o">=</span>131072
存在しないディレクトリ <span class="s2">"/usr/lib/gcc/x86_64-redhat-linux/4.8.3/include-fixed"</span> を無視します
存在しないディレクトリ <span class="s2">"/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../x86_64-redhat-linux/include"</span> を無視します
<span class="c">#include "..." の探索はここから始まります:</span>
<span class="c">#include &lt;...&gt; の探索はここから始まります:</span>
 /usr/lib/gcc/x86_64-redhat-linux/4.8.3/include
 /usr/local/include
 /usr/include
探索リストの終わりです。
GNU C <span class="o">(</span>GCC<span class="o">)</span> version 4.8.3 20140911 <span class="o">(</span>Red Hat 4.8.3-9<span class="o">)</span> <span class="o">(</span>x86_64-redhat-linux<span class="o">)</span>
        compiled by GNU C version 4.8.3 20140911 <span class="o">(</span>Red Hat 4.8.3-9<span class="o">)</span>, GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1
warning: GMP header version 5.1.1 differs from library version 6.0.0.
GGC heuristics: <span class="nt">--param</span> ggc-min-expand<span class="o">=</span>100 <span class="nt">--param</span> ggc-min-heapsize<span class="o">=</span>131072
Compiler executable checksum: 0cfa3e41c61de51fe5b3d2388f47f98a
hello.c: 関数 ‘main’ 内:
hello.c:5:1: 警告: 制御が非 void 関数の終りに到達しました <span class="o">[</span><span class="nt">-Wreturn-type</span><span class="o">]</span>
 <span class="o">}</span>
 ^
<span class="nv">COLLECT_GCC_OPTIONS</span><span class="o">=</span><span class="s1">'-Wall'</span> <span class="s1">'-v'</span> <span class="s1">'-mtune=generic'</span> <span class="s1">'-march=x86-64'</span>
 as <span class="nt">-v</span> <span class="nt">--64</span> <span class="nt">-o</span> /tmp/ccYhWWtz.o /tmp/ccyCCZPY.s
GNU アセンブラ バージョン 2.23.52.0.1 <span class="o">(</span>x86_64-redhat-linux<span class="o">)</span>、BFD バージョン version 2.23.52.0.1-30.el7_1.2 20130226 を使用
<span class="nv">COMPILER_PATH</span><span class="o">=</span>/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/:/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.8.3/:/usr/lib/gcc/x86_64-redhat-linux/
<span class="nv">LIBRARY_PATH</span><span class="o">=</span>/usr/lib/gcc/x86_64-redhat-linux/4.8.3/:/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../:/lib/:/usr/lib/
<span class="nv">COLLECT_GCC_OPTIONS</span><span class="o">=</span><span class="s1">'-Wall'</span> <span class="s1">'-v'</span> <span class="s1">'-mtune=generic'</span> <span class="s1">'-march=x86-64'</span>
 /usr/libexec/gcc/x86_64-redhat-linux/4.8.3/collect2 <span class="nt">--build-id</span> <span class="nt">--no-add-needed</span> <span class="nt">--eh-frame-hdr</span> <span class="nt">--hash-style</span><span class="o">=</span>gnu <span class="nt">-m</span> elf_x86_64 
<span class="nt">-dynamic-linker</span> /lib64/ld-linux-x86-64.so.2 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crt1.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crti.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtbegin.o 
<span class="nt">-L</span>/usr/lib/gcc/x86_64-redhat-linux/4.8.3
<span class="nt">-L</span>/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64 
<span class="nt">-L</span>/lib/../lib64 
<span class="nt">-L</span>/usr/lib/../lib64 
<span class="nt">-L</span>/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../.. 
/tmp/ccYhWWtz.o 
<span class="nt">-lgcc</span> <span class="nt">--as-needed</span> <span class="nt">-lgcc_s</span> <span class="nt">--no-as-needed</span> 
<span class="nt">-lc</span> 
<span class="nt">-lgcc</span> <span class="nt">--as-needed</span> <span class="nt">-lgcc_s</span> <span class="nt">--no-as-needed</span> 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtend.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crtn.o
</code></pre></div></div>

<h4>
<span id="組み込みスペック" class="fragment"></span><a href="#%E7%B5%84%E3%81%BF%E8%BE%BC%E3%81%BF%E3%82%B9%E3%83%9A%E3%83%83%E3%82%AF"><i class="fa fa-link"></i></a>組み込みスペック</h4>

<p><a href="http://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file" rel="nofollow noopener" target="_blank">組み込みスペックとは</a></p>

<blockquote>
<p>A specs file is plain text used to control the default behavior for the "gcc" front-end.</p>
</blockquote>

<p>普通内部に持って行て、外部で持てば上書きできるみたい。そういうものみたい。</p>

<h4>
<span id="collect_lto_wrapper" class="fragment"></span><a href="#collect_lto_wrapper"><i class="fa fa-link"></i></a>COLLECT_LTO_WRAPPER</h4>

<p>GCCが使うプラグインで、作業を効率的にするために内部で使用しているみたい。</p>

<h4>
<span id="configure-設定" class="fragment"></span><a href="#configure-%E8%A8%AD%E5%AE%9A"><i class="fa fa-link"></i></a>configure 設定:</h4>

<p>GCCをビルドした時のconfigureの設定がみれるみたい。</p>

<h4>
<span id="コンパイル" class="fragment"></span><a href="#%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB"><i class="fa fa-link"></i></a>コンパイル</h4>

<p><code>/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/cc1</code>がコンパイラの実体。-oで指定されている<code>/tmp/ccyCCZPY.s</code>にコンパイルされたアセンブラが出力される。</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code> /usr/libexec/gcc/x86_64-redhat-linux/4.8.3/cc1 
<span class="nt">-quiet</span> <span class="nt">-v</span> hello.c <span class="nt">-quiet</span> <span class="nt">-dumpbase</span> hello.c <span class="nt">-mtune</span><span class="o">=</span>generic <span class="nt">-march</span><span class="o">=</span>x86-64 <span class="nt">-auxbase</span> hello <span class="nt">-Wall</span> <span class="nt">-version</span> <span class="nt">-o</span> /tmp/ccyCCZPY.s
</code></pre></div></div>

<h4>
<span id="アセンブラ" class="fragment"></span><a href="#%E3%82%A2%E3%82%BB%E3%83%B3%E3%83%96%E3%83%A9"><i class="fa fa-link"></i></a>アセンブラ</h4>

<p>コンパイルで出力されたアセンブラファイル<code>/tmp/ccyCCZPY.s</code>を入力値としてオブジェクトファイル<code>/tmp/ccYhWWtz.o</code><br>
を出力する。</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>as <span class="nt">-v</span> <span class="nt">--64</span> <span class="nt">-o</span> /tmp/ccYhWWtz.o /tmp/ccyCCZPY.s
</code></pre></div></div>

<h4>
<span id="リンカ" class="fragment"></span><a href="#%E3%83%AA%E3%83%B3%E3%82%AB"><i class="fa fa-link"></i></a>リンカ</h4>

<p><code>/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/collect2</code>がリンカの実体。<br>
アセンぶりしたオブジェクトファイル<code>/tmp/ccYhWWtz.o</code>と様々なオブジェクトとリンクして実行形式を作成する。</p>

<h4>
<span id="ダイナミックリンカ指定" class="fragment"></span><a href="#%E3%83%80%E3%82%A4%E3%83%8A%E3%83%9F%E3%83%83%E3%82%AF%E3%83%AA%E3%83%B3%E3%82%AB%E6%8C%87%E5%AE%9A"><i class="fa fa-link"></i></a>ダイナミックリンカ指定</h4>

<p>GCCは特に何も指定しなければ、共有ライブラリをダイナミックリンクする。なのでプログラム実行時にリンクしてくれるダイナミックリンカを指定している。-staticを指定すれば共有ライブラリも静的にリンクする。ダイナミックリンク→<a href="http://qiita.com/saikoro-steak/items/5d90ae34b61c16f6b3cf" id="reference-00d8d52b6b10837f4f7c">動的なリンカ</a><br>
<code>-dynamic-linker /lib64/ld-linux-x86-64.so.2</code></p>

<h5>
<span id="暗黙的にリンクするやつ" class="fragment"></span><a href="#%E6%9A%97%E9%BB%99%E7%9A%84%E3%81%AB%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%99%E3%82%8B%E3%82%84%E3%81%A4"><i class="fa fa-link"></i></a>暗黙的にリンクするやつ</h5>

<p>下のこれらがCのmainの前に呼ばれて色々準備したり、プログラムが終了するまえに呼ばれて後始末する。これは普通に静的にリンクされるはず。</p>

<ol>
<li>crtn.o</li>
<li>crtend.o</li>
<li>crtbegin.o</li>
<li>crti.o</li>
<li>crt1.o</li>
</ol>

<h5>
<span id="他にもライブラリをリンクする" class="fragment"></span><a href="#%E4%BB%96%E3%81%AB%E3%82%82%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%82%92%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%99%E3%82%8B"><i class="fa fa-link"></i></a>他にもライブラリをリンクする</h5>

<h4>
<span id="-l" class="fragment"></span><a href="#-l"><i class="fa fa-link"></i></a>-l</h4>

<p>-lの後についたxxxを取り出してダイナミックリンクの場合はlibxxx.soを静的リンクの場合はlibxxx.aをリンクする。ダイナミックリンクの場合でもsoがなければ.aを探すみたい。<br>
今回xxxはcでダイナミックリンクなので<code>libc.so</code>(標準Cライブラリ)をリンクする<br>
したみたいな感じ。(動的リンクされるはず)</p>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code>ldd a.out 
    linux-gate.so.1 <span class="o">=&gt;</span>  <span class="o">(</span>0xb776e000<span class="o">)</span>
    libc.so.6 <span class="o">=&gt;</span> /lib/libc.so.6 <span class="o">(</span>0x49cbd000<span class="o">)</span>
    /lib/ld-linux.so.2 <span class="o">(</span>0x49c95000<span class="o">)</span>
</code></pre></div></div>

<h4>
<span id="-l-1" class="fragment"></span><a href="#-l-1"><i class="fa fa-link"></i></a>-L</h4>

<p>ライブラリの検索場所を指定</p>

<h3>
<span id="まとめ" class="fragment"></span><a href="#%E3%81%BE%E3%81%A8%E3%82%81"><i class="fa fa-link"></i></a>まとめ</h3>

<p>コンパイラは以下の順番で実行形式を作成している。(んープリプロセッサの指定がないような。。)<br>
1. プリプロセス<br>
2. コンパイル<br>
3. アセンブル<br>
4. リンク</p>

<p>GCCは内部で様々な作業をしてくれる。コンパイラ狭義の意味としての実体はcc1になる。ただしリンクまで行うことをコンパイルとも呼ぶし、ビルドとも呼ぶ。helloworldするだけのCをコンパイルするだけでも様々なオブジェクトをリンクしていることがわかる。</p>


ソースコードから実行形式を作成するまでの流れ

カーネル探検(rest_init()からプロセス番号1生成まで)

# 概要
カーネル処理のstart_kernel()の処理を途中まで見てみた。


# 前回
[start_kernel()以前](http://qiita.com/saikoro-steak/items/60f5ab6cb9d0f825df25)


# 今回 start_kernel()からrest_init()の途中まで
start_kernelは様々なモジュールを初期化して、内容は盛り沢山。なので今回も自分が気になる箇所だけを切り取りしてみる。

## 処理概要
* start_kernel()
    - カーネル環境の初期化
    - sched_init() ランキューの初期化
    - fork_init() タスク数の上限の設定
    - signal_init() シグナルキューの作成

↓

* setup_arch()
    - 機種依存な初期化処理
    - initプロセス用のメモリ構造体に初期値を設定
    - ページテーブルの作成

↓

* mm_init()
    - page構造体とメモリアロケータの初期化

↓

* rest_init()
    - kernel_thread(kernel_init,...)
    - kernel_thread(kerneladd,...)
    - schdule()
    - cpu_idle()
 
## start_kernel()
前回の続きから。とりあえず、start_kernelに入った直後にレジスタをみてみた。

```
(gdb) i r
```
![startkernelスタック.png](https://qiita-image-store.s3.amazonaws.com/0/91729/01c6c292-3ee5-acd4-851c-5aabd690948d.png)

スタックポインタを見てみると現在、実行している処理はinit_thread_unionところのスタックを利用している。これは前回みたスタックを静的に定義していた箇所のこと。やはりinit(プロセス番号1)というより現在の処理(swapper)が利用するスタックということでよいはず。

## setup_arch()
start_kernel() → setup_arch()

initプロセス用のメモリ構造体に初期値を設定している

```c
init_mm.start_code = (unsigned long) _text;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
init_mm.brk = _brk_end;
```
メモ：
 \_textなどはリンカースクリプト(下記載)に記載されている。


```:カーネルリンカースクリプト(arch/x86/kernel/vmlinux.lds.S)
    SECTIONS
 84 {
 85 #ifdef CONFIG_X86_32
 86         . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR;
 87         phys_startup_32 = startup_32 - LOAD_OFFSET;
 88 #else
 89         . = __START_KERNEL;
 90         phys_startup_64 = startup_64 - LOAD_OFFSET;
 91 #endif
 92 
 93         /* Text and read-only data */
 94         .text :  AT(ADDR(.text) - LOAD_OFFSET) {
 95                 _text = .;
 96                 /* bootstrapping code */
 97                 HEAD_TEXT
 98 #ifdef CONFIG_X86_32
 99                 . = ALIGN(PAGE_SIZE);
100                 *(.text.page_aligned)
101 #endif
102                 . = ALIGN(8);
103                 _stext = .;
```

メモ：
これがカーネルのリンカースクリプト。カーネルの実行ファイル(vmlinuz)を作成するときにこのリンカースクリプトをみてリンクするオブジェクトファイルの各セクションをまとめたり、そのセクションが仮想メモリ上でどのアドレスに配置されるのかが記載されている。利用するのはオブジェクトファイルをリンクする時。

## GDBで変数中身と/proc/iomemと/boot/System.mapを見比べてみた

setup_arch()の中の_textなどがどこのカーネルの仮想アドレスに配置されているのか調べてみた。

GDB

```gdb
(gdb) print /x _text
$20 = 0xffffffff81000000 <startup_64>
(gdb) print /x _etext
$21 = 0xffffffff81619285
(gdb) print /x _edata
$22 = 0xffffffff81a2ddc0
(gdb) print /x _brk_end
$23 = 0xffffffff81ee4000
```

メモ：
* 0x1000000がカーネルのエントリポイント(startup_64())でそれは**物理アドレス**
* 0xffffffff81000000 **仮想アドレス**にリンクされている。
* GDBで表示したアドレスと一致している

```bash

# cat /proc/iomem 
  000f0000-000fffff : System ROM
  00100000-dd7a173f : System RAM
  01000000-01619284 : Kernel code
  01619285-01a2ddbf : Kernel data
  01bc7000-01ee3fff : Kernel bss
  2b000000-350fffff : Crash kernel
```

* /boot/System.map-カーネルバージョン

```bash

  271 0000000001000000 A phys_startup_64
  272 ffffffff81000000 T _text
  273 ffffffff81000000 T startup_64
  274 ffffffff81000110 T secondary_startup_64
  275 ffffffff810001b0 T start_cpu0
  276 ffffffff810001c5 t bad_address

28218 ffffffff81618b60 T bad_from_user
28219 ffffffff81618b66 t bad_to_user
28220 ffffffff81619285 T _etext
28221 ffffffff81619288 T __start_notes
28222 ffffffff81619404 T __stop_notes
28223 ffffffff81619410 R __start___ex_table

62139 ffffffff81a2d560 D inet6_protos
62140 ffffffff81a2dd60 d ipv6_packet_offload
62141 ffffffff81a2ddc0 D _edata
62142 ffffffff81a2e000 D __vvar_beginning_hack
62143 ffffffff81a2e000 D __vvar_page
62144 ffffffff81a2e000 D jiffies

69959 ffffffff81ee30e0 b net_header
69960 ffffffff81ee30e8 b klist_remove_lock
69961 ffffffff81ee4000 B __brk_base
69962 ffffffff81ee4000 B __bss_stop
69963 ffffffff81ef4000 b .brk.shared_info_page_brk
69964 ffffffff81ef5000 b .brk.p2m_missing

```

# まとめ
start_kernel()はカーネル環境の様々な初期化をして最後にrest_init()を呼び出して終わる。



<h1>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h1>

<p>カーネル処理のstart_kernel()の処理を途中まで見てみた。</p>

<h1>
<span id="前回" class="fragment"></span><a href="#%E5%89%8D%E5%9B%9E"><i class="fa fa-link"></i></a>前回</h1>

<p><a href="http://qiita.com/saikoro-steak/items/60f5ab6cb9d0f825df25" id="reference-1afe0a30b7154c02ef4a">start_kernel()以前</a></p>

<h1>
<span id="今回-start_kernelからrest_initの途中まで" class="fragment"></span><a href="#%E4%BB%8A%E5%9B%9E-start_kernel%E3%81%8B%E3%82%89rest_init%E3%81%AE%E9%80%94%E4%B8%AD%E3%81%BE%E3%81%A7"><i class="fa fa-link"></i></a>今回 start_kernel()からrest_init()の途中まで</h1>

<p>start_kernelは様々なモジュールを初期化して、内容は盛り沢山。なので今回も自分が気になる箇所だけを切り取りしてみる。</p>

<h2>
<span id="処理概要" class="fragment"></span><a href="#%E5%87%A6%E7%90%86%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>処理概要</h2>

<ul>
<li>start_kernel()

<ul>
<li>カーネル環境の初期化</li>
<li>sched_init() ランキューの初期化</li>
<li>fork_init() タスク数の上限の設定</li>
<li>signal_init() シグナルキューの作成</li>
</ul>
</li>
</ul>

<p>↓</p>

<ul>
<li>setup_arch()

<ul>
<li>機種依存な初期化処理</li>
<li>initプロセス用のメモリ構造体に初期値を設定</li>
<li>ページテーブルの作成</li>
</ul>
</li>
</ul>

<p>↓</p>

<ul>
<li>mm_init()

<ul>
<li>page構造体とメモリアロケータの初期化</li>
</ul>
</li>
</ul>

<p>↓</p>

<ul>
<li>rest_init()

<ul>
<li>kernel_thread(kernel_init,...)</li>
<li>kernel_thread(kerneladd,...)</li>
<li>schdule()</li>
<li>cpu_idle()</li>
</ul>
</li>
</ul>

<h2>
<span id="start_kernel" class="fragment"></span><a href="#start_kernel"><i class="fa fa-link"></i></a>start_kernel()</h2>

<p>前回の続きから。とりあえず、start_kernelに入った直後にレジスタをみてみた。</p>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>(gdb) i r
</code></pre></div></div>

<p><a href="https://camo.qiitausercontent.com/a09ad537ae3a5c51758cc47156d88fd7c4c99368/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f39313732392f30316336633239322d336565352d616364342d383531632d3561616264363930393438642e706e67" target="_blank" rel="nofollow noopener"><img src="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F91729%2F01c6c292-3ee5-acd4-851c-5aabd690948d.png?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;s=ccd0a641a1aae157e6206b6dd8a39e95" alt="startkernelスタック.png" data-canonical-src="https://qiita-image-store.s3.amazonaws.com/0/91729/01c6c292-3ee5-acd4-851c-5aabd690948d.png" srcset="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F91729%2F01c6c292-3ee5-acd4-851c-5aabd690948d.png?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;w=1400&amp;fit=max&amp;s=5d9e7ef2f2a4bda654534044800d525e 1x" loading="lazy"></a></p>

<p>スタックポインタを見てみると現在、実行している処理はinit_thread_unionところのスタックを利用している。これは前回みたスタックを静的に定義していた箇所のこと。やはりinit(プロセス番号1)というより現在の処理(swapper)が利用するスタックということでよいはず。</p>

<h2>
<span id="setup_arch" class="fragment"></span><a href="#setup_arch"><i class="fa fa-link"></i></a>setup_arch()</h2>

<p>start_kernel() → setup_arch()</p>

<p>initプロセス用のメモリ構造体に初期値を設定している</p>

<div class="code-frame" data-lang="c"><div class="highlight"><pre><code><span class="n">init_mm</span><span class="p">.</span><span class="n">start_code</span> <span class="o">=</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">long</span><span class="p">)</span> <span class="n">_text</span><span class="p">;</span>
<span class="n">init_mm</span><span class="p">.</span><span class="n">end_code</span> <span class="o">=</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">long</span><span class="p">)</span> <span class="n">_etext</span><span class="p">;</span>
<span class="n">init_mm</span><span class="p">.</span><span class="n">end_data</span> <span class="o">=</span> <span class="p">(</span><span class="kt">unsigned</span> <span class="kt">long</span><span class="p">)</span> <span class="n">_edata</span><span class="p">;</span>
<span class="n">init_mm</span><span class="p">.</span><span class="n">brk</span> <span class="o">=</span> <span class="n">_brk_end</span><span class="p">;</span>
</code></pre></div></div>

<p>メモ：<br>
 _textなどはリンカースクリプト(下記載)に記載されている。</p>

<div class="code-frame" data-lang="">
<div class="code-lang"><span class="bold">カーネルリンカースクリプト(arch/x86/kernel/vmlinux.lds.S)</span></div>
<div class="highlight"><pre><code>    SECTIONS
 84 {
 85 #ifdef CONFIG_X86_32
 86         . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR;
 87         phys_startup_32 = startup_32 - LOAD_OFFSET;
 88 #else
 89         . = __START_KERNEL;
 90         phys_startup_64 = startup_64 - LOAD_OFFSET;
 91 #endif
 92 
 93         /* Text and read-only data */
 94         .text :  AT(ADDR(.text) - LOAD_OFFSET) {
 95                 _text = .;
 96                 /* bootstrapping code */
 97                 HEAD_TEXT
 98 #ifdef CONFIG_X86_32
 99                 . = ALIGN(PAGE_SIZE);
100                 *(.text.page_aligned)
101 #endif
102                 . = ALIGN(8);
103                 _stext = .;
</code></pre></div>
</div>

<p>メモ：<br>
これがカーネルのリンカースクリプト。カーネルの実行ファイル(vmlinuz)を作成するときにこのリンカースクリプトをみてリンクするオブジェクトファイルの各セクションをまとめたり、そのセクションが仮想メモリ上でどのアドレスに配置されるのかが記載されている。利用するのはオブジェクトファイルをリンクする時。</p>

<h2>
<span id="gdbで変数中身とprociomemとbootsystemmapを見比べてみた" class="fragment"></span><a href="#gdb%E3%81%A7%E5%A4%89%E6%95%B0%E4%B8%AD%E8%BA%AB%E3%81%A8prociomem%E3%81%A8bootsystemmap%E3%82%92%E8%A6%8B%E6%AF%94%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F"><i class="fa fa-link"></i></a>GDBで変数中身と/proc/iomemと/boot/System.mapを見比べてみた</h2>

<p>setup_arch()の中の_textなどがどこのカーネルの仮想アドレスに配置されているのか調べてみた。</p>

<p>GDB</p>

<div class="code-frame" data-lang="gdb"><div class="highlight"><pre><code>(gdb) print /x _text
$20 = 0xffffffff81000000 &lt;startup_64&gt;
(gdb) print /x _etext
$21 = 0xffffffff81619285
(gdb) print /x _edata
$22 = 0xffffffff81a2ddc0
(gdb) print /x _brk_end
$23 = 0xffffffff81ee4000
</code></pre></div></div>

<p>メモ：<br>
* 0x1000000がカーネルのエントリポイント(startup_64())でそれは<strong>物理アドレス</strong><br>
* 0xffffffff81000000 <strong>仮想アドレス</strong>にリンクされている。<br>
* GDBで表示したアドレスと一致している</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>
<span class="c"># cat /proc/iomem </span>
  000f0000-000fffff : System ROM
  00100000-dd7a173f : System RAM
  01000000-01619284 : Kernel code
  01619285-01a2ddbf : Kernel data
  01bc7000-01ee3fff : Kernel bss
  2b000000-350fffff : Crash kernel
</code></pre></div></div>

<ul>
<li>/boot/System.map-カーネルバージョン</li>
</ul>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>
  271 0000000001000000 A phys_startup_64
  272 ffffffff81000000 T _text
  273 ffffffff81000000 T startup_64
  274 ffffffff81000110 T secondary_startup_64
  275 ffffffff810001b0 T start_cpu0
  276 ffffffff810001c5 t bad_address

28218 ffffffff81618b60 T bad_from_user
28219 ffffffff81618b66 t bad_to_user
28220 ffffffff81619285 T _etext
28221 ffffffff81619288 T __start_notes
28222 ffffffff81619404 T __stop_notes
28223 ffffffff81619410 R __start___ex_table

62139 ffffffff81a2d560 D inet6_protos
62140 ffffffff81a2dd60 d ipv6_packet_offload
62141 ffffffff81a2ddc0 D _edata
62142 ffffffff81a2e000 D __vvar_beginning_hack
62143 ffffffff81a2e000 D __vvar_page
62144 ffffffff81a2e000 D jiffies

69959 ffffffff81ee30e0 b net_header
69960 ffffffff81ee30e8 b klist_remove_lock
69961 ffffffff81ee4000 B __brk_base
69962 ffffffff81ee4000 B __bss_stop
69963 ffffffff81ef4000 b .brk.shared_info_page_brk
69964 ffffffff81ef5000 b .brk.p2m_missing

</code></pre></div></div>

<h1>
<span id="まとめ" class="fragment"></span><a href="#%E3%81%BE%E3%81%A8%E3%82%81"><i class="fa fa-link"></i></a>まとめ</h1>

<p>start_kernel()はカーネル環境の様々な初期化をして最後にrest_init()を呼び出して終わる。</p>


カーネル探検(start_kernel()の処理を途中まで見てみた)

# 前回
[環境構築からstart_kernel()を表示](http://qiita.com/saikoro-steak/items/6ab4d80f8f6b213eaf3f)

# 今回
やはりstart_kernel()より以前の処理も自分が気になる箇所だけをピックアップしてみた！

# 前提
* プロセス識別子 0 は swapper。後にアイドル・タスクになるやつ。
    - initを立ち上げるまでのプロセスなので、要するにブート時の初期化とかしているコンテキストそのもののこと
* プロセス識別子 1 は init

# 起動シーケンス概要
## ブートローダ
grub1を使用

```bash
$ grub --version
grub (GNU GRUB 0.97)
```
* grub1=0.9系
* grub2=1.9系

## 起動
* 電源on
↓

* BIOS起動
↓

* BiosがMBRを読み出し(stage1がメモリに展開)
↓

* ブートローダ起動(stage1)
↓

* セクタ2~64にあるstage1.5を起動
↓

* /boot/grub/stage2(stage2ブートローダ)を起動
↓

* カーネル起動
↓

* initramfs
↓

* /etc/inittab
↓

* RCスクリプト
* Upstart
* systemd


# 起動シーケンス概要詳細(電源ONからstart_kernelまで)
* 電源ON
↓

* BIOS起動
    - **0x07c00**にMBRのstage1をロード.stage1起動
    - 16bitのリアルモード(.code 16)

↓

* ブートローダ起動(stage1)
↓

* セクタ2~64にあるstage1.5を起動
    - MBRの直後から最初のパーティション手前までにある先頭30KB以内に位置するローダ起動(stage1.5起動)
    - Stage 1.5ローダのイメージはファイルシステム固有のドライバを含んでいる.stage2はファイルシステムの中にあるので

↓

* /boot/grub/stage2(stage2ブートローダ)を起動
    * /boot/grub/menu.lst(grub.conf)
    * memu.lst は grub.conf へのシンボリックリンク
    * centOSなどでもgrub.confを使用しますが、ディストリビューションによってはmemu.lstが使用されます。ディストリビューション間の互換性のためシンボリックリンクの設定が行われているようです。

```bash
$ ll /boot/grub/menu.lst
lrwxrwxrwx. 1 root root 11 Sep 28  2016 /boot/grub/menu.lst -> ./grub.conf
```

↓

* stage2
    - リアルモードから32bitプロテクトモードへ(.code 32)
    - アセンブラには`.code 32`の記述がある。バイナリが32ビット用に生成される。

↓

* arch/x86/boot/compressed/bead_64S/の解凍コード実行
    - 0x1000000に圧縮されたままのカーネル(vmlinuz)をロード&解凍(解凍先も0x1000000)
    - **0x1000000**は物理アドレス

↓

* 解凍コードの中で64bitモード移行

↓

* jmp \*%rbp(カーネルの**エントリポイントにジャンプ0x1000000**)
    - **0x1000000**はカーネルヘッダに書かれている。
    - 下はvmlinuzをヘキサダンプした結果。0x258からがカーネルエントリポイントの0x1000000になってる。ブートローダーはここから値をとってきてる。
![カーネルヘッダエントリポイント.png](https://qiita-image-store.s3.amazonaws.com/0/91729/f0380d0f-ca03-1b66-910b-a8526543d643.png)

↓

### **startup_64()** 0x1000000
* Linuxのエントリポイント
* 仮のプロテクトモードの環境を整え直す
    - ページテーブルの再設定。カーネル用のマッピング？？
    - CPUの機能設定(cpuid)
    - GDTの再設定
    - スタックの設定(swapper用。後にinitプロセス用)


 ```bash:カーネルの仮想アドレスへのマップ

$ cat /boot/System.map-2.6.32-642.13.2.el6.x86_64 | more
0000000000000000 A VDSO32_PRELINK
0000000000000000 D __per_cpu_start
0000000000000000 D per_cpu__irq_stack_union
0000000000000000 A xen_irq_disable_direct_reloc
0000000000000000 A xen_save_fl_direct_reloc
0000000000000040 A VDSO32_vsyscall_eh_frame_size
00000000000001e7 A kexec_control_code_size
00000000000001f0 A VDSO32_NOTE_MASK
0000000000000400 A VDSO32_sigreturn
0000000000000410 A VDSO32_rt_sigreturn
0000000000000420 A VDSO32_vsyscall
0000000000000430 A VDSO32_SYSENTER_RETURN
0000000000004000 D per_cpu__gdt_page
0000000000005000 d per_cpu__exception_stacks
000000000000a000 d per_cpu__idt_desc
・
・
ffffffff81000000 T _text
ffffffff81000000 T startup_64
ffffffff810000b7 t ident_complete
ffffffff81000100 T secondary_startup_64
ffffffff8100018f t bad_address
ffffffff81000198 T _stext
ffffffff81001000 T hypercall_page
ffffffff81002010 T do_one_initcall
ffffffff81002290 t cpumask_weight
ffffffff810022b0 t run_init_process
ffffffff810022e0 t init_post
ffffffff810023e0 T name_to_dev_t
ffffffff81002640 t create_dev
ffffffff810026a0 t create_dev.clone.0
ffffffff810026d0 t create_dev
ffffffff81002730 t bstat
・
・
```

* **ffffffff80000000**以降の領域はLinuxカーネルのプログラムがロードされる**仮想アドレス**。Linuxカーネルのっプログラムファイルは仮想アドレス**ffffffff81000000**に配置されるようにリンクされる。ユーザプロセスはここにアクセスする。もちろん仮想アドレスなので実際は物理アドレスに変換される。
* ちなみにユーザープロセスは**0000000000000000**~**0000800000000000**にリンクされるようです。127TB。pmapコマンドではここの中で使用されている箇所を表示している。実際に0~800000000000の中の様子。vsyscallだけ、この中に収まっていなかった。なんでだろう？

```bash:pmap結果
$ cat /proc/4705/maps 
7f3a13e5a000-7f3a13e6f000 r-xp 00000000 fd:00 2381451                    /usr/lib64/php/modules/zip.so
7f3a13e6f000-7f3a1406f000 ---p 00015000 fd:00 2381451                    /usr/lib64/php/modules/zip.so
7f3a1406f000-7f3a14071000 rw-p 00015000 fd:00 2381451                    /usr/lib64/php/modules/zip.so
7f3a14071000-7f3a140b0000 r-xp 00000000 fd:00 2381450                    /usr/lib64/php/modules/phar.so
7f3a140b0000-7f3a142af000 ---p 0003f000 fd:00 2381450                    /usr/lib64/php/modules/phar.so
7f3a142af000-7f3a142b2000 rw-p 0003e000 fd:00 2381450                    /usr/lib64/php/modules/phar.so
7f3a142b2000-7f3a142bc000 r-xp 00000000 fd:00 2381449                    /usr/lib64/php/modules/json.so
7f3a142bc000-7f3a144bb000 ---p 0000a000 fd:00 2381449                    /usr/lib64/php/modules/json.so
7f3a144bb000-7f3a144bc000 rw-p 00009000 fd:00 2381449                    /usr/lib64/php/modules/json.so
・
・
7ffe61b3a000-7ffe61b4f000 rw-p 00000000 00:00 0                          [stack]
7ffe61b7b000-7ffe61b7c000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

```

↓

swapper用(後にinitプロセス用)のスタック設定

```asm:arch/x86/kernel/head_64.S
        /* Setup a boot time stack */
        movq stack_start(%rip),%rsp

        ENTRY(stack_start)
        .quad  init_thread_union+THREAD_SIZE-8
        .word  0
```
* init_thread_unionはinitプロセスのための領域
* その他：ENTRY()はマクロ。展開されて↓みたいな感じになる。外部からnameでアクセスできる。

```c
#define ENTRY(name)
.global name;
ALIGN;
name:
```
* スタックポインタを設定しているので、これが最初に使うカーネルスタックの実体。最初のプロセスのスタックは直で書かれている。initプロセスが動作するまでのカーネル環境構築。

↓

### x86_64_start_kernel()
ここからC言語。割り込みハンドラを仮設定

- x86_64_start_reservations()
- start_kernel()

```asm
252         movq    initial_code(%rip),%rax
253         pushq   $0              # fake return address to stop unwinder
254         pushq   $__KERNEL_CS    # set correct cs
255         pushq   %rax            # target address in negative space
256         lretq

261         ENTRY(initial_code)
262         .quad   x86_64_start_kernel
```
```c:arch/x86/kernel/head64.c
void __init x86_64_start_kernel(char * real_mode_data)
{
        int i;

        /*
         * Build-time sanity checks on the kernel image and module
         * area mappings. (these are purely build-time and produce no code)
         */
        BUILD_BUG_ON(MODULES_VADDR < KERNEL_IMAGE_START);
        BUILD_BUG_ON(MODULES_VADDR-KERNEL_IMAGE_START < KERNEL_IMAGE_SIZE);
        BUILD_BUG_ON(MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE);
        BUILD_BUG_ON((KERNEL_IMAGE_START & ~PMD_MASK) != 0);
        BUILD_BUG_ON((MODULES_VADDR & ~PMD_MASK) != 0);
        BUILD_BUG_ON(!(MODULES_VADDR > __START_KERNEL));
        BUILD_BUG_ON(!(((MODULES_END - 1) & PGDIR_MASK) ==
                                (__START_KERNEL & PGDIR_MASK)));
        BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= MODULES_END);

        /* clear bss before set_intr_gate with early_idt_handler */
        clear_bss();

        /* Make NULL pointers segfault */
        zap_identity_mappings();

        /* Cleanup the over mapped high alias */
        cleanup_highmap();

        for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
#ifdef CONFIG_EARLY_PRINTK
                set_intr_gate(i, &early_idt_handlers[i]);
#else
                set_intr_gate(i, early_idt_handler);
#endif
        }
        load_idt((const struct desc_ptr *)&idt_descr);

        if (console_loglevel == 10)
                early_printk("Kernel alive\n");

        x86_64_start_reservations(real_mode_data);
}

void __init x86_64_start_reservations(char *real_mode_data)
{
        copy_bootdata(__va(real_mode_data));

        reserve_trampoline_memory();

        reserve_early(__pa_symbol(&_text), __pa_symbol(&__bss_stop), "TEXT DATA BSS");

#ifdef CONFIG_BLK_DEV_INITRD
        /* Reserve INITRD */
        if (boot_params.hdr.type_of_loader && boot_params.hdr.ramdisk_image) {
                unsigned long ramdisk_image = boot_params.hdr.ramdisk_image;
                unsigned long ramdisk_size  = boot_params.hdr.ramdisk_size;
                unsigned long ramdisk_end   = ramdisk_image + ramdisk_size;
                reserve_early(ramdisk_image, ramdisk_end, "RAMDISK");
        }
#endif

        reserve_ebda_region();

        /*
         * At this point everything still needed from the boot loader
         * or BIOS or kernel text should be early reserved or marked not
         * RAM in e820. All other memory is free game.
         */

        start_kernel();
}
```

start_kernel()を呼び出して終わる。start_kernel()ではカーネルスレッドなどの生成をしている

# まとめ

リアルモードから32bitプロテクトモードへ
↓
カーネル(vmlinuz)をロード&解凍
↓
64bitモード移行
↓
startup_64()　**カーネルエントリポイント**
↓
x86_64_start_kernel()
↓
x86_64_start_reservations()
↓
start_kernel()


カーネル探検(start_kernel以前)

### 概要
BIOSがMBRを読み込んでブートローダが動き出し、カーネルをメモリにロードして/sbin/initが動き出すまでの処理をデバッグするための自分めもめも。そして最近？は/sbin/initからsystemdに置き換わりつつあるらしいので、systemdを導入しているcentOS7を使用してsystemdから各プロセスを起動させる処理もデバッグできたらいいなぁ(でもきっとむり)。カーネル処理をみていくことでそこから色々派生していろんな知識を学べたらいいなぁ。そしてこのデバッグ経験を活かしてDockerなどのコンテナ技術をカーネル(cgroups、systemd)のコードから理解できるようになれればいいなぁ(でもきっとむり)。

### スタート地点
どこからデバッグしてみようかなぁと考えた。とりあえずアセンブラ部分は~~やめておこう~~後に取っておこうというとでブートローダ(Cの箇所もあるけど)とばし、カーネル処理のアセンブラ箇所(メモリ設定など)をとばしー、なんて思ってたらデバッグのスタート地点は王道のstart_kernelからに決定。ということで今回は環境構築してGDB起動してstart_kernel先頭まで。

### カーネル探検(環境構築からstart_kernelまで)
#### 概要
仮想マシン上のCentOS7カーネルをGDBでリモートデバッグする。

#### 準備
* ホストOS
  - Cent7
* ゲストOS
  - Cent7
* QEMU(2.4.1)
  - qemu-system-xxxコマンドは自分でmake && make install
* カーネルver
  - 3.10.0-229.el7.x86_64
  - Linux Cross Referenceで示すコードは参考までにこのバージョンでないものも示す。
* vmlinux
  - カーネルのデバッグ情報(シンボル)が含まれているカーネル。カーネルコンフィグでチェックするか、kernel-debuginfo install kernel-xxxxでバージョン指定して任意のvmllinuxをインストールする。ブートローダーがメモリにロード(解凍したやつ)するvmlinuzはデバッグ情報が含まれていない。
* GDB(gdb-7.6.1-64.el7.x86_64)
  - QEMUを使用して64bit版のカーネルをデバッグする場合、CPUを32bitから64bitに移行する箇所でQEMUとGDBの間で不具合がるよう。GDBにパッチをあてる解決が簡単らいいのでパッチをあてる必要がる。[パッチのdiff](http://www.cygwin.com/ml/gdb-patches/2012-03/msg00116.html)。このdiffの内容がパッチの内容でpatchコマンドでパッチを適用する。
  - GDBの最新を自分でビルドして入れるならシステムにncurses-develがないとtuiモードが使えずlayoutコマンドが動作しない。

#### 環境構築
1. ホストOS上でデバッグしたいOSを含む仮想マシンを作成(qemu-img、qemu-kvm)

```
$ qemu-img create -f raw xxx.img 4G
```
```
$ qemu-kvm -k ja -m 1024 -localtime -hda xxx.img -net nic,model=e1000 -net user -cdrom xxx.iso -boot d
```

2. 仮想マシンの起動はqemu-system-xxxコマンドを使う。実行するとに色々オプションを指定。-SはGDBが接続するまでOSの起動？を待ってくれるオプション。

```
$ qemu-system-x86_64 -S -s -snapshot -k ja -m 1024 -localtime -hda xxx.img -net nic,model=e1000 -net user -monitor stdio
```
3. ホストOSからGDBを使ってQEMU上で動作するCentOS7のカーネルに対してリモートアクセスしてカーネル動作をデバッグ

```
$ gdb vmlinxへのパス
```

その他：もしゲストOS上と異るバージョンのカーネルをデバッグしたい場合は、カーネルがそのバージョンの仮想マシンを作るか、ホストOS上でカーネルコンパイルして既存の仮想マシンに任意のカーネルバージョンをインストールすればよいみたい(試してない)。

#### start_kernel表示
アプリケーションをデバッグする場合
  
- gdb 実行ファイル

カーネルをデバッグする場合

1. gdb  vmlinux
2. (gdb) target remote localhot:1234
3. (gdb) b start_kernel
4. (gdb) c 
5. (gdb) layout src
![スナップショット1.png](https://qiita-image-store.s3.amazonaws.com/0/91729/536f73e3-1f48-a640-6918-f92d3993a2e4.png)
わー、バックトレースやレジスタの中身が分るのねー！スタックの中身もみれるのかな？？素敵！

### next
[カーネル探検2](http://qiita.com/saikoro-steak/items/60f5ab6cb9d0f825df25)

#### 参考
1. [新装改訂版 Linuxのブートプロセスをみる](http://www.amazon.co.jp/%E6%96%B0%E8%A3%85%E6%94%B9%E8%A8%82%E7%89%88-Linux%E3%81%AE%E3%83%96%E3%83%BC%E3%83%88%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%82%92%E3%81%BF%E3%82%8B-%E7%99%BD%E5%B4%8E%E5%8D%9A%E7%94%9F/dp/404891393X/ref=tmm_jp_oversized_meta_binding_title_0)



<h3>
<span id="概要" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81"><i class="fa fa-link"></i></a>概要</h3>

<p>BIOSがMBRを読み込んでブートローダが動き出し、カーネルをメモリにロードして/sbin/initが動き出すまでの処理をデバッグするための自分めもめも。そして最近？は/sbin/initからsystemdに置き換わりつつあるらしいので、systemdを導入しているcentOS7を使用してsystemdから各プロセスを起動させる処理もデバッグできたらいいなぁ(でもきっとむり)。カーネル処理をみていくことでそこから色々派生していろんな知識を学べたらいいなぁ。そしてこのデバッグ経験を活かしてDockerなどのコンテナ技術をカーネル(cgroups、systemd)のコードから理解できるようになれればいいなぁ(でもきっとむり)。</p>

<h3>
<span id="スタート地点" class="fragment"></span><a href="#%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%88%E5%9C%B0%E7%82%B9"><i class="fa fa-link"></i></a>スタート地点</h3>

<p>どこからデバッグしてみようかなぁと考えた。とりあえずアセンブラ部分は<del>やめておこう</del>後に取っておこうというとでブートローダ(Cの箇所もあるけど)とばし、カーネル処理のアセンブラ箇所(メモリ設定など)をとばしー、なんて思ってたらデバッグのスタート地点は王道のstart_kernelからに決定。ということで今回は環境構築してGDB起動してstart_kernel先頭まで。</p>

<h3>
<span id="カーネル探検環境構築からstart_kernelまで" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E6%8E%A2%E6%A4%9C%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89%E3%81%8B%E3%82%89start_kernel%E3%81%BE%E3%81%A7"><i class="fa fa-link"></i></a>カーネル探検(環境構築からstart_kernelまで)</h3>

<h4>
<span id="概要-1" class="fragment"></span><a href="#%E6%A6%82%E8%A6%81-1"><i class="fa fa-link"></i></a>概要</h4>

<p>仮想マシン上のCentOS7カーネルをGDBでリモートデバッグする。</p>

<h4>
<span id="準備" class="fragment"></span><a href="#%E6%BA%96%E5%82%99"><i class="fa fa-link"></i></a>準備</h4>

<ul>
<li>ホストOS

<ul>
<li>Cent7</li>
</ul>
</li>
<li>ゲストOS

<ul>
<li>Cent7</li>
</ul>
</li>
<li>QEMU(2.4.1)

<ul>
<li>qemu-system-xxxコマンドは自分でmake &amp;&amp; make install</li>
</ul>
</li>
<li>カーネルver

<ul>
<li>3.10.0-229.el7.x86_64</li>
<li>Linux Cross Referenceで示すコードは参考までにこのバージョンでないものも示す。</li>
</ul>
</li>
<li>vmlinux

<ul>
<li>カーネルのデバッグ情報(シンボル)が含まれているカーネル。カーネルコンフィグでチェックするか、kernel-debuginfo install kernel-xxxxでバージョン指定して任意のvmllinuxをインストールする。ブートローダーがメモリにロード(解凍したやつ)するvmlinuzはデバッグ情報が含まれていない。</li>
</ul>
</li>
<li>GDB(gdb-7.6.1-64.el7.x86_64)

<ul>
<li>QEMUを使用して64bit版のカーネルをデバッグする場合、CPUを32bitから64bitに移行する箇所でQEMUとGDBの間で不具合がるよう。GDBにパッチをあてる解決が簡単らいいのでパッチをあてる必要がる。<a href="http://www.cygwin.com/ml/gdb-patches/2012-03/msg00116.html" rel="nofollow noopener" target="_blank">パッチのdiff</a>。このdiffの内容がパッチの内容でpatchコマンドでパッチを適用する。</li>
<li>GDBの最新を自分でビルドして入れるならシステムにncurses-develがないとtuiモードが使えずlayoutコマンドが動作しない。</li>
</ul>
</li>
</ul>

<h4>
<span id="環境構築" class="fragment"></span><a href="#%E7%92%B0%E5%A2%83%E6%A7%8B%E7%AF%89"><i class="fa fa-link"></i></a>環境構築</h4>

<ol>
<li>ホストOS上でデバッグしたいOSを含む仮想マシンを作成(qemu-img、qemu-kvm)</li>
</ol>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>$ qemu-img create -f raw xxx.img 4G
</code></pre></div></div>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>$ qemu-kvm -k ja -m 1024 -localtime -hda xxx.img -net nic,model=e1000 -net user -cdrom xxx.iso -boot d
</code></pre></div></div>

<ol>
<li>仮想マシンの起動はqemu-system-xxxコマンドを使う。実行するとに色々オプションを指定。-SはGDBが接続するまでOSの起動？を待ってくれるオプション。</li>
</ol>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>$ qemu-system-x86_64 -S -s -snapshot -k ja -m 1024 -localtime -hda xxx.img -net nic,model=e1000 -net user -monitor stdio
</code></pre></div></div>

<ol>
<li>ホストOSからGDBを使ってQEMU上で動作するCentOS7のカーネルに対してリモートアクセスしてカーネル動作をデバッグ</li>
</ol>

<div class="code-frame" data-lang="text"><div class="highlight"><pre><code>$ gdb vmlinxへのパス
</code></pre></div></div>

<p>その他：もしゲストOS上と異るバージョンのカーネルをデバッグしたい場合は、カーネルがそのバージョンの仮想マシンを作るか、ホストOS上でカーネルコンパイルして既存の仮想マシンに任意のカーネルバージョンをインストールすればよいみたい(試してない)。</p>

<h4>
<span id="start_kernel表示" class="fragment"></span><a href="#start_kernel%E8%A1%A8%E7%A4%BA"><i class="fa fa-link"></i></a>start_kernel表示</h4>

<p>アプリケーションをデバッグする場合</p>

<ul>
<li>gdb 実行ファイル</li>
</ul>

<p>カーネルをデバッグする場合</p>

<ol>
<li>gdb  vmlinux</li>
<li>(gdb) target remote localhot:1234</li>
<li>(gdb) b start_kernel</li>
<li>(gdb) c </li>
<li>(gdb) layout src
<a href="https://camo.qiitausercontent.com/61ce4a021ed5a841947601b8c01e8b2a7109d8b5/68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f39313732392f35333666373365332d316634382d613634302d363931382d6639326433393933613265342e706e67" target="_blank" rel="nofollow noopener"><img src="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F91729%2F536f73e3-1f48-a640-6918-f92d3993a2e4.png?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;s=e74ce9c2a1cbb4a261fff7658243972b" alt="スナップショット1.png" data-canonical-src="https://qiita-image-store.s3.amazonaws.com/0/91729/536f73e3-1f48-a640-6918-f92d3993a2e4.png" srcset="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F91729%2F536f73e3-1f48-a640-6918-f92d3993a2e4.png?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;w=1400&amp;fit=max&amp;s=b2cf626c698b9fe7513ee2357ab48f4e 1x" loading="lazy"></a>
わー、バックトレースやレジスタの中身が分るのねー！スタックの中身もみれるのかな？？素敵！</li>
</ol>

<h3>
<span id="next" class="fragment"></span><a href="#next"><i class="fa fa-link"></i></a>next</h3>

<p><a href="http://qiita.com/saikoro-steak/items/60f5ab6cb9d0f825df25" id="reference-da56be5c077c126c0ab6">カーネル探検2</a></p>

<h4>
<span id="参考" class="fragment"></span><a href="#%E5%8F%82%E8%80%83"><i class="fa fa-link"></i></a>参考</h4>

<ol>
<li><a href="http://www.amazon.co.jp/%E6%96%B0%E8%A3%85%E6%94%B9%E8%A8%82%E7%89%88-Linux%E3%81%AE%E3%83%96%E3%83%BC%E3%83%88%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%82%92%E3%81%BF%E3%82%8B-%E7%99%BD%E5%B4%8E%E5%8D%9A%E7%94%9F/dp/404891393X/ref=tmm_jp_oversized_meta_binding_title_0" rel="nofollow noopener" target="_blank">新装改訂版 Linuxのブートプロセスをみる</a></li>
</ol>


カーネル探検(環境構築からstart_kernelまで)

#### カーネル構築簡単メモメモ
いろいろカーネルのソースコードを色々試していたら知識の整理したくなったので自分用にめもしてみる。

##### カーネルソースコードのありか
カーネルソースコードの種類は２種類あって

* kernel.org版(xzとかで圧縮されてる)

* kernel.orgにパッチをあてたディストリビューション版(ソースパッケージとして提供されてる。拡張子はredhat系とかだとsrc.rpmとか)

##### どっち使うのか
* 最新版使いたいーとかだとkernel.org
  - ディストリビューション上でカーネルを最新版にする場合、現在のディストリビューションのカーネル設定ファイル(/boot/.confing-カーネルバージョン)をcpすればよし。そしてmake oldconfig(設定変えない場合)or make menuconfigすればよし。
* ディストリビューションのカーネルをデバッグしてみたーい時に現在のディストリビューションと同じカーネルソースが欲しい場合とかだと各ディストリビューションのソースパッケージを使う。
  - rpmbuildコマンド
     + バッチが適用されたソースコード＆適用していないバニラカーネルソースコードも作ってくれる。!
     + ビルドすればrpmパッケージつくってくれる。
     + そのrpmに対してrpm -ivh で作成したカーネルをインストールできるみたい(試したことなし)
     + ソースコードのルートディレクトリで普通にmake && make && module_install && make installしてもインストールされるみたい。(やってみた)



<h4>
<span id="カーネル構築簡単メモメモ" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E6%A7%8B%E7%AF%89%E7%B0%A1%E5%8D%98%E3%83%A1%E3%83%A2%E3%83%A1%E3%83%A2"><i class="fa fa-link"></i></a>カーネル構築簡単メモメモ</h4>

<p>いろいろカーネルのソースコードを色々試していたら知識の整理したくなったので自分用にめもしてみる。</p>

<h5>
<span id="カーネルソースコードのありか" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AE%E3%81%82%E3%82%8A%E3%81%8B"><i class="fa fa-link"></i></a>カーネルソースコードのありか</h5>

<p>カーネルソースコードの種類は２種類あって</p>

<ul>
<li><p>kernel.org版(xzとかで圧縮されてる)</p></li>
<li><p>kernel.orgにパッチをあてたディストリビューション版(ソースパッケージとして提供されてる。拡張子はredhat系とかだとsrc.rpmとか)</p></li>
</ul>

<h5>
<span id="どっち使うのか" class="fragment"></span><a href="#%E3%81%A9%E3%81%A3%E3%81%A1%E4%BD%BF%E3%81%86%E3%81%AE%E3%81%8B"><i class="fa fa-link"></i></a>どっち使うのか</h5>

<ul>
<li>最新版使いたいーとかだとkernel.org

<ul>
<li>ディストリビューション上でカーネルを最新版にする場合、現在のディストリビューションのカーネル設定ファイル(/boot/.confing-カーネルバージョン)をcpすればよし。そしてmake oldconfig(設定変えない場合)or make menuconfigすればよし。</li>
</ul>
</li>
<li>ディストリビューションのカーネルをデバッグしてみたーい時に現在のディストリビューションと同じカーネルソースが欲しい場合とかだと各ディストリビューションのソースパッケージを使う。

<ul>
<li>rpmbuildコマンド

<ul>
<li>バッチが適用されたソースコード＆適用していないバニラカーネルソースコードも作ってくれる。!</li>
<li>ビルドすればrpmパッケージつくってくれる。</li>
<li>そのrpmに対してrpm -ivh で作成したカーネルをインストールできるみたい(試したことなし)</li>
<li>ソースコードのルートディレクトリで普通にmake &amp;&amp; make &amp;&amp; module_install &amp;&amp; make installしてもインストールされるみたい。(やってみた)</li>
</ul>
</li>
</ul>
</li>
</ul>


カーネル再構築簡単メモメモ


### KVMとQEMU
プロセスメモリの仮想化、Java仮想マシン、RubyマシンYARV、ネットワークの仮想化などなど、とかくこの世の中仮想しまくっっている。ということでこの前ハードウェア(CPUと各デバイス)をまるごと仮想化する仕組みKVMとQEMUをCentOS7上で操作してみたので自分なりに用語などまとめてみた。

#### KVM
##### KVMってなに？
* カーネル・モジュール。カーネルの機能。ロードするだけで仮想化機能使える。
* 実体はこの`/dev/kvm`デバイスファイル？。これを各プロセスがオープンすることで各プロセスが独自のメモリそして`ソフトウェア的なCPU`をもつこと。なのでKVMはこの一連の仕組の枠組みといえるはず。

##### タイプ 
* ハイパーバイザ(完全仮想化)というタイプに分類。完全とはBIOSも含めたハードウェアを全部を仮想化すること。
* 同用語として仮想マシンモニタ

#### CPU
* KVMを使用するにはCPUが仮想化に対応してないとだめ。対応しているかどうかは簡単にコマンドで調べられる。
* ゲストOSの命令はセンシティブ命令。CPUの仮想化機能はこれを感知するようになっている。
* 仮想化に対応しているCPUはカーネルモード、ユーザーモードの他にゲストモードがある。
  - ゲストモード
     + 仮想マシン上のOSが動作している間はCPUはこのモードっぽい
     + VMX non-root
         - 仮想マシン上のOSがユーザーモードの時
     + VMX root 
         - 仮想マシン上のOSがカーネルモードの時。この時CPUは仮想マシン上のOSの命令を感知して`KVMに制御を渡す`。KVMモジュールからソフトウェア的に作成したCPUが実行されるみたいなイメージをもっている。

#### /dev/kvm
~~~txt
$ qemu-img create -f qcow vm-disk.img 4G
~~~
↑例えばこんな感じで実行すると、内部で/dev/kvmが使用されるよう。他にもvirt-managerやvirt-installなどすると/dev/kvmをオープンしてるはずたぶん。要するに仮想マシンを起動？、生成する際に/dev/kvmをオープンしているみたい。あとはオープンで取得したfd(オープンしたプロセスと結びついているファイル構造体など)をもとにkvm_create関数(仮想CPU(その情報を表わせ構造体のこと)を作成)したり、load_file関数によって、指定されたVMのアドレス空間に仮想マシンイメージがロードされるみたい。
詳しくは(こういう詳しい本欲しい)
https://www.ibm.com/developerworks/jp/linux/library/l-linux-kvm/

* 下をみれば起動のイメージが湧く！！
./linux-2.6.20/drivers/kvm/kvm_main.c

~~~C
int main()
{
        void *vm_mem;

        kvm = kvm_init(&test_callbacks, 0);
        if (!kvm) {
            fprintf(stderr, "kvm_init failed\n");
            return 1;
        }
        if (kvm_create(kvm, 128 * 1024 * 1024, &vm_mem) < 0) {
            kvm_finalize(kvm);
            fprintf(stderr, "kvm_create failed\n");
            return 1;
        }
        if (ac > 1)
            if (strcmp(av[1], "-32") != 0)
                load_file(vm_mem + 0xf0000, av[1]);
            else
                enter_32(kvm);
        if (ac > 2)
            load_file(vm_mem + 0x100000, av[2]);
        kvm_show_regs(kvm, 0);

        kvm_run(kvm, 0);

        return 0;
}
~~~

#### QEMU
KVMは上で述べた様に複数のオペレーティング・システム用にソフトウェア的にメモリ、CPUを仮想化するもの。これに対してQEMUはゲストOSからの入出力I/O(ディスク、ネットワークetc)を仮想化するもの。KVMはこのQEMUの力を借りている。QEMUにもCPUを仮想化する機能があるが、KVMはこの機能を使用せずにCPUの仮想機能を使用して仮想化を実現している。KVMはCPUを仮想化、QEMUはI/Oを仮想化といった具合に分担してマシンを仮想化している。

#### DOCKER
今度はDOCKER！！！！



<h3>
<span id="kvmとqemu" class="fragment"></span><a href="#kvm%E3%81%A8qemu"><i class="fa fa-link"></i></a>KVMとQEMU</h3>

<p>プロセスメモリの仮想化、Java仮想マシン、RubyマシンYARV、ネットワークの仮想化などなど、とかくこの世の中仮想しまくっっている。ということでこの前ハードウェア(CPUと各デバイス)をまるごと仮想化する仕組みKVMとQEMUをCentOS7上で操作してみたので自分なりに用語などまとめてみた。</p>

<h4>
<span id="kvm" class="fragment"></span><a href="#kvm"><i class="fa fa-link"></i></a>KVM</h4>

<h5>
<span id="kvmってなに" class="fragment"></span><a href="#kvm%E3%81%A3%E3%81%A6%E3%81%AA%E3%81%AB"><i class="fa fa-link"></i></a>KVMってなに？</h5>

<ul>
<li>カーネル・モジュール。カーネルの機能。ロードするだけで仮想化機能使える。</li>
<li>実体はこの<code>/dev/kvm</code>デバイスファイル？。これを各プロセスがオープンすることで各プロセスが独自のメモリそして<code>ソフトウェア的なCPU</code>をもつこと。なのでKVMはこの一連の仕組の枠組みといえるはず。</li>
</ul>

<h5>
<span id="タイプ" class="fragment"></span><a href="#%E3%82%BF%E3%82%A4%E3%83%97"><i class="fa fa-link"></i></a>タイプ</h5>

<ul>
<li>ハイパーバイザ(完全仮想化)というタイプに分類。完全とはBIOSも含めたハードウェアを全部を仮想化すること。</li>
<li>同用語として仮想マシンモニタ</li>
</ul>

<h4>
<span id="cpu" class="fragment"></span><a href="#cpu"><i class="fa fa-link"></i></a>CPU</h4>

<ul>
<li>KVMを使用するにはCPUが仮想化に対応してないとだめ。対応しているかどうかは簡単にコマンドで調べられる。</li>
<li>ゲストOSの命令はセンシティブ命令。CPUの仮想化機能はこれを感知するようになっている。</li>
<li>仮想化に対応しているCPUはカーネルモード、ユーザーモードの他にゲストモードがある。

<ul>
<li>ゲストモード

<ul>
<li>仮想マシン上のOSが動作している間はCPUはこのモードっぽい</li>
<li>VMX non-root

<ul>
<li>仮想マシン上のOSがユーザーモードの時</li>
</ul>
</li>
<li>VMX root 

<ul>
<li>仮想マシン上のOSがカーネルモードの時。この時CPUは仮想マシン上のOSの命令を感知して<code>KVMに制御を渡す</code>。KVMモジュールからソフトウェア的に作成したCPUが実行されるみたいなイメージをもっている。</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>

<h4>
<span id="devkvm" class="fragment"></span><a href="#devkvm"><i class="fa fa-link"></i></a>/dev/kvm</h4>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>$ qemu-img create -f qcow vm-disk.img 4G
</code></pre></div></div>

<p>↑例えばこんな感じで実行すると、内部で/dev/kvmが使用されるよう。他にもvirt-managerやvirt-installなどすると/dev/kvmをオープンしてるはずたぶん。要するに仮想マシンを起動？、生成する際に/dev/kvmをオープンしているみたい。あとはオープンで取得したfd(オープンしたプロセスと結びついているファイル構造体など)をもとにkvm_create関数(仮想CPU(その情報を表わせ構造体のこと)を作成)したり、load_file関数によって、指定されたVMのアドレス空間に仮想マシンイメージがロードされるみたい。<br>
詳しくは(こういう詳しい本欲しい)<br>
<a href="https://www.ibm.com/developerworks/jp/linux/library/l-linux-kvm/" class="autolink" rel="nofollow noopener" target="_blank">https://www.ibm.com/developerworks/jp/linux/library/l-linux-kvm/</a></p>

<ul>
<li>下をみれば起動のイメージが湧く！！
./linux-2.6.20/drivers/kvm/kvm_main.c</li>
</ul>

<div class="code-frame" data-lang="C"><div class="highlight"><pre><code><span class="kt">int</span> <span class="nf">main</span><span class="p">()</span>
<span class="p">{</span>
        <span class="kt">void</span> <span class="o">*</span><span class="n">vm_mem</span><span class="p">;</span>

        <span class="n">kvm</span> <span class="o">=</span> <span class="n">kvm_init</span><span class="p">(</span><span class="o">&amp;</span><span class="n">test_callbacks</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
        <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">kvm</span><span class="p">)</span> <span class="p">{</span>
            <span class="n">fprintf</span><span class="p">(</span><span class="n">stderr</span><span class="p">,</span> <span class="s">"kvm_init failed</span><span class="se">\n</span><span class="s">"</span><span class="p">);</span>
            <span class="k">return</span> <span class="mi">1</span><span class="p">;</span>
        <span class="p">}</span>
        <span class="k">if</span> <span class="p">(</span><span class="n">kvm_create</span><span class="p">(</span><span class="n">kvm</span><span class="p">,</span> <span class="mi">128</span> <span class="o">*</span> <span class="mi">1024</span> <span class="o">*</span> <span class="mi">1024</span><span class="p">,</span> <span class="o">&amp;</span><span class="n">vm_mem</span><span class="p">)</span> <span class="o">&lt;</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
            <span class="n">kvm_finalize</span><span class="p">(</span><span class="n">kvm</span><span class="p">);</span>
            <span class="n">fprintf</span><span class="p">(</span><span class="n">stderr</span><span class="p">,</span> <span class="s">"kvm_create failed</span><span class="se">\n</span><span class="s">"</span><span class="p">);</span>
            <span class="k">return</span> <span class="mi">1</span><span class="p">;</span>
        <span class="p">}</span>
        <span class="k">if</span> <span class="p">(</span><span class="n">ac</span> <span class="o">&gt;</span> <span class="mi">1</span><span class="p">)</span>
            <span class="k">if</span> <span class="p">(</span><span class="n">strcmp</span><span class="p">(</span><span class="n">av</span><span class="p">[</span><span class="mi">1</span><span class="p">],</span> <span class="s">"-32"</span><span class="p">)</span> <span class="o">!=</span> <span class="mi">0</span><span class="p">)</span>
                <span class="n">load_file</span><span class="p">(</span><span class="n">vm_mem</span> <span class="o">+</span> <span class="mh">0xf0000</span><span class="p">,</span> <span class="n">av</span><span class="p">[</span><span class="mi">1</span><span class="p">]);</span>
            <span class="k">else</span>
                <span class="n">enter_32</span><span class="p">(</span><span class="n">kvm</span><span class="p">);</span>
        <span class="k">if</span> <span class="p">(</span><span class="n">ac</span> <span class="o">&gt;</span> <span class="mi">2</span><span class="p">)</span>
            <span class="n">load_file</span><span class="p">(</span><span class="n">vm_mem</span> <span class="o">+</span> <span class="mh">0x100000</span><span class="p">,</span> <span class="n">av</span><span class="p">[</span><span class="mi">2</span><span class="p">]);</span>
        <span class="n">kvm_show_regs</span><span class="p">(</span><span class="n">kvm</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>

        <span class="n">kvm_run</span><span class="p">(</span><span class="n">kvm</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>

        <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div></div>

<h4>
<span id="qemu" class="fragment"></span><a href="#qemu"><i class="fa fa-link"></i></a>QEMU</h4>

<p>KVMは上で述べた様に複数のオペレーティング・システム用にソフトウェア的にメモリ、CPUを仮想化するもの。これに対してQEMUはゲストOSからの入出力I/O(ディスク、ネットワークetc)を仮想化するもの。KVMはこのQEMUの力を借りている。QEMUにもCPUを仮想化する機能があるが、KVMはこの機能を使用せずにCPUの仮想機能を使用して仮想化を実現している。KVMはCPUを仮想化、QEMUはI/Oを仮想化といった具合に分担してマシンを仮想化している。</p>

<h4>
<span id="docker" class="fragment"></span><a href="#docker"><i class="fa fa-link"></i></a>DOCKER</h4>

<p>今度はDOCKER！！！！</p>


KVMの仕組み

## カーネル再構築 2.6→4.3
centos6.7のカーネルバージョンを2.6から4.3にアップしてみた。

### カーネルプログラムの分類
大きく２つに分けられる

* カーネル本体
* カーネルモジュール

#### 上の２つはどこに置いてあるの？？
##### カーネル本体
* /boot 
  - vmlinuz-2.6.32-573.el6.x86_64
  - ↑圧縮されてる

~~~txt
$ ls -ls
total 34310
  106 -rw-r--r--. 1 root root   107134 Jul 23 09:13 config-2.6.32-573.el6.x86_64
    2 drwxr-xr-x. 3 root root     1024 Nov 20 18:48 efi
    2 drwxr-xr-x. 2 root root     1024 Nov 20 19:50 grub
27335 -rw-------. 1 root root 27989384 Nov 20 18:55 initramfs-2.6.32-573.el6.x86_64.img
   13 drwx------. 2 root root    12288 Nov 20 18:38 lost+found
  203 -rw-r--r--. 1 root root   205998 Jul 23 09:14 symvers-2.6.32-573.el6.x86_64.gz
 2526 -rw-r--r--. 1 root root  2585052 Jul 23 09:13 System.map-2.6.32-573.el6.x86_64
 4123 -rwxr-xr-x. 1 root root  4220560 Jul 23 09:13 vmlinuz-2.6.32-573.el6.x86_64
~~~

#### カーネルモジュール
* /lib/modules/カーネルバージョン/kernel

~~~txt 
 $ pwd
/lib/modules/2.6.32-573.el6.x86_64/kernel
$ ls -ls
total 36
4 drwxr-xr-x.  3 root root 4096 Nov 20 18:45 arch
4 drwxr-xr-x.  3 root root 4096 Nov 20 18:45 crypto
4 drwxr-xr-x. 63 root root 4096 Nov 20 18:45 drivers
4 drwxr-xr-x. 30 root root 4096 Nov 20 18:45 fs
4 drwxr-xr-x.  3 root root 4096 Nov 20 18:45 kernel
4 drwxr-xr-x.  6 root root 4096 Nov 20 18:45 lib
4 drwxr-xr-x.  2 root root 4096 Nov 20 18:45 mm
4 drwxr-xr-x. 28 root root 4096 Nov 20 18:45 net
4 drwxr-xr-x.  9 root root 4096 Nov 20 18:45 sound
~~~

### 4.3にあげてみた
#### やった場所
~

#### カーネル設定の引き継ぎ
現在のカーネル設定を反映させる。その上で新しい設定を反映させる。そうしないと今までのやつが動かなくなる？？

~~~txt
cp config-2.6.32-573.el6.x86_64　.config
~~~

#### 最新の設定だけを反映
oldconfigを使用すると最新の設定だけをyse/noで聞かれる。
最新の設定はenter押してデフォルト設定にする。

~~~txt
make oldconfig
~~~

#### ビルド
~~~txt
make 
~~~

#### 怒られる
openssl.hがないみたいなメッセージ発生して途中で終わる。
openssl-develがないみたいだ。

#### そもそもxxx-develってなに？？
* develはdevelopmentの略
* 開発の際(ビルド)の時に必要になるもの。ヘッダファイルとかはいっている。
* CentOSなどではコンパイルに必要なファイルをまとめたパッケージには後ろに-develという名前が付くようになっている。ライブラリそのものはヘッダファイルがなくても動作するため、パッケージが分割された状態になっていることがほとんどらしい。


```sh
$ rpm -qi  openssl-devel

Description :
OpenSSL is a toolkit for supporting cryptography. The openssl-devel
package contains include files needed to develop applications which
support various cryptographic algorithms and protocols.
```
↑説明通り。

```bash
$ rpm -ql  openssl-devel
/usr/include/openssl
/usr/include/openssl/aes.h
/usr/include/openssl/asn1.h
/usr/include/openssl/asn1_mac.h
/usr/include/openssl/asn1t.h
/usr/include/openssl/bio.h
/usr/include/openssl/blowfish.h
/usr/include/openssl/bn.h
/usr/include/openssl/buffer.h
/usr/include/openssl/camellia.h
/usr/include/openssl/cast.h
/usr/include/openssl/cmac.h
/usr/include/openssl/cms.h
/usr/include/openssl/comp.h
/usr/include/openssl/conf.h
/usr/include/openssl/conf_api.h
/usr/include/openssl/crypto.h
/usr/include/openssl/des.h
/usr/include/openssl/des_old.h
/usr/include/openssl/dh.h
/usr/include/openssl/dsa.h
/usr/include/openssl/dso.h
・
・
```
↑やはりヘッダファイルあり。

## なんでヘッダファイルがないとビルドできないのか？
今回のビルドエラーはヘッダファイルをinclude指定しているがそのヘッダがないのでエラー。

## ヘッダファイルを利用しない
* あるファイルの関数から別ファイルの関数を呼び出す場合、その呼び出す関数の引数、戻り値を知っていないといけない。それを知るために、呼び出し側ではその関数の宣言を利用する。
* 利用側で宣言を知ることができない場合、暗黙の宣言が利用される。
* 宣言が定義と合致しているかはちぇっくなし。
* 別ファイルの関数などを使う場合に都度、自分で宣言を書かないといけない

## 暗黙の宣言
* 呼び出し側で例えば関数の情報(宣言)を知ることができない場合int型を返す、引数なしの関数としてみなされる。
* 自分で宣言を書いて定義と異なっていたとしても同じ
* コンパイラの気持ちとしては別ファイルにあるはずなので`リンク時`にみつかるやろ～

## エラー
* 発覚するのはリンク時。`コンパイル時`にエラー見つけたい。

## ヘッダファイルを利用
* 宣言を一つにまとめられる。再利用できる。
* ヘッダファイルに、関数、変数の宣言かく。`コンパイル時`に例えば関数の呼び出し側、定義側、とヘッダファイルにかかれている宣言が正しい(引数、戻り値の型)などをチェックしてくれる。`コンパイル時`にみつかる。

 

#### 色々試してみた

##### 別ファイルに関数ある場合
main

~~~C
#include <stdio.h>

int main()
{
  printf("answer=%f\n", add(3.0, 4.0) );
  return 0;
}
~~~

↓別ファイル

~~~c
double add(double a, double b)
{
  return a+b;
}
~~~
mainでadd()の宣言していないのでコンパイラは勝手にint addで暗黙宣言して思い込む。よって-Wallつきでコンパイルすると

~~~txt
gcc test.c test2.c -c -Wall
test.c: In function ‘main’:
test.c:5: warning: implicit declaration of function ‘add’
~~~

その様な警告でる。ただ-Wallをつけているから警告でるだけなのでコンパイルは通るし、リンクもされる。実行もされる。

##### 同じファイルに関数ある場合

~~~c
#include <stdio.h>

int main()
{
  printf("answer=%f\n", add(3.0, 4.0) );
  return 0;
}

double add(double a, double b)
{
  return a+b;
}
~~~

- 同じファイルにあると警告でなくエラーがでてコンパイルに失敗する↓

~~~txt
gcc test3.c 
test3.c:9: error: conflicting types for ‘add’
test3.c:5: note: previous implicit declaration of ‘add’ was here
~~~

- 同じファイルにあるとコンパイラが使用するのは下のaddと確定させるから??
- 別ファイルにある関数を使用する場合、暗黙の宣言した関数の情報と実際の使用する関数の情報が異なっていてもエラーにならずに(-Wallをつけるとduplicateの警告でるが)リンクまで正常にできた

#### 結果
- この結果からヘッダ(宣言)なくてもリンクまで行ける。自分が使い方させ間違えなければOK。ただし、間違えた場合、リンク時エラー、最悪、実行時にエラーすると思われる。
- だからきっと-Wallをつけて警告は全て排除する必要あり(コンパイラが宣言をチェックしてくれて頑張ってるから)。そのためにも宣言必要。ヘッダファイルで使用する関数を宣言して定義と使用箇所をコンパイル時にチェック。再利用可能。
- ヘッダファイル(宣言)はコンパイラにコンパイル時点で間違いを気づかせてもらうためにあるはず。


## カーネル再構築の続き

* モジュールをシステムにインストール

~~~txt
make modules_install
~~~

* カーネル本体をインストール？

~~~txt
make install 
~~~

* インストール完了
  - grubには自動で新カーネルが追加で設定される。再起動後↓

~~~txt
uname -r
4.3.0
~~~

### 感想
再構築は本を見てやりかたしっていたけど、やっぱり実際に手を動かしてみると色々試行錯誤が生まれて勉強になる。実際に試してみることが大切だと実感させられました。



<h2>
<span id="カーネル再構築-2643" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E5%86%8D%E6%A7%8B%E7%AF%89-2643"><i class="fa fa-link"></i></a>カーネル再構築 2.6→4.3</h2>

<p>centos6.7のカーネルバージョンを2.6から4.3にアップしてみた。</p>

<h3>
<span id="カーネルプログラムの分類" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%81%AE%E5%88%86%E9%A1%9E"><i class="fa fa-link"></i></a>カーネルプログラムの分類</h3>

<p>大きく２つに分けられる</p>

<ul>
<li>カーネル本体</li>
<li>カーネルモジュール</li>
</ul>

<h4>
<span id="上の２つはどこに置いてあるの" class="fragment"></span><a href="#%E4%B8%8A%E3%81%AE%EF%BC%92%E3%81%A4%E3%81%AF%E3%81%A9%E3%81%93%E3%81%AB%E7%BD%AE%E3%81%84%E3%81%A6%E3%81%82%E3%82%8B%E3%81%AE"><i class="fa fa-link"></i></a>上の２つはどこに置いてあるの？？</h4>

<h5>
<span id="カーネル本体" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E6%9C%AC%E4%BD%93"><i class="fa fa-link"></i></a>カーネル本体</h5>

<ul>
<li>/boot 

<ul>
<li>vmlinuz-2.6.32-573.el6.x86_64</li>
<li>↑圧縮されてる</li>
</ul>
</li>
</ul>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>$ ls -ls
total 34310
  106 -rw-r--r--. 1 root root   107134 Jul 23 09:13 config-2.6.32-573.el6.x86_64
    2 drwxr-xr-x. 3 root root     1024 Nov 20 18:48 efi
    2 drwxr-xr-x. 2 root root     1024 Nov 20 19:50 grub
27335 -rw-------. 1 root root 27989384 Nov 20 18:55 initramfs-2.6.32-573.el6.x86_64.img
   13 drwx------. 2 root root    12288 Nov 20 18:38 lost+found
  203 -rw-r--r--. 1 root root   205998 Jul 23 09:14 symvers-2.6.32-573.el6.x86_64.gz
 2526 -rw-r--r--. 1 root root  2585052 Jul 23 09:13 System.map-2.6.32-573.el6.x86_64
 4123 -rwxr-xr-x. 1 root root  4220560 Jul 23 09:13 vmlinuz-2.6.32-573.el6.x86_64
</code></pre></div></div>

<h4>
<span id="カーネルモジュール" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB"><i class="fa fa-link"></i></a>カーネルモジュール</h4>

<ul>
<li>/lib/modules/カーネルバージョン/kernel</li>
</ul>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code> $ pwd
/lib/modules/2.6.32-573.el6.x86_64/kernel
$ ls -ls
total 36
4 drwxr-xr-x.  3 root root 4096 Nov 20 18:45 arch
4 drwxr-xr-x.  3 root root 4096 Nov 20 18:45 crypto
4 drwxr-xr-x. 63 root root 4096 Nov 20 18:45 drivers
4 drwxr-xr-x. 30 root root 4096 Nov 20 18:45 fs
4 drwxr-xr-x.  3 root root 4096 Nov 20 18:45 kernel
4 drwxr-xr-x.  6 root root 4096 Nov 20 18:45 lib
4 drwxr-xr-x.  2 root root 4096 Nov 20 18:45 mm
4 drwxr-xr-x. 28 root root 4096 Nov 20 18:45 net
4 drwxr-xr-x.  9 root root 4096 Nov 20 18:45 sound
</code></pre></div></div>

<h3>
<span id="43にあげてみた" class="fragment"></span><a href="#43%E3%81%AB%E3%81%82%E3%81%92%E3%81%A6%E3%81%BF%E3%81%9F"><i class="fa fa-link"></i></a>4.3にあげてみた</h3>

<h4>
<span id="やった場所" class="fragment"></span><a href="#%E3%82%84%E3%81%A3%E3%81%9F%E5%A0%B4%E6%89%80"><i class="fa fa-link"></i></a>やった場所</h4>

<p>~</p>

<h4>
<span id="カーネル設定の引き継ぎ" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E8%A8%AD%E5%AE%9A%E3%81%AE%E5%BC%95%E3%81%8D%E7%B6%99%E3%81%8E"><i class="fa fa-link"></i></a>カーネル設定の引き継ぎ</h4>

<p>現在のカーネル設定を反映させる。その上で新しい設定を反映させる。そうしないと今までのやつが動かなくなる？？</p>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>cp config-2.6.32-573.el6.x86_64　.config
</code></pre></div></div>

<h4>
<span id="最新の設定だけを反映" class="fragment"></span><a href="#%E6%9C%80%E6%96%B0%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A0%E3%81%91%E3%82%92%E5%8F%8D%E6%98%A0"><i class="fa fa-link"></i></a>最新の設定だけを反映</h4>

<p>oldconfigを使用すると最新の設定だけをyse/noで聞かれる。<br>
最新の設定はenter押してデフォルト設定にする。</p>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>make oldconfig
</code></pre></div></div>

<h4>
<span id="ビルド" class="fragment"></span><a href="#%E3%83%93%E3%83%AB%E3%83%89"><i class="fa fa-link"></i></a>ビルド</h4>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>make 
</code></pre></div></div>

<h4>
<span id="怒られる" class="fragment"></span><a href="#%E6%80%92%E3%82%89%E3%82%8C%E3%82%8B"><i class="fa fa-link"></i></a>怒られる</h4>

<p>openssl.hがないみたいなメッセージ発生して途中で終わる。<br>
openssl-develがないみたいだ。</p>

<h4>
<span id="そもそもxxx-develってなに" class="fragment"></span><a href="#%E3%81%9D%E3%82%82%E3%81%9D%E3%82%82xxx-devel%E3%81%A3%E3%81%A6%E3%81%AA%E3%81%AB"><i class="fa fa-link"></i></a>そもそもxxx-develってなに？？</h4>

<ul>
<li>develはdevelopmentの略</li>
<li>開発の際(ビルド)の時に必要になるもの。ヘッダファイルとかはいっている。</li>
<li>CentOSなどではコンパイルに必要なファイルをまとめたパッケージには後ろに-develという名前が付くようになっている。ライブラリそのものはヘッダファイルがなくても動作するため、パッケージが分割された状態になっていることがほとんどらしい。</li>
</ul>

<div class="code-frame" data-lang="sh"><div class="highlight"><pre><code><span class="nv">$ </span>rpm <span class="nt">-qi</span>  openssl-devel

Description :
OpenSSL is a toolkit <span class="k">for </span>supporting cryptography. The openssl-devel
package contains include files needed to develop applications which
support various cryptographic algorithms and protocols.
</code></pre></div></div>

<p>↑説明通り。</p>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code><span class="nv">$ </span>rpm <span class="nt">-ql</span>  openssl-devel
/usr/include/openssl
/usr/include/openssl/aes.h
/usr/include/openssl/asn1.h
/usr/include/openssl/asn1_mac.h
/usr/include/openssl/asn1t.h
/usr/include/openssl/bio.h
/usr/include/openssl/blowfish.h
/usr/include/openssl/bn.h
/usr/include/openssl/buffer.h
/usr/include/openssl/camellia.h
/usr/include/openssl/cast.h
/usr/include/openssl/cmac.h
/usr/include/openssl/cms.h
/usr/include/openssl/comp.h
/usr/include/openssl/conf.h
/usr/include/openssl/conf_api.h
/usr/include/openssl/crypto.h
/usr/include/openssl/des.h
/usr/include/openssl/des_old.h
/usr/include/openssl/dh.h
/usr/include/openssl/dsa.h
/usr/include/openssl/dso.h
・
・
</code></pre></div></div>

<p>↑やはりヘッダファイルあり。</p>

<h2>
<span id="なんでヘッダファイルがないとビルドできないのか" class="fragment"></span><a href="#%E3%81%AA%E3%82%93%E3%81%A7%E3%83%98%E3%83%83%E3%83%80%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8C%E3%81%AA%E3%81%84%E3%81%A8%E3%83%93%E3%83%AB%E3%83%89%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84%E3%81%AE%E3%81%8B"><i class="fa fa-link"></i></a>なんでヘッダファイルがないとビルドできないのか？</h2>

<p>今回のビルドエラーはヘッダファイルをinclude指定しているがそのヘッダがないのでエラー。</p>

<h2>
<span id="ヘッダファイルを利用しない" class="fragment"></span><a href="#%E3%83%98%E3%83%83%E3%83%80%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%AA%E3%81%84"><i class="fa fa-link"></i></a>ヘッダファイルを利用しない</h2>

<ul>
<li>あるファイルの関数から別ファイルの関数を呼び出す場合、その呼び出す関数の引数、戻り値を知っていないといけない。それを知るために、呼び出し側ではその関数の宣言を利用する。</li>
<li>利用側で宣言を知ることができない場合、暗黙の宣言が利用される。</li>
<li>宣言が定義と合致しているかはちぇっくなし。</li>
<li>別ファイルの関数などを使う場合に都度、自分で宣言を書かないといけない</li>
</ul>

<h2>
<span id="暗黙の宣言" class="fragment"></span><a href="#%E6%9A%97%E9%BB%99%E3%81%AE%E5%AE%A3%E8%A8%80"><i class="fa fa-link"></i></a>暗黙の宣言</h2>

<ul>
<li>呼び出し側で例えば関数の情報(宣言)を知ることができない場合int型を返す、引数なしの関数としてみなされる。</li>
<li>自分で宣言を書いて定義と異なっていたとしても同じ</li>
<li>コンパイラの気持ちとしては別ファイルにあるはずなので<code>リンク時</code>にみつかるやろ～</li>
</ul>

<h2>
<span id="エラー" class="fragment"></span><a href="#%E3%82%A8%E3%83%A9%E3%83%BC"><i class="fa fa-link"></i></a>エラー</h2>

<ul>
<li>発覚するのはリンク時。<code>コンパイル時</code>にエラー見つけたい。</li>
</ul>

<h2>
<span id="ヘッダファイルを利用" class="fragment"></span><a href="#%E3%83%98%E3%83%83%E3%83%80%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E5%88%A9%E7%94%A8"><i class="fa fa-link"></i></a>ヘッダファイルを利用</h2>

<ul>
<li>宣言を一つにまとめられる。再利用できる。</li>
<li>ヘッダファイルに、関数、変数の宣言かく。<code>コンパイル時</code>に例えば関数の呼び出し側、定義側、とヘッダファイルにかかれている宣言が正しい(引数、戻り値の型)などをチェックしてくれる。<code>コンパイル時</code>にみつかる。</li>
</ul>

<h4>
<span id="色々試してみた" class="fragment"></span><a href="#%E8%89%B2%E3%80%85%E8%A9%A6%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F"><i class="fa fa-link"></i></a>色々試してみた</h4>

<h5>
<span id="別ファイルに関数ある場合" class="fragment"></span><a href="#%E5%88%A5%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AB%E9%96%A2%E6%95%B0%E3%81%82%E3%82%8B%E5%A0%B4%E5%90%88"><i class="fa fa-link"></i></a>別ファイルに関数ある場合</h5>

<p>main</p>

<div class="code-frame" data-lang="C"><div class="highlight"><pre><code><span class="cp">#include &lt;stdio.h&gt;
</span>
<span class="kt">int</span> <span class="nf">main</span><span class="p">()</span>
<span class="p">{</span>
  <span class="n">printf</span><span class="p">(</span><span class="s">"answer=%f</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">add</span><span class="p">(</span><span class="mi">3</span><span class="p">.</span><span class="mi">0</span><span class="p">,</span> <span class="mi">4</span><span class="p">.</span><span class="mi">0</span><span class="p">)</span> <span class="p">);</span>
  <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div></div>

<p>↓別ファイル</p>

<div class="code-frame" data-lang="c"><div class="highlight"><pre><code><span class="kt">double</span> <span class="nf">add</span><span class="p">(</span><span class="kt">double</span> <span class="n">a</span><span class="p">,</span> <span class="kt">double</span> <span class="n">b</span><span class="p">)</span>
<span class="p">{</span>
  <span class="k">return</span> <span class="n">a</span><span class="o">+</span><span class="n">b</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div></div>

<p>mainでadd()の宣言していないのでコンパイラは勝手にint addで暗黙宣言して思い込む。よって-Wallつきでコンパイルすると</p>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>gcc test.c test2.c -c -Wall
test.c: In function ‘main’:
test.c:5: warning: implicit declaration of function ‘add’
</code></pre></div></div>

<p>その様な警告でる。ただ-Wallをつけているから警告でるだけなのでコンパイルは通るし、リンクもされる。実行もされる。</p>

<h5>
<span id="同じファイルに関数ある場合" class="fragment"></span><a href="#%E5%90%8C%E3%81%98%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AB%E9%96%A2%E6%95%B0%E3%81%82%E3%82%8B%E5%A0%B4%E5%90%88"><i class="fa fa-link"></i></a>同じファイルに関数ある場合</h5>

<div class="code-frame" data-lang="c"><div class="highlight"><pre><code><span class="cp">#include &lt;stdio.h&gt;
</span>
<span class="kt">int</span> <span class="nf">main</span><span class="p">()</span>
<span class="p">{</span>
  <span class="n">printf</span><span class="p">(</span><span class="s">"answer=%f</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">add</span><span class="p">(</span><span class="mi">3</span><span class="p">.</span><span class="mi">0</span><span class="p">,</span> <span class="mi">4</span><span class="p">.</span><span class="mi">0</span><span class="p">)</span> <span class="p">);</span>
  <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
<span class="p">}</span>

<span class="kt">double</span> <span class="nf">add</span><span class="p">(</span><span class="kt">double</span> <span class="n">a</span><span class="p">,</span> <span class="kt">double</span> <span class="n">b</span><span class="p">)</span>
<span class="p">{</span>
  <span class="k">return</span> <span class="n">a</span><span class="o">+</span><span class="n">b</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div></div>

<ul>
<li>同じファイルにあると警告でなくエラーがでてコンパイルに失敗する↓</li>
</ul>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>gcc test3.c 
test3.c:9: error: conflicting types for ‘add’
test3.c:5: note: previous implicit declaration of ‘add’ was here
</code></pre></div></div>

<ul>
<li>同じファイルにあるとコンパイラが使用するのは下のaddと確定させるから??</li>
<li>別ファイルにある関数を使用する場合、暗黙の宣言した関数の情報と実際の使用する関数の情報が異なっていてもエラーにならずに(-Wallをつけるとduplicateの警告でるが)リンクまで正常にできた</li>
</ul>

<h4>
<span id="結果" class="fragment"></span><a href="#%E7%B5%90%E6%9E%9C"><i class="fa fa-link"></i></a>結果</h4>

<ul>
<li>この結果からヘッダ(宣言)なくてもリンクまで行ける。自分が使い方させ間違えなければOK。ただし、間違えた場合、リンク時エラー、最悪、実行時にエラーすると思われる。</li>
<li>だからきっと-Wallをつけて警告は全て排除する必要あり(コンパイラが宣言をチェックしてくれて頑張ってるから)。そのためにも宣言必要。ヘッダファイルで使用する関数を宣言して定義と使用箇所をコンパイル時にチェック。再利用可能。</li>
<li>ヘッダファイル(宣言)はコンパイラにコンパイル時点で間違いを気づかせてもらうためにあるはず。</li>
</ul>

<h2>
<span id="カーネル再構築の続き" class="fragment"></span><a href="#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E5%86%8D%E6%A7%8B%E7%AF%89%E3%81%AE%E7%B6%9A%E3%81%8D"><i class="fa fa-link"></i></a>カーネル再構築の続き</h2>

<ul>
<li>モジュールをシステムにインストール</li>
</ul>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>make modules_install
</code></pre></div></div>

<ul>
<li>カーネル本体をインストール？</li>
</ul>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>make install 
</code></pre></div></div>

<ul>
<li>インストール完了

<ul>
<li>grubには自動で新カーネルが追加で設定される。再起動後↓</li>
</ul>
</li>
</ul>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>uname -r
4.3.0
</code></pre></div></div>

<h3>
<span id="感想" class="fragment"></span><a href="#%E6%84%9F%E6%83%B3"><i class="fa fa-link"></i></a>感想</h3>

<p>再構築は本を見てやりかたしっていたけど、やっぱり実際に手を動かしてみると色々試行錯誤が生まれて勉強になる。実際に試してみることが大切だと実感させられました。</p>


カーネル再構築 2.6→4.3

# はじめに
動的リンクについて簡単にまとめてみました

# 動的リンクとは
https://e-words.jp/w/%E5%8B%95%E7%9A%84%E3%83%AA%E3%83%B3%E3%82%AF.html

* 動的リンクとは、プログラムの実行に必要なライブラリやモジュールなどを、実行時にリンク（連結）して起動すること。
* 例えばprintfなどを使ったC言語のプログラムを実行するときは、LinuxのGlibc(標準Cライブラリ)などの共有ライブラリが実行時に動的にリンクされる

# 実行ファイルの中身を見てみた

~~~bash
readelf -a a.out 
ELF ヘッダ:
  マジック:  7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  クラス:                            ELF32
  データ:                            2 の補数、リトルエンディアン
(中略)
セクションヘッダ:
  [番] 名前              タイプ          アドレス Off    サイズ ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        08048154 000154 000013 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            08048168 000168 000020 00   A  0   0  4
  [ 3] .note.gnu.build-i NOTE            08048188 000188 000024 00   A  0   0  4
  [ 4] .gnu.hash         GNU_HASH        080481ac 0001ac 000020 04   A  5   0  4
  [ 5] .dynsym           DYNSYM          080481cc 0001cc 000040 10   A  6   1  4
(中略)
プログラムヘッダ:
  タイプ       オフセット 仮想Addr   物理Addr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4
  INTERP         0x000154 0x08048154 0x08048154 0x00013 0x00013 R   0x1
      [要求されるプログラムインタプリタ: /lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x00590 0x00590 R E 0x1000
  LOAD           0x000f08 0x08049f08 0x08049f08 0x00110 0x00114 RW  0x1000
  DYNAMIC        0x000f14 0x08049f14 0x08049f14 0x000e8 0x000e8 RW  0x4
オフセット 0xf14 にある動的セクションは 24 個のエントリから構成されています:
 タグ        タイプ                       名前/値
 0x00000001 (NEEDED)                     共有ライブラリ: [libc.so.6]
 0x0000000c (INIT)                       0x8048294
 0x0000000d (FINI)                       0x8048494
 0x00000019 (INIT_ARRAY)                 0x8049f08
 0x0000001b (INIT_ARRAYSZ)               4 (バイト)
(中略)
再配置セクション '.rel.plt' (オフセット 0x284) は 2 個のエントリから構成されています:
 オフセット 情報    型              シンボル値 シンボル名
0804a00c  00000107 R_386_JUMP_SLOT   00000000   __gmon_start__
0804a010  00000207 R_386_JUMP_SLOT   00000000   __libc_start_main
~~~

## interpセクション
* 動的リンカが指定されている(/lib/ld-linux.so.2)。**通称ld.so**。リンク時に共有ライブラリなどがある場合、リンカによって書き込まれる。

## 動的リンクの流れ
* execveされてカーネルがメモリに実行ファイルをロード。カーネルがINTREPセクションを発見するとそのパスに書かれている動的リンカをメモリにロードする。上だと(/lib/ld-linux.so.2)。
* そしてカーネルは処理をこの動的リンカに受け渡して動的リンカが起動
* 動的リンカはカーネルから渡された情報(実行ファイルなど)を元に実行ファイルのDYNAMICセクションを探してDYNAMICセクションのTYPEがNEEDEDの共有ライブラリ(上記のlibc.so.6)をメモリに読み込む。
* 共有ライブラリを検索する場所は環境変数、デフォルト検索パスなど(コマンドラインでコンパイルした時に-Lを指定したパス)
* そして共有ライブラリのDYNAMICセクションにも共有ライブラリがリンクされていたら再帰的にメモリにロードしてすべての共有ライブラリをメモリに配置する

## 実行ファイルと共有ライブラリ
* 対象：実行ファイル(ELF)
  - **カーネル(ローダー)**がメモリに配置する。
* 対象：実行ファイルで使用される共有ライブラリ
  - **動的リンカ(ダイナミックリンカローダ)**がメモリに配置する




<h1>
<span id="はじめに" class="fragment"></span><a href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB"><i class="fa fa-link"></i></a>はじめに</h1>

<p>動的リンクについて簡単にまとめてみました</p>

<h1>
<span id="動的リンクとは" class="fragment"></span><a href="#%E5%8B%95%E7%9A%84%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%A8%E3%81%AF"><i class="fa fa-link"></i></a>動的リンクとは</h1>

<p><qiita-embed-ogp src="https://e-words.jp/w/%E5%8B%95%E7%9A%84%E3%83%AA%E3%83%B3%E3%82%AF.html"></qiita-embed-ogp></p>

<ul>
<li>動的リンクとは、プログラムの実行に必要なライブラリやモジュールなどを、実行時にリンク（連結）して起動すること。</li>
<li>例えばprintfなどを使ったC言語のプログラムを実行するときは、LinuxのGlibc(標準Cライブラリ)などの共有ライブラリが実行時に動的にリンクされる</li>
</ul>

<h1>
<span id="実行ファイルの中身を見てみた" class="fragment"></span><a href="#%E5%AE%9F%E8%A1%8C%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E4%B8%AD%E8%BA%AB%E3%82%92%E8%A6%8B%E3%81%A6%E3%81%BF%E3%81%9F"><i class="fa fa-link"></i></a>実行ファイルの中身を見てみた</h1>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>readelf <span class="nt">-a</span> a.out 
ELF ヘッダ:
  マジック:  7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  クラス:                            ELF32
  データ:                            2 の補数、リトルエンディアン
<span class="o">(</span>中略<span class="o">)</span>
セクションヘッダ:
  <span class="o">[</span>番] 名前              タイプ          アドレス Off    サイズ ES Flg Lk Inf Al
  <span class="o">[</span> 0]                   NULL            00000000 000000 000000 00      0   0  0
  <span class="o">[</span> 1] .interp           PROGBITS        08048154 000154 000013 00   A  0   0  1
  <span class="o">[</span> 2] .note.ABI-tag     NOTE            08048168 000168 000020 00   A  0   0  4
  <span class="o">[</span> 3] .note.gnu.build-i NOTE            08048188 000188 000024 00   A  0   0  4
  <span class="o">[</span> 4] .gnu.hash         GNU_HASH        080481ac 0001ac 000020 04   A  5   0  4
  <span class="o">[</span> 5] .dynsym           DYNSYM          080481cc 0001cc 000040 10   A  6   1  4
<span class="o">(</span>中略<span class="o">)</span>
プログラムヘッダ:
  タイプ       オフセット 仮想Addr   物理Addr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4
  INTERP         0x000154 0x08048154 0x08048154 0x00013 0x00013 R   0x1
      <span class="o">[</span>要求されるプログラムインタプリタ: /lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x00590 0x00590 R E 0x1000
  LOAD           0x000f08 0x08049f08 0x08049f08 0x00110 0x00114 RW  0x1000
  DYNAMIC        0x000f14 0x08049f14 0x08049f14 0x000e8 0x000e8 RW  0x4
オフセット 0xf14 にある動的セクションは 24 個のエントリから構成されています:
 タグ        タイプ                       名前/値
 0x00000001 <span class="o">(</span>NEEDED<span class="o">)</span>                     共有ライブラリ: <span class="o">[</span>libc.so.6]
 0x0000000c <span class="o">(</span>INIT<span class="o">)</span>                       0x8048294
 0x0000000d <span class="o">(</span>FINI<span class="o">)</span>                       0x8048494
 0x00000019 <span class="o">(</span>INIT_ARRAY<span class="o">)</span>                 0x8049f08
 0x0000001b <span class="o">(</span>INIT_ARRAYSZ<span class="o">)</span>               4 <span class="o">(</span>バイト<span class="o">)</span>
<span class="o">(</span>中略<span class="o">)</span>
再配置セクション <span class="s1">'.rel.plt'</span> <span class="o">(</span>オフセット 0x284<span class="o">)</span> は 2 個のエントリから構成されています:
 オフセット 情報    型              シンボル値 シンボル名
0804a00c  00000107 R_386_JUMP_SLOT   00000000   __gmon_start__
0804a010  00000207 R_386_JUMP_SLOT   00000000   __libc_start_main
</code></pre></div></div>

<h2>
<span id="interpセクション" class="fragment"></span><a href="#interp%E3%82%BB%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3"><i class="fa fa-link"></i></a>interpセクション</h2>

<ul>
<li>動的リンカが指定されている(/lib/ld-linux.so.2)。<strong>通称ld.so</strong>。リンク時に共有ライブラリなどがある場合、リンカによって書き込まれる。</li>
</ul>

<h2>
<span id="動的リンクの流れ" class="fragment"></span><a href="#%E5%8B%95%E7%9A%84%E3%83%AA%E3%83%B3%E3%82%AF%E3%81%AE%E6%B5%81%E3%82%8C"><i class="fa fa-link"></i></a>動的リンクの流れ</h2>

<ul>
<li>execveされてカーネルがメモリに実行ファイルをロード。カーネルがINTREPセクションを発見するとそのパスに書かれている動的リンカをメモリにロードする。上だと(/lib/ld-linux.so.2)。</li>
<li>そしてカーネルは処理をこの動的リンカに受け渡して動的リンカが起動</li>
<li>動的リンカはカーネルから渡された情報(実行ファイルなど)を元に実行ファイルのDYNAMICセクションを探してDYNAMICセクションのTYPEがNEEDEDの共有ライブラリ(上記のlibc.so.6)をメモリに読み込む。</li>
<li>共有ライブラリを検索する場所は環境変数、デフォルト検索パスなど(コマンドラインでコンパイルした時に-Lを指定したパス)</li>
<li>そして共有ライブラリのDYNAMICセクションにも共有ライブラリがリンクされていたら再帰的にメモリにロードしてすべての共有ライブラリをメモリに配置する</li>
</ul>

<h2>
<span id="実行ファイルと共有ライブラリ" class="fragment"></span><a href="#%E5%AE%9F%E8%A1%8C%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%A8%E5%85%B1%E6%9C%89%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA"><i class="fa fa-link"></i></a>実行ファイルと共有ライブラリ</h2>

<ul>
<li>対象：実行ファイル(ELF)

<ul>
<li>
<strong>カーネル(ローダー)</strong>がメモリに配置する。</li>
</ul>
</li>
<li>対象：実行ファイルで使用される共有ライブラリ

<ul>
<li>
<strong>動的リンカ(ダイナミックリンカローダ)</strong>がメモリに配置する</li>
</ul>
</li>
</ul>


動的リンク (dynamic link)とは

# はじめに
共有ライブラリについて簡単にまとめてみました

# 共有ライブラリとは
https://e-words.jp/w/%E5%85%B1%E6%9C%89%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA.html

* 共有ライブラリとは、部品化されたプログラムの集合であるライブラリの一種で、複数のプログラムから共有・共用されるもの。
* C言語でmain関数の中を空にしてもスタートアッププログラムがリンクされる。
* UNIX系のOSでは「.so.(バージョン番号)」という拡張子のファイルとして、また、Windowsの場合は「. DLL」という拡張子のファイルとして提供される。

# 実行形式の共有ライブラリの確認

```bash
ldd a.out 
	linux-gate.so.1 =>  (0xb776e000)
	libc.so.6 => /lib/libc.so.6 (0x49cbd000)
	/lib/ld-linux.so.2 (0x49c95000)
```
* .soフアイルが共有ファイル


# 共有ファイルの仕組み
## 仮想メモリ
* 共有ライブラリは物理メモリに1つ存在していて、複数のプログラムから共有される
* 各プロセスは各々で仮想メモリ空間に共有ライブラリがロードされる。その時の共有ライブラリは各プロセスでメモリ番地が異なる

## 動的リンク
* 共有ライブラリはプログラム実行時に動的にリンクされる。それまでは共有ライブラリの関数などの番地は空欄？

## 共有ライブラリのシンボル解決
共有ライブラリは各プロセスで共有されて、各プロセスの仮想メモリにはそれぞれ別のメモリ番地に割り当てられる。さらに共有ライブラリは実行時にリンクされるので実行時までメモリ番地が決定されない。よってプログラムの実行時には共有ライブラリの参照箇所はシンボル解決が行われていな。なので、実行時には決定されていない共有ライブラリのメモリ番地を調べてシンボル解決する仕組みが必要になる。それがGOTとPLT。

## 位置独立コード
https://ja.wikipedia.org/wiki/%E4%BD%8D%E7%BD%AE%E7%8B%AC%E7%AB%8B%E3%82%B3%E3%83%BC%E3%83%89

* GOT、PLTの仕組みから成る主記憶装置内のどこに置かれても絶対アドレスに関わらず正しく実行できる仕組みのこと。共有ライブラリがその仕組を利用している。
* 各プログラムが（例えば他の共有ライブラリに）使われていない任意の別々のアドレスに同じ共有ライブラリをロードして使うことができるようになる。

## GOT、PLTその前に
* 共有ライブラリは実体は物理メモリに一つあるのみで、各プロセスから共有されている。各プロセスでは各々で仮想空間上の異なるメモリ番地に共有ライブラリをマッピングしている。よって、各プロセスでロードしているメモリ番地が異なるので、共有ライブラリの関数などを使用する際のメモリ番地を決定することはできない。そこでGOTとPLTを用いてメモリ番地を決定している。
* GOTとPLTは各プロセスが各々で保持している

## GOTとPLTの流れ
* 実行ファイルから共有ライブラリの関数を実行。例えばpfintfを使用する場合、アセンブラで見るとprintf@pltとなっている
* まず、pltセグメントに処理が飛ぶ。初回はシンボル解決して解決した関数の番地をGOTに埋め込む
* 2回目のアクセスもpltセグメントに飛ぶ。2回目はGOTに飛ぶ処理になり、目的の関数がGOTにすでに埋め込まれているので目的の関数が実行される

## GOT
* 直接共有ライブラリへ参照はせず、GOT領域を使用する。GOTはデータ領域に配置されるので各プロセスが独自に持てる領域。なので各プロセスはここで各々プロセスによって異なる共有ライブラリへの参照を保持する。
* 初期値はその共有ライブラリへのシンボル解決するメモリ番地への値が入っていてシンボル解決するとこの各共有ライブラリの関数などに対応するGOT領域にアクセスすれば共有ライブラリに参照ができる。

## PLT
* PLTは対象の共有ライブラリへ参照するためにGOTに飛ぶ。PLT→GOT→共有ライブラリ



<h1>
<span id="はじめに" class="fragment"></span><a href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB"><i class="fa fa-link"></i></a>はじめに</h1>

<p>共有ライブラリについて簡単にまとめてみました</p>

<h1>
<span id="共有ライブラリとは" class="fragment"></span><a href="#%E5%85%B1%E6%9C%89%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%81%A8%E3%81%AF"><i class="fa fa-link"></i></a>共有ライブラリとは</h1>

<p><qiita-embed-ogp src="https://e-words.jp/w/%E5%85%B1%E6%9C%89%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA.html"></qiita-embed-ogp></p>

<ul>
<li>共有ライブラリとは、部品化されたプログラムの集合であるライブラリの一種で、複数のプログラムから共有・共用されるもの。</li>
<li>C言語でmain関数の中を空にしてもスタートアッププログラムがリンクされる。</li>
<li>UNIX系のOSでは「.so.(バージョン番号)」という拡張子のファイルとして、また、Windowsの場合は「. DLL」という拡張子のファイルとして提供される。</li>
</ul>

<h1>
<span id="実行形式の共有ライブラリの確認" class="fragment"></span><a href="#%E5%AE%9F%E8%A1%8C%E5%BD%A2%E5%BC%8F%E3%81%AE%E5%85%B1%E6%9C%89%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%81%AE%E7%A2%BA%E8%AA%8D"><i class="fa fa-link"></i></a>実行形式の共有ライブラリの確認</h1>

<div class="code-frame" data-lang="bash"><div class="highlight"><pre><code>ldd a.out 
    linux-gate.so.1 <span class="o">=&gt;</span>  <span class="o">(</span>0xb776e000<span class="o">)</span>
    libc.so.6 <span class="o">=&gt;</span> /lib/libc.so.6 <span class="o">(</span>0x49cbd000<span class="o">)</span>
    /lib/ld-linux.so.2 <span class="o">(</span>0x49c95000<span class="o">)</span>
</code></pre></div></div>

<ul>
<li>.soフアイルが共有ファイル</li>
</ul>

<h1>
<span id="共有ファイルの仕組み" class="fragment"></span><a href="#%E5%85%B1%E6%9C%89%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF"><i class="fa fa-link"></i></a>共有ファイルの仕組み</h1>

<h2>
<span id="仮想メモリ" class="fragment"></span><a href="#%E4%BB%AE%E6%83%B3%E3%83%A1%E3%83%A2%E3%83%AA"><i class="fa fa-link"></i></a>仮想メモリ</h2>

<ul>
<li>共有ライブラリは物理メモリに1つ存在していて、複数のプログラムから共有される</li>
<li>各プロセスは各々で仮想メモリ空間に共有ライブラリがロードされる。その時の共有ライブラリは各プロセスでメモリ番地が異なる</li>
</ul>

<h2>
<span id="動的リンク" class="fragment"></span><a href="#%E5%8B%95%E7%9A%84%E3%83%AA%E3%83%B3%E3%82%AF"><i class="fa fa-link"></i></a>動的リンク</h2>

<ul>
<li>共有ライブラリはプログラム実行時に動的にリンクされる。それまでは共有ライブラリの関数などの番地は空欄？</li>
</ul>

<h2>
<span id="共有ライブラリのシンボル解決" class="fragment"></span><a href="#%E5%85%B1%E6%9C%89%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%81%AE%E3%82%B7%E3%83%B3%E3%83%9C%E3%83%AB%E8%A7%A3%E6%B1%BA"><i class="fa fa-link"></i></a>共有ライブラリのシンボル解決</h2>

<p>共有ライブラリは各プロセスで共有されて、各プロセスの仮想メモリにはそれぞれ別のメモリ番地に割り当てられる。さらに共有ライブラリは実行時にリンクされるので実行時までメモリ番地が決定されない。よってプログラムの実行時には共有ライブラリの参照箇所はシンボル解決が行われていな。なので、実行時には決定されていない共有ライブラリのメモリ番地を調べてシンボル解決する仕組みが必要になる。それがGOTとPLT。</p>

<h2>
<span id="位置独立コード" class="fragment"></span><a href="#%E4%BD%8D%E7%BD%AE%E7%8B%AC%E7%AB%8B%E3%82%B3%E3%83%BC%E3%83%89"><i class="fa fa-link"></i></a>位置独立コード</h2>

<p><qiita-embed-ogp src="https://ja.wikipedia.org/wiki/%E4%BD%8D%E7%BD%AE%E7%8B%AC%E7%AB%8B%E3%82%B3%E3%83%BC%E3%83%89"></qiita-embed-ogp></p>

<ul>
<li>GOT、PLTの仕組みから成る主記憶装置内のどこに置かれても絶対アドレスに関わらず正しく実行できる仕組みのこと。共有ライブラリがその仕組を利用している。</li>
<li>各プログラムが（例えば他の共有ライブラリに）使われていない任意の別々のアドレスに同じ共有ライブラリをロードして使うことができるようになる。</li>
</ul>

<h2>
<span id="gotpltその前に" class="fragment"></span><a href="#gotplt%E3%81%9D%E3%81%AE%E5%89%8D%E3%81%AB"><i class="fa fa-link"></i></a>GOT、PLTその前に</h2>

<ul>
<li>共有ライブラリは実体は物理メモリに一つあるのみで、各プロセスから共有されている。各プロセスでは各々で仮想空間上の異なるメモリ番地に共有ライブラリをマッピングしている。よって、各プロセスでロードしているメモリ番地が異なるので、共有ライブラリの関数などを使用する際のメモリ番地を決定することはできない。そこでGOTとPLTを用いてメモリ番地を決定している。</li>
<li>GOTとPLTは各プロセスが各々で保持している</li>
</ul>

<h2>
<span id="gotとpltの流れ" class="fragment"></span><a href="#got%E3%81%A8plt%E3%81%AE%E6%B5%81%E3%82%8C"><i class="fa fa-link"></i></a>GOTとPLTの流れ</h2>

<ul>
<li>実行ファイルから共有ライブラリの関数を実行。例えばpfintfを使用する場合、アセンブラで見るとprintf@pltとなっている</li>
<li>まず、pltセグメントに処理が飛ぶ。初回はシンボル解決して解決した関数の番地をGOTに埋め込む</li>
<li>2回目のアクセスもpltセグメントに飛ぶ。2回目はGOTに飛ぶ処理になり、目的の関数がGOTにすでに埋め込まれているので目的の関数が実行される</li>
</ul>

<h2>
<span id="got" class="fragment"></span><a href="#got"><i class="fa fa-link"></i></a>GOT</h2>

<ul>
<li>直接共有ライブラリへ参照はせず、GOT領域を使用する。GOTはデータ領域に配置されるので各プロセスが独自に持てる領域。なので各プロセスはここで各々プロセスによって異なる共有ライブラリへの参照を保持する。</li>
<li>初期値はその共有ライブラリへのシンボル解決するメモリ番地への値が入っていてシンボル解決するとこの各共有ライブラリの関数などに対応するGOT領域にアクセスすれば共有ライブラリに参照ができる。</li>
</ul>

<h2>
<span id="plt" class="fragment"></span><a href="#plt"><i class="fa fa-link"></i></a>PLT</h2>

<ul>
<li>PLTは対象の共有ライブラリへ参照するためにGOTに飛ぶ。PLT→GOT→共有ライブラリ</li>
</ul>


共有ライブラリの仕組み

### socket
擬似ファイル・システムのためにディスクなどに実態はない。よってopenできないのでsocket()でソケット(パケットを入れる箱)とプロセスを結びつける。

### 割り込み
* ハードウェア割り込み
* ソフトウェア割り込み

### 例外もあるよ！
* トラップなどなど

### TSS
* trレジスタにTSSの場所がかかれている
* ユーザモードプロセスのカーネルモードスタックの番地が書かれている。プロセス生成時にTSSにかく？モードが変更された時に他にもレジスタを保存できる
* SS,EIP,CS,EFLAGS,ESP,SSは特権の変更にいくつか保存されるされないがあったような
* SAVE_ALLでその他レジスタはスタックに保存される
* カーネルモードの時の割り込みはその時使用しているカーネルスタックをネストして使用される。だからいっぱいネストしまくったらオーバーフローおこしちゃう？？



<h3>
<span id="socket" class="fragment"></span><a href="#socket"><i class="fa fa-link"></i></a>socket</h3>

<p>擬似ファイル・システムのためにディスクなどに実態はない。よってopenできないのでsocket()でソケット(パケットを入れる箱)とプロセスを結びつける。</p>

<h3>
<span id="割り込み" class="fragment"></span><a href="#%E5%89%B2%E3%82%8A%E8%BE%BC%E3%81%BF"><i class="fa fa-link"></i></a>割り込み</h3>

<ul>
<li>ハードウェア割り込み</li>
<li>ソフトウェア割り込み</li>
</ul>

<h3>
<span id="例外もあるよ" class="fragment"></span><a href="#%E4%BE%8B%E5%A4%96%E3%82%82%E3%81%82%E3%82%8B%E3%82%88"><i class="fa fa-link"></i></a>例外もあるよ！</h3>

<ul>
<li>トラップなどなど</li>
</ul>

<h3>
<span id="tss" class="fragment"></span><a href="#tss"><i class="fa fa-link"></i></a>TSS</h3>

<ul>
<li>trレジスタにTSSの場所がかかれている</li>
<li>ユーザモードプロセスのカーネルモードスタックの番地が書かれている。プロセス生成時にTSSにかく？モードが変更された時に他にもレジスタを保存できる</li>
<li>SS,EIP,CS,EFLAGS,ESP,SSは特権の変更にいくつか保存されるされないがあったような</li>
<li>SAVE_ALLでその他レジスタはスタックに保存される</li>
<li>カーネルモードの時の割り込みはその時使用しているカーネルスタックをネストして使用される。だからいっぱいネストしまくったらオーバーフローおこしちゃう？？</li>
</ul>


ソケットと割り込みとTSS

### ユーザースタック
mainの前はスタートアッププログラム

#### スタートアッププログラムのユーザースタック領域
どんなもので構成されているのか
---------------------------[スタートアップスタックフレーム]
環境変数文字列
コマンドライン引数
・
・
envp[0]~envp[n]
それぞれ環境変数文字列さしている
argv[o]~argv[n]
コマンドライン引数をさしている
argc
戻りアドレス？
---------------------------[mainスタックフレーム]
元のebp
calee-saveレジスタ
ローカル変数
・
・
・

んー間違っていそう。今度実際に値をみてみようと思います。



<h3>
<span id="ユーザースタック" class="fragment"></span><a href="#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF"><i class="fa fa-link"></i></a>ユーザースタック</h3>

<p>mainの前はスタートアッププログラム</p>

<h4>
<span id="スタートアッププログラムのユーザースタック領域" class="fragment"></span><a href="#%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%81%AE%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E9%A0%98%E5%9F%9F"><i class="fa fa-link"></i></a>スタートアッププログラムのユーザースタック領域</h4>

<p>どんなもので構成されているのか<br>
---------------------------[スタートアップスタックフレーム]<br>
環境変数文字列<br>
コマンドライン引数<br>
・<br>
・<br>
envp[0]~envp[n]<br>
それぞれ環境変数文字列さしている<br>
argv[o]~argv[n]<br>
コマンドライン引数をさしている<br>
argc<br>
戻りアドレス？<br>
---------------------------[mainスタックフレーム]<br>
元のebp<br>
calee-saveレジスタ<br>
ローカル変数<br>
・<br>
・<br>
・</p>

<p>んー間違っていそう。今度実際に値をみてみようと思います。</p>


ユーザースタック

## 用語
### オブジェクトファイル
~.oだけでなく実行形式もオブジェクトファイルと呼ぶこともある。

### 狭義のコンパイル
プリプロセス後、～.sファイルが作成されるまで。

### 広義のコンパイル
~.oをリンクして実行形式が作成されるまで。

### オブジェクトファイル(~.o)
各セクション情報を持っている、セクションヘッダをもつ。まだ、セクションはまとめられていないのでセグメントはもたない。よってプログラムヘッダももたない。

### オブジェクトファイル(実行形式)
~.oのセクションをまとめたもの、セグメントをもっている。各セグメントの情報を保持している、プログラムヘッダをもっている。

### セクション
.text .data .bssとか

### セクションヘッダ
各セクションの情報をもつ。リンクはセクション単位で行われる。

### プログラムヘッダ
各セグメントの情報をもつ。ローダはセグメント単位でロードする。

### シンボルテーブル
関数、変数の名前とアドレスの対応表。ここにアドレスを挿入することをシンボル解決。

### 再配置
オブジェクトファイルが実際の固定アドレスに割り当てられること



<h2>
<span id="用語" class="fragment"></span><a href="#%E7%94%A8%E8%AA%9E"><i class="fa fa-link"></i></a>用語</h2>

<h3>
<span id="オブジェクトファイル" class="fragment"></span><a href="#%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB"><i class="fa fa-link"></i></a>オブジェクトファイル</h3>

<p>~.oだけでなく実行形式もオブジェクトファイルと呼ぶこともある。</p>

<h3>
<span id="狭義のコンパイル" class="fragment"></span><a href="#%E7%8B%AD%E7%BE%A9%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB"><i class="fa fa-link"></i></a>狭義のコンパイル</h3>

<p>プリプロセス後、～.sファイルが作成されるまで。</p>

<h3>
<span id="広義のコンパイル" class="fragment"></span><a href="#%E5%BA%83%E7%BE%A9%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB"><i class="fa fa-link"></i></a>広義のコンパイル</h3>

<p>~.oをリンクして実行形式が作成されるまで。</p>

<h3>
<span id="オブジェクトファイルo" class="fragment"></span><a href="#%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%ABo"><i class="fa fa-link"></i></a>オブジェクトファイル(~.o)</h3>

<p>各セクション情報を持っている、セクションヘッダをもつ。まだ、セクションはまとめられていないのでセグメントはもたない。よってプログラムヘッダももたない。</p>

<h3>
<span id="オブジェクトファイル実行形式" class="fragment"></span><a href="#%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E5%AE%9F%E8%A1%8C%E5%BD%A2%E5%BC%8F"><i class="fa fa-link"></i></a>オブジェクトファイル(実行形式)</h3>

<p>~.oのセクションをまとめたもの、セグメントをもっている。各セグメントの情報を保持している、プログラムヘッダをもっている。</p>

<h3>
<span id="セクション" class="fragment"></span><a href="#%E3%82%BB%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3"><i class="fa fa-link"></i></a>セクション</h3>

<p>.text .data .bssとか</p>

<h3>
<span id="セクションヘッダ" class="fragment"></span><a href="#%E3%82%BB%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%98%E3%83%83%E3%83%80"><i class="fa fa-link"></i></a>セクションヘッダ</h3>

<p>各セクションの情報をもつ。リンクはセクション単位で行われる。</p>

<h3>
<span id="プログラムヘッダ" class="fragment"></span><a href="#%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%83%98%E3%83%83%E3%83%80"><i class="fa fa-link"></i></a>プログラムヘッダ</h3>

<p>各セグメントの情報をもつ。ローダはセグメント単位でロードする。</p>

<h3>
<span id="シンボルテーブル" class="fragment"></span><a href="#%E3%82%B7%E3%83%B3%E3%83%9C%E3%83%AB%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB"><i class="fa fa-link"></i></a>シンボルテーブル</h3>

<p>関数、変数の名前とアドレスの対応表。ここにアドレスを挿入することをシンボル解決。</p>

<h3>
<span id="再配置" class="fragment"></span><a href="#%E5%86%8D%E9%85%8D%E7%BD%AE"><i class="fa fa-link"></i></a>再配置</h3>

<p>オブジェクトファイルが実際の固定アドレスに割り当てられること</p>


オブジェクトファイル

### Udev
* 今日勉強した時にUdevが書かれていて、そういえば昔勉強したなーと思ったので、思い出してみた

#### /dev
* Ram上のファイルシステ、ディスク上に実態はない

#### udev
* insmodの後に手動でmknodしていたのを自動でする

##### 何するのudev
* 確かデバイスを検知したらデバイスファイルを作成、取り外したらデバイスファイルを削除する
* きっかけはドライバのロード、アンロード関数
  - insmodでクラスの登録 /sys/class/~~~
  - Udevが検知してる？登録されたdevファイルを元にmknod /etc/ude/rules.dを参照してパーミションなどを設定してデバイスファイルを作成



<h3>
<span id="udev" class="fragment"></span><a href="#udev"><i class="fa fa-link"></i></a>Udev</h3>

<ul>
<li>今日勉強した時にUdevが書かれていて、そういえば昔勉強したなーと思ったので、思い出してみた</li>
</ul>

<h4>
<span id="dev" class="fragment"></span><a href="#dev"><i class="fa fa-link"></i></a>/dev</h4>

<ul>
<li>Ram上のファイルシステ、ディスク上に実態はない</li>
</ul>

<h4>
<span id="udev-1" class="fragment"></span><a href="#udev-1"><i class="fa fa-link"></i></a>udev</h4>

<ul>
<li>insmodの後に手動でmknodしていたのを自動でする</li>
</ul>

<h5>
<span id="何するのudev" class="fragment"></span><a href="#%E4%BD%95%E3%81%99%E3%82%8B%E3%81%AEudev"><i class="fa fa-link"></i></a>何するのudev</h5>

<ul>
<li>確かデバイスを検知したらデバイスファイルを作成、取り外したらデバイスファイルを削除する</li>
<li>きっかけはドライバのロード、アンロード関数

<ul>
<li>insmodでクラスの登録 /sys/class/~~~</li>
<li>Udevが検知してる？登録されたdevファイルを元にmknod /etc/ude/rules.dを参照してパーミションなどを設定してデバイスファイルを作成</li>
</ul>
</li>
</ul>


Udev

### デバイスファイル

#### /dev/consoleとりあえずみてみた
* メジャー番号とマイナー番号が入っているただの箱
* catとかしてもなんか反応しなかった…

~~~txt
ls -lsa /dev/console 
0 crw-------  1 hoge  staff    0,   0  8 16 06:08 /dev/console
~~~

##### メジャー番号、マイナー番号どこで生成しているのだろうか
* insmodっぽい
* insmod ドライバファイル.o
  - そしたらドライバファイルの中のinsmodに対する関数が実行
  - その中でメジャー番号の確保,システムコールハンドラの登録、カーネルへの登録(対応表みたいなやつ)
 * insmodあと下のようなコマンドでメジャー番号をみつけて

~~~txt
cat /proc/devices | grep hoge
~~~

* それを元にmknod メジャー番号 したような。

### insmod
* カーネルに対して動的リンクする
  - 動的リンク
      + メモリ再配置してカーネルの対応表を埋めてセクションをまとめる(.textとかその他もろもろ)

### open
その後にopen()したような
プロセスとドライバのinodeを結んでファイルを開くようにfopみたいなドライバのオペレーションをfile構造体に設定して、ドライバの各関数を使用できるようにする。



<h3>
<span id="デバイスファイル" class="fragment"></span><a href="#%E3%83%87%E3%83%90%E3%82%A4%E3%82%B9%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB"><i class="fa fa-link"></i></a>デバイスファイル</h3>

<h4>
<span id="devconsoleとりあえずみてみた" class="fragment"></span><a href="#devconsole%E3%81%A8%E3%82%8A%E3%81%82%E3%81%88%E3%81%9A%E3%81%BF%E3%81%A6%E3%81%BF%E3%81%9F"><i class="fa fa-link"></i></a>/dev/consoleとりあえずみてみた</h4>

<ul>
<li>メジャー番号とマイナー番号が入っているただの箱</li>
<li>catとかしてもなんか反応しなかった…</li>
</ul>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>ls -lsa /dev/console 
0 crw-------  1 hoge  staff    0,   0  8 16 06:08 /dev/console
</code></pre></div></div>

<h5>
<span id="メジャー番号マイナー番号どこで生成しているのだろうか" class="fragment"></span><a href="#%E3%83%A1%E3%82%B8%E3%83%A3%E3%83%BC%E7%95%AA%E5%8F%B7%E3%83%9E%E3%82%A4%E3%83%8A%E3%83%BC%E7%95%AA%E5%8F%B7%E3%81%A9%E3%81%93%E3%81%A7%E7%94%9F%E6%88%90%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%AE%E3%81%A0%E3%82%8D%E3%81%86%E3%81%8B"><i class="fa fa-link"></i></a>メジャー番号、マイナー番号どこで生成しているのだろうか</h5>

<ul>
<li>insmodっぽい</li>
<li>insmod ドライバファイル.o

<ul>
<li>そしたらドライバファイルの中のinsmodに対する関数が実行</li>
<li>その中でメジャー番号の確保,システムコールハンドラの登録、カーネルへの登録(対応表みたいなやつ)</li>
<li>insmodあと下のようなコマンドでメジャー番号をみつけて</li>
</ul>
</li>
</ul>

<div class="code-frame" data-lang="txt"><div class="highlight"><pre><code>cat /proc/devices | grep hoge
</code></pre></div></div>

<ul>
<li>それを元にmknod メジャー番号 したような。</li>
</ul>

<h3>
<span id="insmod" class="fragment"></span><a href="#insmod"><i class="fa fa-link"></i></a>insmod</h3>

<ul>
<li>カーネルに対して動的リンクする

<ul>
<li>動的リンク

<ul>
<li>メモリ再配置してカーネルの対応表を埋めてセクションをまとめる(.textとかその他もろもろ)</li>
</ul>
</li>
</ul>
</li>
</ul>

<h3>
<span id="open" class="fragment"></span><a href="#open"><i class="fa fa-link"></i></a>open</h3>

<p>その後にopen()したような<br>
プロセスとドライバのinodeを結んでファイルを開くようにfopみたいなドライバのオペレーションをfile構造体に設定して、ドライバの各関数を使用できるようにする。</p>


My Tech Blog

カーネルダンプ出力設定メモ

プロセスのコアダンプ出力設定メモ

SystemTap使ってみた

システム負荷切り分け自分メモ

perf使ってみた

シェルの設定ファイル(bash)

IO待ちメモ

kernel-headersとkernel-devel

VMSTATで表示される各時間の詳細を調べてみた

プロセス権限

Dockerを触ってみた

PID名前空間

httpsのサーバー認証

システムコールめもめも

カーネルスレッド生成&ユーザーモードプロセス生成

マウントと名前空間めもめも

リンカ＆ローダーの役割自分メモメモ

ソースコードから実行形式を作成するまでの流れ

カーネル探検(rest_init()からプロセス番号1生成まで)

カーネル探検(start_kernel()の処理を途中まで見てみた)

カーネル探検(start_kernel以前)

カーネル探検(環境構築からstart_kernelまで)

カーネル再構築簡単メモメモ

KVMの仕組み

カーネル再構築 2.6→4.3

動的リンク (dynamic link)とは

共有ライブラリの仕組み

ソケットと割り込みとTSS

ユーザースタック

オブジェクトファイル

Udev

デバイスファイル

My Tech Blog

カーネルダンプ出力設定メモ

プロセスのコアダンプ出力設定メモ

SystemTap使ってみた

システム負荷切り分け自分メモ

perf使ってみた

シェルの設定ファイル(bash)

IO待ちメモ

kernel-headersとkernel-devel

VMSTATで表示される各時間の詳細を調べてみた

プロセス権限

Dockerを触ってみた

PID名前空間

httpsのサーバー認証

システムコールめもめも

カーネルスレッド生成&ユーザーモードプロセス生成

マウントと名前空間めもめも

リンカ＆ローダーの役割 自分メモメモ

ソースコードから実行形式を作成するまでの流れ

カーネル探検(rest_init()からプロセス番号1生成まで)

カーネル探検(start_kernel()の処理を途中まで見てみた)

カーネル探検(start_kernel以前)

カーネル探検(環境構築からstart_kernelまで)

カーネル再構築簡単メモメモ

KVMの仕組み

カーネル再構築 2.6→4.3

動的リンク (dynamic link)とは

共有ライブラリの仕組み

ソケットと割り込みとTSS

ユーザースタック

オブジェクトファイル

Udev

デバイスファイル

リンカ＆ローダーの役割自分メモメモ