ManjaroLinux はお利口さんなDistroですが
Octopi だけでは不安になる時があります。

今回、Manjaro そのものは更新されているのに
自分のは更新されない？　というときの対処法

Switching Branches ←クリック(新窓)
rebuild the mirrorlist and update your packages:
and then type

sudo pacman-mirrors --fasttrack 5 && sudo pacman -Syyu

信用データベースを更新し、必要な update が始まるはず・・
反応がなかったOctopi が 911MB update すると言い出しました。

大成功！

超基本だけどプロセス確認コマンドpsのオプション忘備録。

ps

オプションなし。
自分のユーザのプロセスが省略された形で出てくる。

$ ps

  PID TTY           TIME CMD
24863 ttys000    0:00.10 /bin/bash -l
32161 ttys004    0:00.05 -bash

ps -f

fオプション。
UID、PPID、C、STIMEのカラムを追加で確認できる。

$ ps -f

  UID   PID  PPID   C STIME   TTY           TIME CMD
  501 24863 24861   0  7:32PM ttys000    0:00.10 /bin/bash -l
  501 32161 32160   0  6:45PM ttys004    0:00.05 -bash

ps -ef

$ ps -ef

  UID   PID  PPID   C STIME   TTY           TIME CMD
    0     1     0   0 木10AM ??         3:30.67 /sbin/launchd
    0   102     1   0 木10AM ??         0:07.61 /usr/sbin/syslogd
    0   103     1   0 木10AM ??         0:17.05 /usr/libexec/UserEventAgent (System)
...

全ユーザの実行中プロセスが省略されずに表示される。

カラム	意味
UID	ユーザID
PID	プロセス番号
PPID	親プロセスID
C	プロセスのCPU使用状況
STIME	プロセスの開始時刻
TTY	端末名
TIME	プロセスの総実行時間
CMD	実行コマンド名

ps -ef | grep xxxx

プロセスを探したいときは基本的にこれを使う。

$ ps -ef | grep xxxx

例

$ ps -ef | grep httpd

    0   141     1   0 木10AM ??         0:02.34 /usr/sbin/httpd -D FOREGROUND
   70   320   141   0 木10AM ??         0:00.00 /usr/sbin/httpd -D FOREGROUND
  501 32954 32161   0  7:31PM ttys004    0:00.00 grep httpd

参考

【Linux】ps実行時に-efオプションを付ける理由 | 金融エンジニア

状況

Visual Studio Codeでterminal が何も表示しなくなりました。何も出来ません困りました。

またハマっちゃうので自分用メモ

環境

Ubuntu 18.04 LTS

解決策

File -> Preference -> Setting -> Features -> terminal -> Integraged: Ingerit Env

Integraged: Ingerit Env

の歯車マークを押してReset Setting をおす

参照

神投稿
https://stackoverflow.com/questions/54092486/visual-studio-code-terminal-blank-screen

問題

wsl2のwhileループの中でWindowsのコマンド(.exe)を実行すると表示が崩れる。

$ seq 10 | while read i; do ipconfig.exe &>/dev/null; echo $i; done
1

期待した結果が得られない。
ipconfig.exe以外の.exeのコマンドでも同様。
wsl1ではこの問題は発生しない。

原因

(恐らく).exeが標準入力を拾っている。

解決策

.exe に</dev/nullを付ける。

ipconfig.exe </dev/null

$ seq 10 | while read i; do ipconfig.exe </dev/null &>/dev/null; echo $i; done
1
2
3
4
5
6
7
8
9
10

はじめに

Linuxはたくさんのディレクトリやファイルから構成されています。
これまでに実行してきたlsやcpといったコマンドも、実行ファイルと呼ばれるファイルとして配置されています。
あちこちに配置されたファイルを覚えておくのは不可能なので、Linuxにはファイルやディレクトリを検索するコマンドが用意されています。
今回は、それらコマンドの使い方と、わからないことを調べる方法についてまとめます。

findコマンド

findはその名の通り、ファイルを探すコマンドです。

findコマンド

$ find <検索開始ディレクトリ> <検索条件> <アクション>

# コマンドの使用例
$ find . -name file-1.txt -print

#コマンドライン詳細
find             #コマンド
.                #検索開始ディレクトリ (「.」はカレントディレクトリを意味する)
-name file-1.txt #検索条件
-print           #アクション

