Perché i numeri di chiamata del sistema Linux in x86 e x86_64 sono diversi?

So che l'interfaccia di chiamata di sistema è implementata su un livello basso e quindi codice di architettura / piattaforma dipendente, non "generico".

Tuttavia, non riesco a vedere chiaramente il motivo per cui le chiamate di sistema nei kernel x86 a 32 bit di Linux hanno numeri che non sono mantenuti uguali nell'architettura simile a Linux x86_64 a 64 bit? Qual è la motivazione / ragione dietro questa decisione?

La mia prima ipotesi è stata che un motivo di fondo è stato quello di mantenere le applicazioni a 32 bit eseguibili su un sistema x86_64, in modo che tramite un ragionevole offset al numero di chiamata del sistema il sistema sapesse che lo spazio utente è 32-bit o 64-bit rispettivamente. Questo non è tuttavia il caso. Almeno mi sembra che read () essendo il numero di chiamata di sistema 0 in x86_64 non possa essere allineato con questo pensiero.

Un'altra ipotesi è stata che la modifica dei numeri di chiamata del sistema potrebbe avere un background di sicurezza / protezione, qualcosa che non sono stato in grado di confermare.

Essendo ignaro delle sfide legate all'implementazione delle parti di codice dipendenti dall'architettura, mi chiedo ancora come cambiare i numeri di chiamata del sistema , quando non sembra necessario (poiché anche un registro a 16 bit memorizzerebbe molto più dei numeri attualmente ~ 346 per rappresentare tutto chiamate), aiuterebbe a ottenere qualsiasi cosa, oltre a interrompere la compatibilità (sebbene l'uso delle chiamate di sistema attraverso una libreria, libc, la mitiga).

Per quanto riguarda il ragionamento alla base della numerazione specifica, che non corrisponde a nessun'altra architettura [tranne "x32" che è in realtà solo parte dell'architettura x86_64]: Nei primissimi giorni del supporto x86_64 nel kernel di Linux, prima che ci fossero gravi vincoli di compatibilità con le versioni precedenti, tutte le chiamate di sistema sono state rinumerate per ottimizzarle a livello di utilizzo della cache .

Non so abbastanza sullo sviluppo del kernel per conoscere le basi specifiche di queste scelte, ma a quanto pare c'è una logica dietro la scelta di rinumerare tutto con questi numeri particolari piuttosto che semplicemente copiare l'elenco da un'architettura esistente e rimuovere quelli inutilizzati. Sembra che l'ordine possa essere basato sulla frequenza con cui vengono chiamati, ad esempio read / write / open / close sono in primo piano. Exit e fork possono sembrare "fondamentali", ma ciascuno di essi viene chiamato una sola volta per processo.

Potrebbe anche succedere qualcosa riguardo al mantenimento delle chiamate di sistema che sono comunemente usate insieme nella stessa linea di cache (questi valori sono solo numeri interi, ma c'è una tabella nel kernel con puntatori di funzione per ognuno, quindi ogni gruppo di 8 chiamate di sistema occupa una riga della cache a 64 byte per quella tabella)

Vedi quella risposta alla domanda "Perché i numeri di chiamata di sistema sono diversi in Linux amd64?" su Stack Overflow.

Per riassumere: per motivi di compatibilità, l'elenco delle chiamate di sistema è stabile e può solo crescere. Quando è apparsa l'architettura x86 64, l'ABI (passaggio degli argomenti, valore restituito) era diverso, quindi gli sviluppatori del kernel hanno colto l'occasione per apportare cambiamenti che erano attesi da tempo.

In breve, perché qualcuno pensava che "i N+1modi di farlo gratuitamente sono incompatibili con i Nmodi". Per gli archi storici, i numeri di syscall erano generalmente scelti per abbinare alcuni unix proprietari legacy. Ma per x86_64 gli sviluppatori del kernel erano liberi di scegliere qualsiasi numerazione che gli piaceva. Piuttosto che fare la scelta semplice e riutilizzare una numerazione esistente, hanno fatto la scelta di inventare un nuovo standard. Poi l'hanno fatto di nuovo per aarch64 e molti altri. Questo è un modello spesso ripetuto nello sviluppo del kernel Linux.