Tại sao các số gọi hệ thống Linux trong x86 và x86_64 khác nhau?

Tôi biết rằng giao diện cuộc gọi hệ thống được triển khai ở mức độ thấp và do đó phụ thuộc vào kiến ​​trúc / nền tảng, chứ không phải mã "chung".

Tuy nhiên, tôi không thể thấy rõ lý do tại sao các cuộc gọi hệ thống trong hạt nhân Linux 32 bit x86 có các số không được giữ giống nhau trong kiến ​​trúc tương tự Linux 64 bit x86_64? Động lực / lý do đằng sau quyết định này là gì?

Dự đoán đầu tiên của tôi là một lý do nền tảng là để giữ cho các ứng dụng 32 bit có thể chạy được trên hệ thống x86_64, do đó thông qua phần bù hợp lý cho số cuộc gọi hệ thống, hệ thống sẽ biết rằng không gian người dùng là 32 bit hoặc 64 bit tương ứng. Tuy nhiên, đây không phải là tình huống. Ít nhất đối với tôi, đọc () là số gọi hệ thống 0 trong x86_64 không thể phù hợp với suy nghĩ này.

Một dự đoán khác là việc thay đổi số cuộc gọi hệ thống có thể có nền tảng bảo mật / cứng, điều mà tôi không thể tự xác nhận.

Không biết gì về các thách thức khi triển khai các phần mã phụ thuộc vào kiến ​​trúc, tôi vẫn tự hỏi làm thế nào để thay đổi số cuộc gọi hệ thống , khi dường như không cần (vì ngay cả một thanh ghi 16 bit sẽ lưu trữ nhiều hơn số ~ 346 hiện tại để thể hiện tất cả các cuộc gọi), sẽ giúp đạt được bất cứ điều gì, ngoài khả năng tương thích (mặc dù sử dụng các cuộc gọi hệ thống thông qua thư viện, libc, giảm nhẹ nó).

Về lý do đằng sau việc đánh số cụ thể, không khớp với bất kỳ kiến ​​trúc nào khác [ngoại trừ "x32", đây thực sự chỉ là một phần của kiến ​​trúc x86_64]: Trong những ngày đầu hỗ trợ x86_64 trong nhân linux, trước khi có bất kỳ kiến ​​trúc nào các hạn chế tương thích ngược nghiêm trọng, tất cả các cuộc gọi hệ thống đã được đánh số lại để tối ưu hóa nó ở mức độ sử dụng bộ đệm .

Tôi không biết đủ về phát triển kernel để biết cơ sở cụ thể cho các lựa chọn này, nhưng rõ ràng có một số logic đằng sau sự lựa chọn để đánh số lại mọi thứ với những con số cụ thể này thay vì chỉ sao chép danh sách từ một kiến ​​trúc hiện có và loại bỏ những kiến ​​trúc không sử dụng. Có vẻ như thứ tự có thể được dựa trên mức độ phổ biến của chúng được gọi - ví dụ đọc / ghi / mở / đóng ở phía trước. Lối ra và ngã ba có vẻ "cơ bản", nhưng mỗi cái chỉ được gọi một lần cho mỗi quy trình.

Cũng có thể có điều gì đó xảy ra về việc giữ các cuộc gọi hệ thống thường được sử dụng cùng nhau trong cùng một dòng bộ đệm (các giá trị này chỉ là số nguyên, nhưng có một bảng trong nhân với các con trỏ hàm cho mỗi một, vì vậy mỗi nhóm 8 lệnh gọi hệ thống chiếm một dòng bộ đệm 64 byte cho bảng đó)

Xem câu trả lời cho câu hỏi "Tại sao các số gọi hệ thống khác nhau trong amd64 linux?" trên Stack Overflow.

Tóm lại: vì mục đích tương thích, danh sách cuộc gọi hệ thống ổn định và chỉ có thể phát triển. Khi kiến ​​trúc x86 64 xuất hiện, ABI (đối số truyền, giá trị trả về) khác nhau, do đó, các nhà phát triển kernel đã có cơ hội mang đến những thay đổi đã được chờ đợi từ lâu.

Nói tóm lại, bởi vì ai đó nghĩ rằng " N+1những cách làm không tương thích một cách vô cớ thì tốt hơn Nnhững cách". Đối với các vòm lịch sử, các số tòa nhà thường được chọn để phù hợp với một số unix độc quyền kế thừa. Nhưng đối với x86_64, các nhà phát triển kernel có thể tự do chọn bất kỳ cách đánh số nào họ thích. Thay vì đưa ra lựa chọn đơn giản và sử dụng lại cách đánh số hiện có, họ đã lựa chọn phát minh ra một tiêu chuẩn mới. Sau đó, họ đã làm điều đó một lần nữa cho aarch64 và một loạt những người khác. Đây là một mẫu lặp đi lặp lại trong phát triển nhân Linux.