私はシステムコールインターフェイスが低レベルで実装されているので、「一般的な」コードではなく、アーキテクチャ/プラットフォームによって異なることを理解しています。
ただし、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バイトキャッシュライン）
答え2
バラよりその答え質問「スタックオーバーフローでamd64 Linuxでシステムコール番号が異なるのはなぜですか？」
要約すると、互換性のためにシステムコールのリストは安定しており、増加するだけです。 x86 64アーキテクチャが出たときにABI（パラメータ渡し、戻り値）が異なり、カーネル開発者は長い間待っていた変更をもたらす機会を得ました。
答え3
簡単に言うと、一部の人々は「方法よりもN+1不要な非互換性がN優れている」と信じているからです。歴史的アーキテクチャでは、システムコール番号は、いくつかのレガシー独自のUNIXと一致するように選択されることがよくあります。しかし、x86_64では、カーネル開発者は好きな番号を自由に選択できます。単純な選択をして既存の番号を再利用する代わりに、新しい標準を考案することにしました。それから彼らはaarch64と他のいくつかについて同じことをしました。これはLinuxカーネル開発で頻繁に繰り返されるパターンです。