Co před námi tají /proc (22)

Pro představu o tom, co nás čeká a co už máme za sebou, uvedu výpis adresářů, které lze nalézt na mém počítači v /proc. Otečkovány jsou ty adresáře, které jsme už prošli.:

.acpi/    .ide/    sys/
.bus/     .irq/    sysvipc/
.driver/   net/    tty/
.fs/      .nv/

Pozor! Opět jsem přešel na novější jádro – tentokrát 2.4.13-pre3. Samozřejmě hlavním důvodem jsou nedočkaví čtenáři Roota, kteří vyžadují vždy aktuální informace :)

net

V tomto adresáři najdeme informace o síťovém rozhraní jádra, a to především základní a obecnější informace o využití jednotlivých vrstev a rozhraní. Jsou zde přítomny tyto soubory:

arp, dev, dev_mcast, igmp, netlink, netstat, raw, route, rt_cache,
rt_cache_stat, snmp, sockstat, softnet_stat, tcp, udp, unix

Na první pohled je jich docela dost, ale hodně jich je podobných a pouze některé obsahují opravdu důležité informace. Nebudeme se v tom příliš šťourat, jednak sítě nejsou moje nejsilnější stránka, a taky po minulém fiasku s velikostí sektoru disku utrpělo moje sebevědomí značnou ránu. Navíc doma mám pouze jeden počítač, a tak ukazovat příklady sítě není zrovna nejjednodušší (kromě loopback). Tak opravdu letecky nejprve to, co je jednodušší: Soubor arp zpřístupňuje obsah ARP keše. V té se uchovávají vazby mezi IP adresami a HW adresami jednotlivých síťových karet. To je potřeba pro směrování paketů v rámci jedné sítě. ARP je potom zkratka pro Adress Resolution Protokol. dev obsahuje statistiky provozu jednotlivých sítových rozhraní:

Inter-|   Receive                                                |
 face |bytes    packets errs drop fifo frame compressed multicast|...
    lo:    2453       9    0    0    0     0          0         0
  eth0:       0       0    0    0    0     0          0         0
 plip0:       0       0    0    0    0     0          0         0

V ukázce je zobrazena první polovina pro přijaté pakety a po ní následuje v souboru již nezobrazené tabulka pro provoz na zařízení. Je zde vidět jednak množství zpracovaných dat (bytes nebo packets), počet chybných (errs) a zahozených drop) paketů. Pro jiná zařízení než lo je ještě k dispozici informace o rámcích (frames), kompresi (compress) a multicastingovém provozu na tomto zařízení (multicast).

Dalším souborem je dev_mcast, kde jsou informace o zařízeních schopných multicastového provozu (tedy skupinové komunikace na více adres současně). Je zde vidět počet uživatelů a skupin (třetí a čtvrtý sloupec) a multicastová adresa (poslední položka).

igmp obsahuje další informace k multicastingu pro IP, netstat některé statistiky síťového provozu, netlink obsahuje informace o speciálním síťovém rozhraní, které se používá pro komunikaci mezi jádrem a uživatelskými aplikacemi (na jednom stroji).

Soubory route, rc_cache a rt_cache_stat uvádějí důležité informace o směrování IP paketů. Soubor route udává použitá směrovací pravidla v jádře a zbylé dva poskytují informace o obsahu a využití keše směrování IP paketů.

snmp udává některé další detailní informace o jednotlivých protokolech, sockstat potom přehledně vypisuje využití soketů jednotlivých typů. Jsou zde informace o využití TCP, UDP, RAW a dalších soketů. Nejsou zde však obsaženy sokety rodiny AF_UNIX. Podrobné informace (jako adresy odesilatele a příjemce, identifikace vlastníka, stav front atd.) jsou pro jednotlivé typy soketu v souborech tcp, udp respektive unix.

Posledním souborem je softnet_stat. Ten obsahuje statistiky pro všechna zařízení a protokoly (nad IP) dohromady. První dva sloupce udávají počet celkem přenesených paketů a počet celkem zahozených paketů. Význam dalších polí je možno nalézt v net/core/dev­.c:dev_proc_stat­s().

I když tohle byl spíše průzkum bojem, než nějaké pořádné vysvětlení, bude to muset stačit. U části souborů jsou celkem vysvětlující hlavičky tabulek, u zbytku jsem se snažil (tam, kde jsem věděl) napsat, co se dalo. Třeba se k této problematice někdy vrátí nějaký povolanější síťař, než jsem já.