findコマンドを実行すると、引数で指定した<検索開始ディレクトリ>を起点として、ディレクトリツリーを順に降りながら、<検索条件>満たすファイルを探し、<アクション>を実行します。なお、アクションを指定しない場合は-printが実行されます。

findコマンドの実行例を次の2つの図に示します。検索開始コマンドにはカレントディレクトリを指定しており、その配下のfile-1.txtに一致するファイルを検索しています。ここではファイル名で探すために-nameオプションを指定しています。これについて後述します。

ファイル名で探す (-name, -iname)

findコマンドでファイル名を指定してファイルを探すには、検索条件に-name、もしくは-inameを指定してファイル名を与えます。

オプション	内容
-name	大文字小文字を区別して、指定したファイル名を検索する
-iname	大文字小文字を無視して、指定したファイルを検索する

ファイル名の指定にはワイルドカードとして「*」や「?」が使えますが、-nameや-inameでワイルドカードを使用する場合には、「''」(シングルクォート)または「""」(ダブルクォート)を必ずつける必要があります。

findコマンドでワイルドカードの使用

$ find . -name '*.txt' -print
$ find . -name "*.txt" -print

クォートを使用せずにそのまま使うと、*がbashのパス名展開とみなされ、展開後のファイル名で置き換えられた文字列がfindコマンドに渡されてしまいます。

例えば以下のようなファイル構成の場合を考えます。

findコマンドのワイルドカード使用(パス名展開とクォート)

$ find . -name *.txt -print   #入力したコマンド
↓
# シェルにより、*.txt -> file-1.txt readme.txtという文字列に展開される
↓
$ find . -name file-1.txt readme.txt -print  #上記入力での実行されるコマンド

ワイルドカードを用いる際は、どこまでをシェルが展開して、どのような文字列でコマンドが実行されるかを意識する必要があります。

ファイルの種類で探す (-type)

-typeでファイルタイプを指定することでファイルの種別により検索条件を絞り込むことができます。

指定	ファイル別
-type f	通常ファイル
-type d	ディレクトリ
-type l	シンボリックリンク

複数の検索条件の設定

findコマンドでファイルを検索するとき、検索条件を-a(AND)で区切って並べることで、複数の検索条件を同時に指定するAND検索ができます。

-aを使用した複数条件の検索

$ find . -type f -a -name '*.txt' -print

カレントディレクトリ配下で、通常ファイルで、かつ、ファイル名が〇〇.txtを検索する。

なお、 -aは省略可能です。単に検索結果を並べて書いてもANDの検索結果になります。

Locateコマンド

locateはパス名の一部を指定してファイルを探すためのコマンドです。このとき、ファイル名を専用のデータベースから検索するため、ディスクをスキャンしてファイルを探すfindコマンドに比べて非常に高速に検索することができます。

locateコマンドはLinuxにインストールされていない可能性もあるため、まずはインストールしましょう。

locateコマンドのインストール

CentOSとUbuntuでコマンドが異なりますので注意してください。

locateコマンドのインストール

$ locate --version               #locateコマンドのインストール状態を確認。インストールされていない場合次へ。
$ su                             #rootユーザへ切り替え
$ yum install mlocate            #CentOSでのlocateのインストール
$ sudo apt-get install mlocate   #Ubuntuでのlocateのインストール
$ updatedb                       #データベースの作成

ファイルの検索

locateコマンド

locate [オプション] <検索パターン>

locateコマンドの実行結果を示します。短時間での検索が可能です。

findとlocateコマンドの違い

findコマンドは実行するたびにディレクトリツリーを下って、全てのファイルを検索します。そのため大量のファイルを格納しているディスクを検索する場合はどうしても時間がかかります。

一方、locateコマンドは事前に作成してあるデータベースだけを検索するため、高速に動作します。findコマンドでは何分もかかるような動作であってもlocateコマンドであれば数秒で終了することもあります。
なお、locateコマンドはインストールの時に、ファイルパスのデータベースを1日1回作成するように設定されます。このため次のようなケースが起こりえます。

• locateコマンドで表示されたファイルが実際にはディスク上に存在しない
• locateコマンドでは表示されないのに、ディスク上にファイルが存在する

例えば、たった今作成したばかりのファイルはデータベース上に存在しないためlocateコマンドで見つけることはできません。
locateコマンドは作成してからしばらく経ったファイルを見つけるのに適しています。

さまざまな検索方法の設定

