Dlaczego numery systemowe w Linuksie w wersjach x86 i x86_64 są różne?

Wiem, że interfejs wywołania systemowego jest implementowany na niskim poziomie, a zatem zależy od architektury / platformy, a nie „ogólnego” kodu.

Jednak nie widzę jasno, dlaczego wywołania systemowe w Linuksie 32-bitowe jądra x86 mają numery, które nie są takie same w podobnej architekturze Linux 64-bit x86_64? Jaka jest motywacja / powód tej decyzji?

Moje pierwsze przypuszczenie polega na tym, że przyczyną tła było utrzymywanie działania aplikacji 32-bitowych w systemie x86_64, aby dzięki rozsądnemu przesunięciu w stosunku do numeru wywołania systemowego system wiedział, że przestrzeń użytkownika jest 32-bitowa lub 64-bitowa odpowiednio. Tak jednak nie jest. Przynajmniej wydaje mi się, że read () będący wywołaniem systemowym o numerze 0 w x86_64 nie może być dopasowany do tej myśli.

Innym przypuszczeniem jest to, że zmiana numerów wywołań systemowych może mieć podłoże zabezpieczające / hartujące, czego nie byłem w stanie potwierdzić.

Nie znając wyzwań związanych z implementacją części kodu zależnych od architektury, wciąż zastanawiam się, jak zmienić systemowe numery wywoławcze , kiedy wydaje się, że nie ma takiej potrzeby (ponieważ nawet 16-bitowy rejestr przechowałby znacznie więcej niż obecnie ~ 346 liczb do reprezentowania wszystkich wywołania), pomogłyby w osiągnięciu czegokolwiek, poza zerwaniem kompatybilności (chociaż używanie wywołań systemowych przez bibliotekę, libc, łagodzi to).

Jeśli chodzi o uzasadnienie konkretnej numeracji, która nie pasuje do żadnej innej architektury [z wyjątkiem „x32”, która jest tak naprawdę tylko częścią architektury x86_64]: W pierwszych dniach obsługi x86_64 w jądrze Linuksa, zanim pojawiły się jakieś poważne ograniczenia kompatybilności wstecznej, wszystkie połączenia systemowe zostały ponumerowane, aby zoptymalizować je na poziomie użycia pamięci podręcznej .

Nie wiem wystarczająco dużo na temat rozwoju jądra, aby poznać konkretną podstawę tych wyborów, ale najwyraźniej istnieje pewna logika przy zmianie numeracji wszystkiego za pomocą tych konkretnych liczb zamiast po prostu kopiowania listy z istniejącej architektury i usuwania nieużywanych. Wygląda na to, że kolejność może zależeć od tego, jak często się je nazywa - np. Odczyt / zapis / otwarcie / zamknięcie są z góry. Wyjście i rozwidlenie mogą wydawać się „fundamentalne”, ale każde z nich wywoływane jest tylko raz na proces.

Może się również zdarzyć coś z utrzymywaniem wywołań systemowych, które są często używane razem w tej samej linii pamięci podręcznej (te wartości są tylko liczbami całkowitymi, ale w jądrze znajduje się tabela z wskaźnikami funkcji dla każdego z nich, więc każda grupa 8 wywołań systemowych jest zajęta 64-bajtowa linia pamięci podręcznej dla tej tabeli)

Zobacz tę odpowiedź na pytanie „Dlaczego numery wywołań systemowych różnią się w Linuksie amd64?” na przepełnienie stosu.

Podsumowując: ze względu na kompatybilność lista wywołań systemowych jest stabilna i może się powiększać. Kiedy pojawiła się architektura x86 64, ABI (przekazywanie argumentów, zwracana wartość) było inne, dlatego twórcy jądra skorzystali z okazji, aby wprowadzić zmiany, na które długo czekał.

Krótko mówiąc, ponieważ ktoś pomyślał, że „ N+1nieuzasadnione niezgodne sposoby są lepsze niż Nsposoby”. W przypadku historycznych łuków numery syscall były zwykle wybierane, aby pasowały do ​​niektórych starszych zastrzeżonych systemów uniksowych. Ale dla x86_64 programiści jądra mogli dowolnie wybierać dowolną numerację. Zamiast dokonać prostego wyboru i ponownie wykorzystać istniejącą numerację, wybrali nowy standard. Potem zrobili to ponownie dla aarch64 i kilku innych. Jest to często powtarzany wzorzec w rozwoju jądra Linuksa.