I den här artikeln kommer vi att använda faktiska systemanrop för att utföra verkligt arbete i vårt C -program. Först granskar vi om du behöver använda ett systemsamtal och ger sedan ett exempel med hjälp av callfilen () som kan dramatiskt förbättra filkopieringens prestanda. Slutligen kommer vi att gå igenom några punkter att komma ihåg när vi använder Linux -systemsamtal.
Även om det är oundvikligt kommer du att använda ett systemanrop någon gång i din C -utvecklingskarriär, om du inte är inriktad på hög prestanda eller en viss typfunktion kommer glibc -biblioteket och andra grundläggande bibliotek som ingår i större Linux -distributioner att ta hand om majoriteten av dina behov.
Glibc-standardbiblioteket tillhandahåller en plattformsoberoende, vältestad ram för att utföra funktioner som annars skulle kräva systemspecifika systemanrop. Till exempel kan du läsa en fil med fscanf (), fread (), getc (), etc., eller så kan du använda read () Linux -systemanropet. Glibc -funktionerna ger fler funktioner (dvs. bättre felhantering, formaterad IO, etc.) och fungerar på alla systemglibc -stöd.
Å andra sidan finns det tillfällen där kompromisslös prestanda och exakt körning är avgörande. Omslaget som fread () tillhandahåller kommer att lägga till overhead, och även om det är mindre, är det inte helt transparent. Dessutom kanske du inte vill eller behöver de extra funktioner som omslaget tillhandahåller. I så fall tjänar du bäst på ett systemsamtal.
Du kan också använda systemanrop för att utföra funktioner som ännu inte stöds av glibc. Om din kopia av glibc är uppdaterad kommer detta knappast att vara ett problem, men att utveckla på äldre distributioner med nyare kärnor kan kräva denna teknik.
Nu när du har läst ansvarsfriskrivningarna, varningarna och potentiella omvägarna, låt oss nu gräva i några praktiska exempel.
Vilken CPU är vi på?
En fråga som de flesta program förmodligen inte tänker ställa, men en giltig ändå. Detta är ett exempel på ett systemanrop som inte kan kopieras med glibc och som inte täcks av en glibc -omslag. I den här koden ringer vi samtalet getcpu () direkt via funktionen syscall (). Syscall -funktionen fungerar enligt följande:
syscall(SYS_call,arg1,arg2,...);Det första argumentet, SYS_call, är en definition som representerar numret på systemanropet. När du inkluderar sys/syscall.h ingår dessa. Den första delen är SYS_ och den andra delen är namnet på systemanropet.
Argument för samtalet går in i arg1, arg2 ovan. Vissa samtal kräver fler argument, och de fortsätter i ordning från deras man -sida. Kom ihåg att de flesta argument, särskilt för returer, kommer att kräva pekare till char -matriser eller minne tilldelat via malloc -funktionen.
exempel1.c
#omfatta#omfatta
#omfatta
#omfatta
inthuvud() {
osigneradcpu,nod;
// Få nuvarande CPU -kärna och NUMA -nod via systemanrop
// Observera att detta inte har någon glibc -omslag så vi måste kalla det direkt
syscall(SYS_getcpu, &cpu, &nod,NULL);
// Visa information
printf ('Det här programmet körs på CPU -kärnan %u och NUMA -noden %u. n n',cpu,nod);
lämna tillbaka 0;
}
Att kompilera och köra:
gcc exempel1.c -o exempel1
./exempel1
För mer intressanta resultat kan du snurra trådar via pthreads -biblioteket och sedan ringa den här funktionen för att se på vilken processor din tråd körs.
Sendfile: Överlägsen prestanda
Sendfile ger ett utmärkt exempel på att förbättra prestanda genom systemsamtal. Sendfile () -funktionen kopierar data från en filbeskrivning till en annan. I stället för att använda flera funktioner för fread () och fwrite () utför sendfile överföringen i kärnutrymmet, vilket reducerar overhead och därmed ökar prestandan.
I det här exemplet ska vi kopiera 64 MB data från en fil till en annan. I ett test kommer vi att använda standard läs-/skrivmetoder i standardbiblioteket. I den andra använder vi systemanrop och sendfile () -anropet för att spränga denna data från en plats till en annan.
test1.c (glibc)
#omfatta#omfatta
#omfatta
#omfatta
#define BUFFER_SIZE 67108864
#define BUFFER_1 'buffer1'
#define BUFFER_2 'buffer2'
inthuvud() {
FIL*fel, *slutet;
printf (' nI/O -test med traditionella glibc -funktioner. n n');
// Ta en BUFFER_SIZE -buffert.
// Bufferten kommer att ha slumpmässig data i den men vi bryr oss inte om det.
printf ('Tilldela 64 MB buffert:');
röding *buffert= (röding *) malloc (BUFFER_SIZE);
printf ('GJORT n');
// Skriv bufferten till fOut
printf ('Skriva data till första bufferten:');
fel= fopen (BUFFER_1, 'wb');
fwrite (buffert, storlek av(röding),BUFFER_SIZE,fel);
fclose (fel);
printf ('GJORT n');
printf ('Kopiera data från första fil till andra:');
slutet= fopen (BUFFER_1, 'rb');
fel= fopen (BUFFER_2, 'wb');
skrämmande (buffert, storlek av(röding),BUFFER_SIZE,slutet);
fwrite (buffert, storlek av(röding),BUFFER_SIZE,fel);
fclose (slutet);
fclose (fel);
printf ('GJORT n');
printf ('Befriande buffert:');
fri (buffert);
printf ('GJORT n');
printf ('Radera filer:');
avlägsna (BUFFER_1);
avlägsna (BUFFER_2);
printf ('GJORT n');
lämna tillbaka 0;
}
test2.c (systemanrop)
#omfatta#omfatta
#omfatta
#omfatta
#omfatta
#omfatta
#omfatta
#omfatta
#omfatta
#define BUFFER_SIZE 67108864
inthuvud() {
intfel,slutet;
printf (' nI/O -test med sendfile () och relaterade systemanrop. n n');
// Ta en BUFFER_SIZE -buffert.
// Bufferten kommer att ha slumpmässig data i den men vi bryr oss inte om det.
printf ('Tilldela 64 MB buffert:');
röding *buffert= (röding *) malloc (BUFFER_SIZE);
printf ('GJORT n');
// Skriv bufferten till fOut
printf ('Skriva data till första bufferten:');
fel=öppen('buffer1',O_RDONLY);
skriva(fel, &buffert,BUFFER_SIZE);
stänga(fel);
printf ('GJORT n');
printf ('Kopiera data från första fil till andra:');
slutet=öppen('buffer1',O_RDONLY);
fel=öppen('buffer2',O_RDONLY);
skicka Fil(fel,slutet, 0,BUFFER_SIZE);
stänga(slutet);
stänga(fel);
printf ('GJORT n');
printf ('Befriande buffert:');
fri (buffert);
printf ('GJORT n');
printf ('Radera filer:');
ta bort länken('buffer1');
ta bort länken('buffer2');
printf ('GJORT n');
lämna tillbaka 0;
}
Kompilerings- och körtester 1 & 2
För att bygga dessa exempel behöver du utvecklingsverktygen installerade på din distribution. På Debian och Ubuntu kan du installera detta med:
benägenInstallerabygg-väsentligaKompilera sedan med:
gcctest1.c-ellertest1&& gcctest2.c-ellertest2För att köra båda och testa prestanda, kör:
tid./test1&& tid./test2Du bör få resultat så här:
I/O -test med traditionella glibc -funktioner.
Tilldela 64 MB buffert: KLARTSkriva data till den första bufferten: Klar
Kopiera data från första fil till andra: Klar
Befriande buffert: KLAR
Radera filer: KLART
verkliga 0m0.397s
användare 0m0.000s
sys 0m0.203s
I/O -test med sendfile () och relaterade systemanrop.
Tilldela 64 MB buffert: KLART
Skriva data till den första bufferten: Klar
Kopiera data från första fil till andra: Klar
Befriande buffert: KLAR
Radera filer: KLART
verkliga 0m0.019s
användare 0m0.000s
sys 0m0.016s
Som du kan se går koden som använder systemanropen mycket snabbare än glibc -ekvivalenten.
Saker att komma ihåg
Systemanrop kan öka prestanda och ge ytterligare funktionalitet, men de är inte utan sina nackdelar. Du måste väga fördelarna som systemsamtal ger mot bristen på plattformsportabilitet och ibland minskad funktionalitet jämfört med biblioteksfunktioner.
När du använder vissa systemsamtal måste du se till att använda resurser som returneras från systemsamtal snarare än biblioteksfunktioner. Till exempel är FIL -strukturen som används för glibc: s fopen (), fread (), fwrite () och fclose () funktioner inte samma som filbeskrivningsnumret från det öppna () systemanropet (returneras som ett heltal). Att blanda dessa kan leda till problem.
I allmänhet har Linux -systemsamtal färre stötfångarbanor än glibc -funktioner. Även om det är sant att systemanrop har viss felhantering och rapportering, får du mer detaljerad funktionalitet från en glibc -funktion.
Och slutligen, ett ord om säkerhet. Systemanrop gränsar direkt mot kärnan. Linux -kärnan har omfattande skydd mot shenanigans från användarland, men det finns oupptäckta buggar. Lita inte på att ett systemsamtal validerar din inmatning eller isolerar dig från säkerhetsproblem. Det är klokt att se till att data du lämnar till ett systemanrop saneras. Naturligtvis är detta ett bra råd för alla API -samtal, men du kan inte vara försiktig när du arbetar med kärnan.
Jag hoppas att du gillade detta djupare dyk i Linux -systemsamtalens land. För en fullständig lista över Linux System Call, se vår huvudlista.