AT＆T Unixおよび歴史的にBSDには、スレッドではなくプロセスしかありませんでした。プロセステーブルの各エントリは、struct proc構造体とstruct user構造体の2つの部分で構成されていました。前者は常にカーネルメモリに常駐していました。後者は、プロセスの交換の一部として交換することができます。 （これは、Unicesがdemand-pagedではなく、実際にswapしたことを思い出してください。）
struct user構造体は「u領域」とも呼ばれていました。これは、いくつかの巧妙なメモリマッピングの結果として、現在のプロセスのuser構造体は常にカーネルメモリ内の同じ固定仮想アドレスにあり、グローバルシンボルuを介して（ポインターではなく）コードで参照できるためです。
構造には、プロセスが現在実行中のプロセスではないときに、カーネルが必要としなかったあらゆる種類のものが含まれています。これには、ファイル作成マスク、開いているファイル記述子テーブル、リソース制限などが含まれます。シグナルハンドラーのアドレスが含まれています。これは、プロセスが実行中でハンドラーを呼び出そうとしているときにのみ必要ですが、ブロックされたシグナルのマスクや保留中のシグナルのセットは含まれません。これは、プロセスがスワップアウトされるときに必要であり、したがってstruct procに含まれていました。一部のUnicesでは、スタック上で渡されるのではなく、現在のI/O操作の引数が含まれていました。
もちろん、この設計の理由は長い間保持されていません。彼らは1980年代の終わりまでにかなり時代遅れになりました。結局のところ、グローバル変数と巧妙なメモリマッピングは、結局、ポインタを介した単純な間接参照に置き換えられました。 struct userは、BSDのCライブラリヘッダーファイル（<sys/user.h>内）にまだ存在していますが、ソースの互換性のために主に存在しています。 XNUでは 、実際には空の構造体として宣言されています。 FreeBSDに関する注意事項 これは主に、a.outフォーマットの実行のためにコアダンプで使用されるために存在します。 Linuxは、アイデアが時代遅れになるまで存在しませんでしたし、この方法ではまったく機能しません。
この設計には多少のばらつきがありました。例：AT＆T Unix System 5には、u構造体のstruct euserフィールドによってポイントされる「拡張ユーザー領域」、u_euserpがあり、そこにいくつかのものが存在していました。これは、さらなるポイントの例です。 struct userのすべてのメンバー変数は、当時のCカーネルのコーディング規則とその初期の言語規則に従ってu_somethingと名付けられています。 これはumaskがそのように命名された理由であると考えられてきました 、それは確かではありませんが。
参考文献
- スティーブ・D・ペイト（1996）。 UNIX Internals：A Practical Approach。 Addison-Wesley。 ISBN 9780201877212。
- モーリス・J・バッハ（1987）。 Unix®オペレーティングシステムの設計。プレンティスホール。 ISBN 0132017571。