sysvipc

V tomhle adresáři nalezneme informace o aktuálně využívaných prostředcích pro komunikaci mezi jednotlivými procesy, které jsou obvykle označovány jako IPC System V. IPC jako Inter Process Communication a System V (V jako římské pět) je verze Unixu (od AT&T), ve které se tyto prostředky poprvé objevily. Jedná se o tři částečně vzájemně nahraditelné způsoby komunikace mezi jednotlivými procesy. První způsob jsou zprávy (messages), mechanismus zasílání strukturovaných dat do schránek, ke kterým mají přístup všechny procesy (obecně). Je to jako papírová pošta. Napíšete dopis, adresu a někdo ho pak doručí až na místo. Můžete také dopis nechat ležet na ulici a tím ho adresovat libovolnému kolemjdoucímu.

Další metodou komunikace jsou semafory (semaphore). Velmi zjednodušeně je lze popsat jako nastavitelné příznaky. Klasickým použitím je přístup k objektu, který je schopen obsloužit jen jeden požadavek najednou. Jako příklad třeba tiskárna. Pokud budu chtít tisknout, zkontroluji příznak PRINTER_BUSY. Není-li nastaven, nastavím ho – tím si tiskárnu zaberu pro sebe – a tisknu. Až skončím, nastavím příznak zpět na volno. Pokud je ale při testování obsazen, znamená to, že již někdo jiný tiskne. Potom musím počkat, až někdo jiný nastaví příznak do pozice volno, a můžu zkusit celý postup znovu. No snažil jsem se o počítačový příklad, ale pro ty, co o počítačových semaforech nikdy neslyšeli, bude asi lepší si představit železniční přejezd se semaforem. Ten tam plní stejnou funkci. Zajišťuje, aby byl přejezd využíván vždy jen v jednom z kolmých směrů (vlak nebo auta, ale nikdy dohromady).

Posledním způsobem komunikace dvou procesů je sdílená paměť. S tímto pojmem se někdy trochu zahrává, tak jen vysvětlím, jaké jsou možnosti. Pokud se mluví o správě paměti, je sdílenou pamětí označována část fyzického adresového prostoru například s kódem (dynamické) knihovny, který je namapován do více logických adresových prostorů (tedy procesů). Tyto procesy však o tom nemusí mít (a zpravidla nemají) nejmenší tušení. Celý mechanismus slouží jen pro úsporu paměti, případně času a dalších prostředků. Naproti tomu sdílená paměť v kontextu meziprocesorové komunikace označuje takovou fyzickou paměť mapovanou na více procesů, o které tyto procesy vědí a používají ji k vzájemné komunikaci (synchronizaci, předávání dat atd.).

Probíraný adresář sysvipc obsahuje odpovídající tři soubory. V nich je potom možno nalézt aktuálně používané objekty patřičného druhu, na každém řádku jeden. Všechny soubory mají několik společných sloupců, a ty si popíšeme dohromady. První položkou je klíč key. Pokud se zamyslíte nad implementací spolupráce více procesů, zjistíte, že musí mít nějakou společnou informaci, kterou se vymezí do skupiny, ve které potom operují. Pokud mají přistupovat ke sdílenému objektu, musí mít pro něj všichni jednoznačnou identifikaci. Tento problém je vyřešen tak, že při vytváření objektů IPC se vždy zadává tzv. klíč, což je hodnota (číslo), na které se dohodnou spolupracující procesy. Pro každý proces potom funkce pro vytvoření IPC objektu vrátí jeho identifikaci, která se používá při další manipulaci. Ta už ale může být pro každý proces jiná (i když to není nutné). Další „společnou“ položkou je ID. To je hodnota v druhém sloupci nadepsaném vracená funkcemi pro vytváření IPC objektů.Následuje položka shmid, semid nebo msgid, to je právě identifikace perms, obsahuje standardní unixová přístupová práva pro daný objekt. Ta se kontrolují vůči identifikaci procesu, který s objekty manipuluje. Zbývají identifikace majitele objektu v položkách uid a gid a identifikace toho, kdo objekt vytvořil, v cuid a cgid. U každého objektu je ještě několik časů. Jsou to některé z stime pro čas posledního odeslání (zápisu), rtime pro poslední příjem (čtení zprávy), ctime pro čas poslední modifikace (change), atime – připojení a dtime – odpojení sdílené paměti a nakonec otime pro čas poslední operace nad semaforem.

