私はシステムコールインターフェイスが低レベルで実装されているので、「一般的な」コードではなく、アーキテクチャ/プラットフォームによって異なることを理解しています。
ただし、Linux 32ビットx86カーネルのシステムコール番号付けが、類似アーキテクチャのLinux 64ビットx86_64の番号付けとはなぜ異なるのかはっきりとわかりません。この決定を下した動機/理由は何でしたか？
私の最初の推測は、バックグラウンド理由がx86_64システムで32ビットアプリケーションを実行し続け、システムコール番号の合理的なオフセットを使用して、システムがユーザースペースがそれぞれ32ビットか64ビットかを知ることができるようにすることです。しかしそうではありません。少なくとも私の考えでは、x86_64のシステムコール番号0であるread（）はこのアイデアと一致しません。
もう1つの推測は、syscall番号を変更するとセキュリティ/強化の背景がある可能性があることです。ただし、これを直接確認することはできません。
コードのアーキテクチャに依存する部分を実装する際の難しさを理解していなくても、まだ知りたいです。システムコール番号を変更する方法、不要に見えるとき（16ビットレジスタでもすべての呼び出しを表すために現在〜346個の数よりも多くの数を格納するので）、互換性を破る以外の目標を達成するのに役立ちます。（これはlibcライブラリを介したシステムコールを使用して軽減できます。）
ベストアンサー1
特定の数字の後の推論は他のアーキテクチャと一致しません[実際にはx86_64アーキテクチャの一部である「x32」を除く）。 Linuxカーネルでx86_64サポートの初期、サポートがありませんでした。深刻な以前のバージョンとの互換性の制限により、すべてのシステムコールの番号が再割り当てされます。キャッシュライン使用レベルで最適化。
私はこれらの選択の具体的な根拠を知るのに十分なカーネル開発について十分ではありませんが、明らかに次のことがあります。一部単に既存のスキーマからリストをコピーし、未使用のリストを削除するのではなく、これらの特定の番号を使用してすべての項目の番号を再編成するように選択するロジックです。順序は呼び出しの頻度によって異なります。たとえば、読み取り/書き込み/開く/閉じるが前にあります。シャットダウンとフォークは「デフォルト」のように見えますが、プロセスごとに一度だけ呼び出されます。
一般的に使用されているシステムコールを同じキャッシュラインに保持すると問題が発生する可能性があります（値は単に整数ですが、カーネルには各システムコールへの関数ポインタを持つテーブルがあるため、8つのシステムコールで構成される各グループがこれを占めます。 ）テーブル用の64バイトキャッシュライン）