Abyste viděli skutečný zdroj systémových volání, budete potřebovat zdroje linuxového jádra. Manuálové stránky, pokud jsou nainstalovány na vašem lokálním systému, obsahují pouze dokumentaci volání a nikoli jejich samotný zdroj.
Bohužel pro vás nejsou systémová volání uložena pouze na jednom konkrétním místě v celém stromu jádra. Je to proto, že různá systémová volání mohou odkazovat na různé části systému (správa procesů, správa souborového systému atd.), a proto by bylo nemožné je uložit mimo část stromu související s danou částí systému.
Nejlepší, co můžete udělat, je vyhledat SYSCALL_DEFINE[0-6] makro. Používá se (samozřejmě) k definování daného bloku kódu jako systémového volání. Například fs/ioctl.c má následující kód:
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
{
/* do freaky ioctl stuff */
}
Taková definice znamená, že ioctl syscall je deklarován a přijímá tři argumenty. Číslo vedle SYSCALL_DEFINE znamená počet argumentů. Například v případě getpid(void) , deklarovaný v kernel/timer.c , máme následující kód:
SYSCALL_DEFINE0(getpid)
{
return task_tgid_vnr(current);
}
Doufám, že to trochu vyjasní věci.
Z pohledu aplikace je systémové volání elementární a atomická operace, kterou provádí jádro.
The Assembly Howto vysvětluje, co se děje, pokud jde o strojové instrukce.
Při manipulaci se systémovým voláním jádro samozřejmě dělá spoustu věcí.
Vlastně byste skoro mohli věřit, že celý kód jádra je věnován zpracování všech systémových volání (to není úplně pravda, ale téměř; z pohledu aplikací je jádro viditelné pouze prostřednictvím systémových volání). Další odpovědí Daniela Kamila Kozara je vysvětlení, jaká funkce jádra spouští obsluhu nějakého systémového volání (velmi často se ale na systémových voláních nepřímo podílí mnoho dalších částí jádra, například plánovač se nepřímo podílí na implementaci fork protože spravuje podřízený proces vytvořený úspěšným fork systémové volání).