¿Por qué los números de llamada del sistema Linux en x86 y x86_64 son diferentes?

Sé que la interfaz de llamada del sistema se implementa en un nivel bajo y, por lo tanto, depende de la arquitectura / plataforma, no del código "genérico".

Sin embargo, no puedo ver claramente la razón por la cual las llamadas al sistema en núcleos Linux x86 de 32 bits tienen números que no se mantienen iguales en la arquitectura similar Linux 64 bits x86_64. ¿Cuál es la motivación / razón detrás de esta decisión?

Mi primera suposición ha sido que una razón de fondo ha sido mantener las aplicaciones de 32 bits ejecutables en un sistema x86_64, de modo que a través de un desplazamiento razonable al número de llamada del sistema, el sistema sabría que el espacio de usuario es de 32 bits o 64 bits respectivamente. Sin embargo, este no es el caso. Al menos me parece que read () siendo el número de llamada del sistema 0 en x86_64 no puede alinearse con este pensamiento.

Otra suposición ha sido que cambiar los números de llamada del sistema podría tener un fondo de seguridad / endurecimiento, algo que no pude confirmar.

Al ignorar los desafíos de la implementación de las partes del código dependientes de la arquitectura, todavía me pregunto cómo cambiar los números de llamada del sistema , cuando parece que no es necesario (ya que incluso un registro de 16 bits almacenaría en gran medida más que los ~ 346 números actuales para representar a todos llamadas), ayudaría a lograr cualquier cosa, que no sea romper la compatibilidad (aunque el uso de las llamadas del sistema a través de una biblioteca, libc, lo mitiga).

En cuanto al razonamiento detrás de la numeración específica, que no coincide con ninguna otra arquitectura [excepto "x32", que en realidad es solo parte de la arquitectura x86_64]: En los primeros días del soporte x86_64 en el kernel de Linux, antes de que hubiera graves restricciones de compatibilidad con versiones anteriores, todas las llamadas al sistema se volvieron a numerar para optimizarlo en el nivel de uso de la línea de caché .

No sé lo suficiente sobre el desarrollo del kernel para conocer la base específica de estas opciones, pero aparentemente hay cierta lógica detrás de la elección de renumerar todo con estos números en particular en lugar de simplemente copiar la lista de una arquitectura existente y eliminar los no utilizados. Parece que el orden puede basarse en la frecuencia con la que se les llama, por ejemplo, leer / escribir / abrir / cerrar son por adelantado. Salir y bifurcar puede parecer "fundamental", pero cada uno se llama solo una vez por proceso.

También puede estar sucediendo algo acerca de mantener las llamadas del sistema que se usan comúnmente juntas dentro de la misma línea de caché (estos valores son solo enteros, pero hay una tabla en el núcleo con punteros de función para cada uno, por lo que cada grupo de 8 llamadas del sistema ocupa una línea de caché de 64 bytes para esa tabla)

Vea esa respuesta a la pregunta "¿Por qué los números de llamada del sistema son diferentes en amd64 linux?" en desbordamiento de pila.

Para resumir: en aras de la compatibilidad, la lista de llamadas del sistema es estable y solo puede crecer. Cuando apareció la arquitectura x86 64, el ABI (paso de argumento, valor devuelto) era diferente, por lo tanto, los desarrolladores del kernel aprovecharon la oportunidad para traer cambios que tanto habían esperado.

En resumen, porque alguien pensó que "las N+1formas gratuitas de incompatibilidad de hacerlo son mejores que las Nformas". Para los arcos históricos, los números de syscall generalmente se eligen para que coincidan con algunos Unix propietarios. Pero para x86_64 los desarrolladores del kernel eran libres de elegir la numeración que quisieran. En lugar de hacer una elección simple y reutilizar una numeración existente, decidieron inventar un nuevo estándar. Luego lo hicieron de nuevo para aarch64 y muchos otros. Este es un patrón que se repite con frecuencia en el desarrollo del kernel de Linux.