Esiste una documentazione di API di sistema Linux/documentazione ABI

Question

Esistono pagine man (2) per le chiamate di sistema, ma queste descrivono il comportamento della libreria C (glibc) che si trova in cima alle chiamate di sistema. La API di sistema RAI/ABI è documentata da qualche parte (oltre a UseTheSourceLuke)? Ho visto qualche menzione delle differenze tra kernel/libc nelle pagine man, ma non ho avuto la sensazione che sia una priorità assoluta documentare queste differenze.

Ciò che intendo dire è: la libreria C è considerata come API Linux stabile/documentata da POLICY e la chiamata di sistema API/ABI del kernel è considerata instabile (potrebbe cambiare) e quindi non documentata di proposito o bassa priorità?

Quindi gli sviluppatori del kernel che modificano una chiamata di sistema creano soluzioni alternative in glibc? E allora l'altra libc?

Posso trovare discussioni storiche su questo argomento?

Edit: Quindi l'ABI è stabile, e anche il comportamento dei syscalls, ma non sono documentati dagli sviluppatori del kernel. Glibc li sta invece documentando (con le sue aggiunte/modifiche). Corretta?

Answer 1

Non penso che gli sviluppatori del kernel pubblichino effettivamente l'API di interrupt, ma è possibile trovare grafici di terze parti come this one.

Answer 2

La risposta alla tua domanda è nello syscall man page. Prestare particolare attenzione al titolo della sezione "Convenzioni di chiamata dell'architettura" e nota come menzionato sopra da John Bollinger che questa informazione potrebbe variare tra le versioni del kernel.

Answer 3

Quello che ho davvero intendo dire è: è la libreria C considerata la stalla/documentata API Linux dalla politica, e l'API chiamata di sistema/ABI del kernel è considerato instabile (può cambiare) e, pertanto, non documentato di proposito o di bassa priorità?

E 'impossibile parlare di politica senza specificare cui politica, per quello.

Le persone che programmano per "Linux" in genere sono in realtà programmi per uno o più versioni di GNU/Linux, a differenza del kernel nuda. Sono quindi incline a dire che probabilmente non stiamo considerando la politica degli sviluppatori del kernel. In effetti, se l'interfaccia della libreria C è disponibile, allora non stiamo parlando di un kernel nullo. Inoltre, in base al tagging, suppongo che tu stia chiedendo della programmazione in C. Se stavi programmando in assembly, l'interfaccia raw di syscall sarebbe naturale e appropriata, e la maggior parte dei miei commenti non sarebbe applicabile.

Se si sta effettivamente indirizzando GNU/Linux all'esclusione di qualsiasi altra cosa, la domanda è in qualche modo ragionevole. D'altra parte, spesso si preferisce programmare per una maggiore compatibilità. In tal caso, non esiste alcuna alternativa all'utilizzo delle interfacce syscall della C-library, poiché le syscall di ogni sistema sono diverse. Le interfacce syscall di Glibc fanno un ottimo lavoro di conformità con POSIX e SUS, quindi usarle (correttamente) è un enorme vantaggio per la portabilità. Anche se altri sistemi Unix e Unix, come OS X, BSD, Solaris, ecc. Non sono obiettivi immediati, raramente è una perdita tenere aperta la possibilità di utilizzare il software su tali sistemi.

In ogni caso, se si fosse certi che il proprio software eseguisse direttamente le syscalls di Linux, si inserirà effettivamente l'assembly inline per farlo ovunque lo si desideri? Sicuramente no - scriveresti le funzioni wrapper.Perché, quindi, dovresti opporsi all'uso delle funzioni wrapper testate e ben documentate già fornite dalla libreria C?

Certamente l'interfaccia syscall di Linux cambia in una certa misura tra le versioni del kernel. Questo può essere considerato la cosa che rende versioni diverse (intendo x.2y ->x.2z o x.y ->z.w). Non sono ben sintonizzato su quanto siano in genere tali modifiche di grandi dimensioni, ma in passato sono state apportate modifiche incompatibili e l'utilizzo delle interfacce della libreria C consente di isolare da tali modifiche in una certa misura. Come descritto sopra, tuttavia, penso che ci siano altri motivi più ampi per preferire l'interfaccia della libreria C.