locateコマンドの検索方法をもう少し詳しくみていきましょう。

locateコマンドの検索方法

#ワイルドカードの使用
$ locate '*.sed'
#大文字小文字を区別しない
$ locate -i notes          #-iまたは--ignore-case
#ファイル名だけを対象に検索
$ locate -b puthon         #-bまたは--basename
#複数パターンの指定(OR検索)
$ locate docs document     #複数の検索パターンを指定するとOR検索
#複数パターンの指定(AND検索)
$ locate -A bash doc       #-Aまたは--allを指定して複数の検索パターンを指定するとAND検索

コマンドの使い方を調べる

コマンドの使い方を調べる場合はLinuxのシステム自身に含まれている使い方の説明を読むことをお勧めします。

--helpオプション

多くのLinuxコマンドでは--helpオプションが使用できます。
このオプションを指定するとコマンド自身のヘルプメッセージを表示します。

例として、catコマンドの--helpオプションを表示してみます。
表示されるヘルプメッセージはコマンドによって異なりますが、おおよそ以下の内容で構成されています。

• 使用方法(オプションや引数の指定方法)
• コマンドの概要
• 利用可能なオプション一覧とその意味
• その他の参考資料の紹介

--helpオプションはコマンド名さえ知っていれば、手軽に使用方法が確認できるので、よく利用されます。

manコマンド

manは指定したコマンドのマニュアルを表示するコマンドです。--helpオプションよりも詳しい解説がされているため、コマンドをきちんと理解するためにはmanを参照するのがお勧めです。

manコマンド

$ man <調べたいコマンド名>

catコマンドのmanをみてみましょう。manを起動するとlessコマンドを使ってマニュアルが表示されます。この操作は通常のlessコマンドと同じです。

manで閲覧できる内容はコマンドによって様々ですが、おおよそは以下の通りとなっています。

項目	内容
名前	コマンド名と簡単な説明
書式	オプションや引数の指定方法
説明	コマンドの詳細説明
オプション	利用可能なオプションの一覧とその使用方法
例	代表的な使い方の例
環境変数	動作を変更するための変数について
ファイル	設定ファイルや関連するファイルについて
関連項目	関係のある、または動作が似ているコマンドについて
バグ	不具合について

キーワードからマニュアルを探す

コマンド名がわからないけど、このようなことをしたいというキーワードだけがわかる場合があります。
そんなときは-kオプションを使いましょう。

manコマンド_キーワードで調べる

$ man -k <キーワード>

例えばcopyというキーワードで検索してみましょう。たくさんのコマンドマニュアルが表示されますので、この中からお望みのマニュアルをmanコマンドで表示すればOKです。

セクション

先ほど $ man cat コマンドを実行した結果にCAT(1)と表記されていたと思います。このカッコ内の文字はマニュアルのセクション番号です。
セクションは次の通りに9つに分かれています。

セクション番号	内容
1	コマンド
2	システムコール
3	ライブラリ関数
4	デバイスファイル
5	ファイルの書式
6	ゲーム
7	その他色々なもの
8	システム管理コマンド
9	カーネルルーチン

上記のうち９番のカーネルルーチンについては、比較的最近追加されたものなので、使っているディストリビューションによっては存在しないかもしれません。

マニュアルはセクションごとに分かれていますが、違うセクションに同じ名前のマニュアルが存在していることがあります。例えば、crontabはcrontab(1)とcrontab(5)の2つのセクションに存在しています。この場合は名前だけでなくセクション番号を指定してあげないと、お望みのマニュアルを開くことができません。なお、セクション番号を省略した場合は、複数のセクション番号のうち最小の番号が表示されます。

manコマンド_セクションで調べる

$ man <セクション番号> <名前>

セクション番号のリストを調べることもできます。

セクション番号のリストを調べる

$ man -wa crontab

コマンドを探す

whichコマンド

Linuxのコマンドはディレクトリツリーのどこかにファイルとして存在しています。一方、これまで実行してきたコマンドは、コマンド名を指定するだけで実行できました。これは、$PATHという環境変数に設定された場所から自動的にコマンドを探してくれるためです。環境変数については後の記事で紹介します。ここではコマンドを探す場所がシェルに設定されていると認識しておいてください。

シェルがコマンドを探す場所は次のように確認できます。

コマンドを探す場所の確認

$ echo $PATH

結果

これは、コマンドを探すディレクトリを:で連結したものです。