Než se pustíme do položek charakteristických pro jednotlivé typy objektů IPC, uvedu jako ukázku výpis souboru pro sdílenou paměť.

key    shmid  perms     size  cpid  lpid nattch   uid   gid  ...
  0        0   1600    46084   473   473       3    48    48  ...
  0 12713985   1777  1051392 28446 28448       1     0   100  ...
  0 24477698   1777   196608 28476 28481       2   500   100  ...

Konce řádků s identifikací toho, kdo objekty vytvořil a jednotlivé časy jsou bohužel z důvodů místa ořezány. To důležité ale zůstalo. Když už máme výpis, začneme tedy sdílenou pamětí. Sloupec size udává velikost oblasti. Ta se vždy alokuje po celých stránkách kvůli mechanismu, kterým je zajištěno vlastní sdílení (mapování FAP -&gt LAP). Obsluhovaná a udávaná je však velikost požadovaná při vytvoření. Dále jsou zde cpid a lpid, což jsou čísla procesů (PID), které objekt vytvořil (Creator PID), respektive naposledy použil (Last PID). nattch je počet procesů, které sdílenou paměť používají. Přesněji se jedná o počet vyřízených požadavků na připojení funkcí shmat(), ale běžně se tato operace provádí v každém procesu právě jednou. uid a gid už jsme probrali.

U semaforů je navíc jen položka nsems. Ta udává počet elementů v jednom objektu semaforu. Pro snazší práci se totiž jako objekt IPC nebere jeden semafor, ale rovnou jejich pole. K tomu se pak přistupuje při jednotlivých operacích najednou (a atomicky).

Zbývají ještě zprávy. U všech objektů IPC je omezen jejich maximální současný počet na jednom systému. U zpráv je navíc omezena velikost jedné zprávy. Právě velikost paměti vyhrazené pro doručované zprávy udává sloupec cbytes. Aktuální počet zpráv ve frontě pak sloupec qnum. lspid je PID procesu, který zprávu naposledy poslal (msgsnd()) a lrpid toho, kdo naposledy zprávu přijal (msgrcv()).

Pokud se budete zajímat o teorii, funkčnost nebo programování IPC, určitě vám bude pro začátek stačit libovolná knížka o programování a/nebo architektuře Unixu. Pro pokročilé doporučuji samozřejmě zdrojáky jádra (případně ještě manuálové stránky pro všechny – man 5 ipc).

tty

Zde najdeme něco o ovladačích jednotlivých terminálových zařízení. Vzhledem k tomu, že v jejich názvech (a i všem ostatním) je teď trochu zmatek (třeba kvůli devfs), je celá tahle oblast trochu nepřehledná, ale pokusíme se podívat, co se s tím dá dělat.

Zajímavý pro nás bude pouze jeden soubor z celého adresáře, a to drivers. Druhý soubor ldiscs a oba adresáře driver a ldisc neobsahují nic až tak zajímavého.

pty_slave            /dev/pts      136   0-255 pty:slave
pty_master           /dev/ptm      128   0-255 pty:master
pty_slave            /dev/ttyp       3   0-255 pty:slave
pty_master           /dev/pty        2   0-255 pty:master
/dev/vc/0            /dev/vc/0       4       0 system:vtmaster
/dev/ptmx            /dev/ptmx       5       2 system
/dev/console         /dev/console    5       1 system:console
/dev/tty             /dev/tty        5       0 system:/dev/tty
unknown              /dev/vc/%d      4    1-63 console

Tak, tohle je tedy soubor drivers. První sloupec obsahuje jméno driveru pro daný terminál, za ním je jméno terminálu jako položka v souborovém systému /dev. Následuje hlavní číslo daného zařízení, počet zařízení (rozsah) a nakonec typ. Typy jsou základní čtyři. Systémový terminál, konzole, sériový terminál a nakonec pseudo terminál. Pseudoterminály jsou zde první čtyři, zbytek jsou různé systémové terminály. To zatím není nic moc, takže co dál? No zklamu vás, nic. Sice mám slušnou představu, jak terminály pracují (i když dost obecně), ale ta spousta typů a jejich zařízení mi zatím příliš jasná není. Tak do toho nebudu zabředávat (alespoň nyní) a jdu od toho.