例えばcatコマンドを実行しようとするとシェルは次の図のようにコマンドを探していきます。

コマンドの実行ファイル

$ cat file-1             #コマンドを入力
↓
シェルは$PATHからコマンドを探す
/usr/local/bin/cat       #見つからない
/usr/local/sbin/cat      #見つからない
/usr/sbin/cat            #見つからない
/usr/bin/cat             #見つかった
↓
/usr/bin/cat file-1          #実行されるコマンド

$PATHで設定する、コマンドを探すディレクトリのことをサーチパスとかあるいは単にパスと呼びます。

コマンドを入力する時に、シェルが実際にどのファイルを実行するかを確認したい時にwhichコマンドを使います。

whichコマンド

$ which [オプション] <コマンド名>

なお、whichコマンドはパスの中から見つかった最初のコマンドだけを表示します。
異なるディレクトリに同じ名前のコマンドが複数配置されているときは-aオプションを指定すると全ての実行ファイルの場所が確認できます。

日本語ドキュメントと英語ドキュメント

多くのコマンドのヘルプには日本語のドキュメントが用意されています。日本語を表示する方法をみていきましょう。

表示言語

$ LANG=ja_JP.UTF-8 cat --help　　　#日本語表示
$ LANG=C cat --help               #英語表示（LANG=Cはデフォルトの意味）

日本語表示結果

日本語で表示できるものの、英語と比較すると一部不正確なところがあるのが現状です。英語に慣れておくほうが賢明かと思います。

参考資料

新しいLinuxの教科書

はじめに

Linixは全てファイルとして表現されている

つまり、文書や画像もファイルとして保存されている事はもちろん、

システム全体もファイルでそれぞれ構成されている。

Linuxカーネルも、ハードウェアもキーボードも入出力が全てファイルに当てられ、そのファイルを介して機器を操作できる。

Linuxの各ディレクトリの役割

/bin

Linux動作に最低限必要な、重要度の高いコマンドを記載する

/dev

デバイスファイルを格納するディレクトリ。
ハードウェアをファイルとして扱える様にした特殊なファイル

/etc

各種アプリケーションや、Linux自体の設定の記載されたファイルを格納するディレクトリ。

/home

Linuxユーザーごとに割り当てられるホームディレクトリ。

/sbin

実行ファイルを置くディレクトリ。

カレントディレクトリの表示

カレントディレクトリを表示するコマンド。

$ pwd
/home/Mac

カレントディレクトリのファイルとディレクトリの表示

$ ls
bin home games ....

$ ls / /home => 複数ディレクトリの指定もできる

相対パスでの移動もできる

$cd .. =>　一つ上の階層へ

Tabキーで補完もできる

$ cd ho

ここでTabキー

$ cd home
$ cd home/local

とパス名が補完できる。

ホームディレクトリへの移動

$ cd

*と?

hoで始まるファイルの一覧表示

$ ls *ho

home homeground hoge

$ ls *.html

index.html hoge.html

hoで始まり長さが4文字のファイルを探す

$ ho??

home

lsコマンドのオプション

$ ls -l =>　ファイル属性の表示
$ ls -a =>　隠しファイルの表示 

オプションは組み合わせて、つなげて書く事も出来る。

nodeのアプリをforeverでデーモン化しようと思っていたところ、そもそもsystemctl使えば必要なかったという話です。

前提

• ts-nodeのexpressアプリをデーモン化したい
• サーバー起動時にも起動したい
• AWSのEC2

systemctlの設定を書く

systemctlは昔のserviceコマンドに替わるものですがだいぶ便利になっています。

昔はinit.dにややこしい起動スクリプトを書く必要がありましたが今では、

/usr/lib/systemd/system/foo.service

[Unit]
Description=foo

[Service]
Type=simple
ExecStart="/home/ec2-user/repo/script/start.sh"

[Install]
WantedBy=multi-user.target

これだけで

$ sudo systemctl enable foo
$ sudo systemctl start foo
$ sudo systemctl stop foo

できます。

start.shには、普通にyarn startが書かれています。
もちろんパスを通したりする必要はありますが。
こんな感じで書いてます。

start.sh

#!/bin/bash

set -e

cd /home/ec2-user/repo

export PATH=/home/ec2-user/.nvm/versions/node/v14.3.0/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/ec2-user/.local/bin:/home/ec2-user/bin:$PATH

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

/home/ec2-user/.nvm/versions/node/v14.3.0/bin/yarn start

便利な世の中になりましたね。

どうでもいいけどserviceコマンドと違って

$ service foo start
$ systemctl start foo

逆なのがなかなか慣れない...

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/oprofile/common.c

0. 呼び出し元 drivers/oprofile/oprof.c

arch固有実装を呼び出しているのは、 drivers/oprofile/oprof.c

drivers/oprofile/oprof.c

static int __init oprofile_init(void)
{
    int err;

    /* always init architecture to setup backtrace support */
    timer_mode = 0;
    err = oprofile_arch_init(&oprofile_ops);
    if (!err) {
        if (!timer && !oprofilefs_register())
            return 0;
        oprofile_arch_exit();
    }

    /* setup timer mode: */
    timer_mode = 1;
    /* no nmi timer mode if oprofile.timer is set */
    if (timer || op_nmi_timer_init(&oprofile_ops)) {
        err = oprofile_timer_init(&oprofile_ops);
        if (err)
            return err;
    }

    return oprofilefs_register();
}


static void __exit oprofile_exit(void)
{
    oprofilefs_unregister();
    if (!timer_mode)
        oprofile_arch_exit();
}

1. oprofile_arch_init()

armでは、arm用のbacktraceが登録される。

arch/arm/oprofile/common.c

int __init oprofile_arch_init(struct oprofile_operations *ops)
{
    /* provide backtrace support also in timer mode: */
    ops->backtrace      = arm_backtrace;

    return oprofile_perf_init(ops);
}

1.1 arm_backtrace

arch/arm/oprofile/common.c

static void arm_backtrace(struct pt_regs * const regs, unsigned int depth)
{
    struct frame_tail *tail = ((struct frame_tail *) regs->ARM_fp) - 1;

    if (!user_mode(regs)) {
        struct stackframe frame;
        arm_get_current_stackframe(regs, &frame);
        walk_stackframe(&frame, report_trace, &depth);
        return;
    }

    while (depth-- && tail && !((unsigned long) tail & 3))
        tail = user_backtrace(tail);
}

2. user_mode()ではない場合 ( walk_stackframe() )

2.1 arm_get_current_stackframe()

arm_get_current_stackframe() は、regsの中身をframeに書き戻すだけなので、うん、わかった！という感じ。

arch/arm/include/asm/stacktrace.h

static __always_inline
void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame)
{
        frame->fp = frame_pointer(regs);
        frame->sp = regs->ARM_sp;
        frame->lr = regs->ARM_lr;
        frame->pc = regs->ARM_pc;
}

2.2 walk_stackframe()

これは、frameを下りながら、関数ポインタfnを実行するお仕事ですね。

arch/arm/kernel/stacktrace.c

void notrace walk_stackframe(struct stackframe *frame,
             int (*fn)(struct stackframe *, void *), void *data)
{
    while (1) {
        int ret;

        if (fn(frame, data))
            break;
        ret = unwind_frame(frame);
        if (ret < 0)
            break;
    }
}
EXPORT_SYMBOL(walk_stackframe);

2.3 unwind_frame()

framepointerから、fp,sp,pcを抜くお仕事。これで順次スタックを参照すると……。

arch/arm/kernel/stacktrace.c

#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
/*
 * Unwind the current stack frame and store the new register values in the
 * structure passed as argument. Unwinding is equivalent to a function return,
 * hence the new PC value rather than LR should be used for backtrace.
 *
 * With framepointer enabled, a simple function prologue looks like this:
 *  mov ip, sp
 *  stmdb   sp!, {fp, ip, lr, pc}
 *  sub fp, ip, #4
 *
 * A simple function epilogue looks like this:
 *  ldm sp, {fp, sp, pc}
 *
 * Note that with framepointer enabled, even the leaf functions have the same
 * prologue and epilogue, therefore we can ignore the LR value in this case.
 */

int notrace unwind_frame(struct stackframe *frame)
{
    unsigned long high, low;
    unsigned long fp = frame->fp;

    /* only go to a higher address on the stack */
    low = frame->sp;
    high = ALIGN(low, THREAD_SIZE);

    /* check current frame pointer is within bounds */
    if (fp < low + 12 || fp > high - 4)
        return -EINVAL;

    /* restore the registers from the stack frame */
    frame->fp = *(unsigned long *)(fp - 12);
    frame->sp = *(unsigned long *)(fp - 8);
    frame->pc = *(unsigned long *)(fp - 4);

    return 0;
}
#endif

2.4 report_trace()

oprofileにがしがしtraceを記録していく処理。

arch/arm/oprofile/common.c

static int report_trace(struct stackframe *frame, void *d)
{
    unsigned int *depth = d;

    if (*depth) {
        oprofile_add_trace(frame->pc);
        (*depth)--;
    }

    return *depth == 0;
}

---

3. user_mode()の場合 ( user_backtrace () )

3.1 user_backtrace

上位レイヤーで、各stackに追加、このuser_backtrace()を呼び出すとなっているので、ここでは単独stackに対する処理。

そして、oprofileに登録して終了！

arch/arm/oprofile/common.c

/*
 * The registers we're interested in are at the end of the variable
 * length saved register structure. The fp points at the end of this
 * structure so the address of this struct is:
 * (struct frame_tail *)(xxx->fp)-1
 */
struct frame_tail {
    struct frame_tail *fp;
    unsigned long sp;
    unsigned long lr;
} __attribute__((packed));

static struct frame_tail* user_backtrace(struct frame_tail *tail)
{
    struct frame_tail buftail[2];

    /* Also check accessibility of one struct frame_tail beyond */
    if (!access_ok(tail, sizeof(buftail)))
        return NULL;
    if (__copy_from_user_inatomic(buftail, tail, sizeof(buftail)))
        return NULL;

    oprofile_add_trace(buftail[0].lr);

    /* frame pointers should strictly progress back up the stack
     * (towards higher addresses) */
    if (tail + 1 >= buftail[0].fp)
        return NULL;

    return buftail[0].fp-1;
}

4. oprofile_arch_exit()

これは大本の、oprofile_perf_exit()を呼び出すだけ。

arch/arm/oprofile/common.c

void oprofile_arch_exit(void)
{
    oprofile_perf_exit();
}

5.（補足)pt_regs

そういえば、他CPU対応とかどうしているのかなー、と見たら、pt_regsがarchごとに分かれていますね…

5.1 ARMのpt_regs

arch/arm/include/asm/ptrace.h

struct pt_regs {
    unsigned long uregs[18];
};

5.1 ARM64のpt_regs

arch/arm64/include/asm/ptrace.h

/*
 * This struct defines the way the registers are stored on the stack during an
 * exception. Note that sizeof(struct pt_regs) has to be a multiple of 16 (for
 * stack alignment). struct user_pt_regs must form a prefix of struct pt_regs.
 */
struct pt_regs {
    union {
        struct user_pt_regs user_regs;
        struct {
            u64 regs[31];
            u64 sp;
            u64 pc;
            u64 pstate;
        };
    };
    u64 orig_x0;
#ifdef __AARCH64EB__
    u32 unused2;
    s32 syscallno;
#else
    s32 syscallno;
    u32 unused2;
#endif

    u64 orig_addr_limit;
    /* Only valid when ARM64_HAS_IRQ_PRIO_MASKING is enabled. */
    u64 pmr_save;
    u64 stackframe[2];
};

5.3 RISC-Vのpt_regs

arch/riscv/include/asm/ptrace.h

struct pt_regs {
    unsigned long epc;
    unsigned long ra;
    unsigned long sp;
    unsigned long gp;
    unsigned long tp;
    unsigned long t0;
    unsigned long t1;
    unsigned long t2;
    unsigned long s0;
    unsigned long s1;
    unsigned long a0;
    unsigned long a1;
    unsigned long a2;
    unsigned long a3;
    unsigned long a4;
    unsigned long a5;
    unsigned long a6;
    unsigned long a7;
    unsigned long s2;
    unsigned long s3;
    unsigned long s4;
    unsigned long s5;
    unsigned long s6;
    unsigned long s7;
    unsigned long s8;
    unsigned long s9;
    unsigned long s10;
    unsigned long s11;
    unsigned long t3;
    unsigned long t4;
    unsigned long t5;
    unsigned long t6;
    /* Supervisor/Machine CSRs */
    unsigned long status;
    unsigned long badaddr;
    unsigned long cause;
    /* a0 value before the syscall */
    unsigned long orig_a0;
};

以上になります。

---

もともと、Linux Kernelのソースコードの一部なので、GPLv2扱いになる（はずの認識）。

https://www.kernel.org/doc/html/latest/index.html

Licensing documentation

The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.

https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing