Jan Pechanec. verze: 17. prosince SISAL MFF UK, Malostranské nám. 25, Praha 1

Programov´ an´ı v UNIXu Jan Pechanec verze: 17. prosince 2007 (c) 1999 – 2004 Martin Beran (c) 2005 – 2007 Jan Pechanec

SISAL MFF UK, Malostranské n´ am. 25, 118 00 Praha 1 [email protected]

Organizaˇcn´ı vˇeci: • tento pˇredmˇet je 2/1, cviˇcen´ı bude jednou za dva t´ ydny v laboratoˇri UNIX • vˇsechny informace které budete potˇrebovat a materi´ aly k pˇredn´ aˇsce jsou na http://www.devnull.cz/mff, vˇcetnˇe aktuáln´ı verze tˇechto poznámkov´ ych slajd˚ u • je potˇreba se zapsat na cviˇcen´ı na webu • z´ apoˇcet je za z´ apoˇctov´ y program • zkouˇska má p´ısemnou a u ´ stn´ı ˇca´st, je nutné z´ıskat z´ apoˇcet pˇ red zkouˇ skou, vˇcetnˇe pˇredterm´ın˚ u • zkouˇset se bude to, co bude odpˇredneseno (kromˇe témat na vyplnˇen´ı pˇr´ıpadnˇe zbylého ˇcasu). Vˇetˇsina informac´ı je ve slajdech, ale ˇrada d˚ uleˇzit´ ych podrobnost´ı m˚ uˇze chybˇet. • pˇredpoklady: – uˇzivatelsk´ a znalost UNIXu, programován´ı v shellu na u ´rovni pˇredn´ aˇsky ´ ,,Uvod do UNIXu a TCP/IP” – znalost jazyka C – znalost z´ akladn´ıch pojm˚ u teorie operaˇcn´ıch systém˚ u • tento text je pr˚ ubˇeˇznˇe doplˇ nován, ChangeLog zaˇc´ıná na stranˇe 207.

1

Obsah • u ´ vod, v´ yvoj UNIXu a C, program´ atorské n´ astroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupová práva, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • signály • synchronizace a komunikace proces˚ u • s´ıt’ová komunikace • vl´ akna, synchronizace vl´ aken • ??? - bude definováno pozdˇeji, podle toho kolik zbyde ˇcasu

• budeme se zab´ yvat hlavnˇe principy UNIXu a programován´ım pro UNIX pouze v jazyce C. • pˇ redn´ aˇ ska je pˇ rev´ aˇ znˇ e o syst´ emov´ ych vol´ an´ıch, tj. rozhran´ım mezi uˇ zivatelsk´ ym prostorem a j´ adrem • pˇri popisu API se budeme drˇzet normy Single UNIX Specification, version 3. Systémy podporuj´ıc´ı tuto specifikaci mohou pouˇz´ıvat oznaˇcen´ı UNIX 03. V souˇcasné dobˇe (09/2007) jsou to posledn´ı verze systém˚ u Solaris, AIX, HP-UX a Mac OS X. • pro konkrérn´ı pˇr´ıklady budu pouˇz´ıvat vˇetˇsinou systémy FreeBSD a Solaris.

2

Obsah • u ´ vod, v´ yvoj UNIXu a C, program´ atorsk´ e n´ astroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupová práva, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • signály • synchronizace a komunikace proces˚ u • s´ıt’ová komunikace • vl´ akna, synchronizace vl´ aken • ??? - bude definováno pozdˇeji, podle toho kolik zbyde ˇcasu

Literatura v ˇ ceˇ stinˇ e 1. Skoˇcovsk´ y, L.: Principy a probl´ emy operaˇ cn´ıho syst´ emu UNIX. Science, 1993 2. Skoˇcovsk´ y, Ludˇek: UNIX, POSIX, Plan9. L. Skoˇcovsk´ y, Brno, 1998 3. Jelen, Milan: UNIX V - programov´ an´ı v syst´ emu. Grada, Praha 1993 4. Linux - Dokumentaˇ cn´ı projekt. Computer Press, 1998; http://www.cpress.cz/knihy/linux ˇ e 5. Herout, Pavel: Uˇ cebnice jazyka C. 2 d´ıly. Kopp, Cesk´ Budˇejovice, 2004 (4., respektive 2. pˇrepracované vydán´ı)

3

Ohlednˇ e Unixu doporuˇ cuji sp´ıˇ se literaturu v anglick´ em jazyce. 1. vˇsestrann´ y u ´ vod do UNIXu, ale dost struˇcn´ a; Skoˇcovsk´ y je autorem v´ıce ˇcesk´ ych knih o Unixu, ale dnes jsou jiˇz v´ıce nebo ménˇe zastaralé 2. pokroˇcilejˇs´ı pohled, ale pˇredpoklád´ a pˇredbˇeˇzné znalosti, m´ısty tˇeˇzko straviteln´ a 3. programován´ı v C pro UNIX System V, práce se soubory a s procesy, System V IPC, nepopisuje napˇr. vl´ akna a s´ıtˇe 4. o Linuxu bylo samozˇrejmˇe v ˇceˇstinˇe vydáno mnoho dalˇs´ıch knih 5. vynikaj´ıc´ı knihy o jazyce C

Literatura - design a principy syst´ emu 1. Uresh Vahalia: UNIX Internals: The New Frontiers. Prentice Hall; 1st edition, 1995 2. Bach, Maurice J.: The Design of the UNIX Operating System. Prentice Hall, 1986 3. McKusick, M. K., Neville-Neil, G. V.: The Design and Implementation of the FreeBSD Operating System. Addison-Wesley, 2004 4. McDougall, R.; Mauro, J.: Solaris Internals. Prentice Hall; 2nd edition, 2006. 5. Linux Documentation Project. http://tldp.org/

Tyto knihy se zab´ yvaj´ı stavbou Unixu, pouˇzit´ ymi algoritmy, strukturami apod., nejsou to kniho o programován´ı pod t´ımto systémem. 1. skvˇel´ a kniha, zab´ yv´ a se obecn´ ymi myˇslenkami UNIXu a porovnáv´ a systémy SVR4.2, 4.4BSD, Solarix 2.x a Mach. 12/2005 mˇelo vyj´ıt druhé, doplnˇené vydán´ı. Term´ın se vˇsak nˇekolikrát posunul, a nyn´ı (stav k 12/2007) toto druhé vydán´ı st´ ale jeˇstˇe nen´ı k dispozici a aktuáln´ı plánovan´ y term´ın je 03/2008. Tˇeˇzko ale ˇr´ıci, jestli k tomu jeˇstˇe nˇekdy v˚ ubec dojde. 2. klasická kniha o UNIXu, popis struktury a funkc´ı jádra UNIX System V Rel. 2, ˇca´steˇcnˇe i 3; pˇrestoˇze je to kniha z dneˇsn´ıho pohledu jiˇz zastaralá, lze ji poˇra´d jednoznaˇcnˇe doporuˇcit protoˇze to je jedna z nejlepˇs´ıch knih, co byla kdy o UNIXu naps´ ana. V roce 1993 vyˇsel ˇcesk´ y pˇreklad, Principy operaˇ cn´ıho syst´ emu UNIX, SAS.

4

3. popis struktury a funkc´ı j´ adra FreeBSD 5.2; tato kniha navazuje na klasickou knihu The Design and Implementation of the 4.4 BSD Operating System od stejného autora (resp. jeden ze ˇctyˇr, uveden´ y jako prvn´ı) 4. nejlepˇs´ı kniha o operaˇcn´ım systému Solaris. Obsahuje podrobné informace o tom, jak tento systém funguje vˇcetnˇe nejnovˇejˇs´ıch vˇec´ı z verze 10 jako jsou z´ ony, Crypto Framework, DTrace, Least Privilege model a dalˇs´ı. 5. domovsk´ a strana Linux dokumentaˇcn´ıho projektu

Literatura - programov´ an´ı 1. Stevens, W. R., Rago, S. A.: Advanced Programming in UNIX(r) Environment. Addison-Wesley, 2nd edition, 2005. 2. Rochkind, M. J.: Advanced UNIX Programming, Addison-Wesley; 2nd edition, 2004 3. Stevens, W. R., Fenner B., Rudoff, A. M.: UNIX Network Programming, Vol. 1 – The Sockets Networking API. Prentice Hall, 3rd edition, 2004 4. Butenhof, D. R.: Programming with POSIX Threads, Addison-Wesley; 1st edition, 1997 5. Unixové specifikace, viz http://www.unix.org 6. manu´ alové str´ anky (zejm. sekce 2, 3)

1. pravdˇepodobnˇe nen´ı lepˇs´ı knihy o programován´ı pod Unixem (neobsahuje s´ıt’ové programován´ı, to je v knize 3) 2. aktualizované vydán´ı dalˇs´ı z klasick´ ych knih o programován´ı pod Unixem. Obsahuje i s´ıt’ové programován´ı a aˇc samozˇrejmˇe nen´ı tak podrobn´ a jako spojen´ı knih 1 a 3, m˚ uˇze to b´ yt nˇekdy naopak v´ yhodou. Tuto knihu jednoznaˇcnˇe doporuˇcuji, pokud chcete nˇeco kupovat. 3. klasická kniha o s´ıt’ovém programován´ı, jedna z nejlepˇs´ıch k tomuto tématu; existuje i druh´ y d´ıl UNIX Network Programming, Volume 2: Interprocess Communications, kter´ a se zab´ yv´ a komunikac´ı mezi procesy (roury, POSIX IPC, System V IPC, synchronizace vl´ aken, RPC). 4. velmi dobr´ a a podrobn´ a kniha o programován´ı s vl´ akny 5. domovsk´ a str´ anka posledn´ıch specifikac´ı rozhran´ı UNIXu 6. podrobn´ y popis jednotliv´ ych funkc´ı (v Linuxu bˇeˇznˇe ne zcela dostaˇcuj´ıc´ı; manu´ alové str´ anky v tomto systému jsou ˇcasto horˇs´ı kvality neˇz u systém˚ u ostatn´ıch)

5

. . . a spousta dalˇs´ıch knih, online dokumentac´ı a internetov´ ych zdroj˚ u, posledn´ı dobou vych´ az´ı pomˇernˇe hodnˇe knih o Linuxu, zamˇeˇren´ ych na pouˇz´ıv´ an´ı i programován´ı . . . jdˇete na http://www.amazon.com/ a zadejte kl´ıˇcové slovo “unix”. Pokud byste z Amazonu nˇeco kupovali, dejte pozor na to, ˇze mnoho knih má aktualizovan´ a vydán´ı i po nˇekolika málo letech, nˇekdy i levnˇejˇs´ı neˇz ta p˚ uvodn´ı, kter´ a jsou vˇsak st´ ale na skladu a v on-line nab´ıdce; tak at’ zbyteˇcnˇe nekoup´ıte starˇs´ı vydán´ı neˇz to aktuáln´ı. Nav´ıc se vyplat´ı zkontrolovat i u pˇr´ısluˇsného vydavatelstv´ı, ˇze nen´ı v brzké dobˇe napl´ anováno vydán´ı nové – tato informace nˇekdy na Amazonu je, nˇekdy ne. . . . na Amazonu se m˚ uˇze vyplatit nakoupit knihy z druhé ruky, protoˇze jsou ˇcasto v´ yraznˇe levnˇejˇs´ı neˇz knihy nové. Problém je, ˇze vˇetˇsinou nen´ı moˇzné je poslat ˇ ale mus´ı vám je nˇekdo pˇrivézt. pˇr´ımo do CR,

Literatura - historie UNIXu • Peter Salus: A Quarter Century of UNIX, Addison-Wesley; 1st edition (1994) • Libes D., Ressler, S.: Life With Unix: A Guide for Everyone, Prentice Hall (1989) • Open Sources: Voices from the Open Source Revolution, kapitola Twenty Years of Berkeley Unix From AT&T-Owned to Freely Redistributable; O’Reilly (1999); on-line na webu . . . mnoho materi´ al˚ u na webu; ˇcasto vˇsak obsahuj´ıc´ı ne zcela pˇresné informace

• kapitola o BSD Unixu napsaná Marshallem Kirk McKusickem je opravdu v´ yborn´ a

6

(Pre)historie UNIXu • 1925 – Bell Telephone Laboratories – v´ yzkum v komunikac´ıch (napˇr. 1947: transistor) v r´ amci AT&T • 1965 – BTL s General Electric a MIT v´ yvoj OS Multics (MULTIplexed Information and Computing System) • 1969 – Bell Labs opouˇst´ı projekt, Ken Thompson p´ıˇse assembler, z´ akladn´ı OS a systém soubor˚ u pro PDP-7 • 1970 – Multi-cs ⇒ Uni-cs ⇒ Uni-x • 1971 – UNIX V1, a portován na PDP-11 • prosinec 1971 – prvn´ı edice UNIX Programmer’s Manual

• AT&T = American Telephone and Telegraph Company • po odchodu BTL z projektu Multics prodala GE svoji poˇc´ıtaˇcovou divizi firmˇe Honeywell vˇcetnˇe projektu Multics, kter´ y se pak pod jej´ı patronac´ı d´ ale vyv´ıjel (virtu´ aln´ı pamˇet’, multiprocesory, . . . ). Posledn´ı instalace Multicsu fungovala na kanadském Ministerstvu obrany (Canadian Department of National Defence) a systém byl napˇr´ıklad jeˇstˇe aktivnˇe pouˇz´ıv´ an pro vojenské operace bˇehem války v Perském z´ alivu. Definitivn´ı shutdown byl proveden 31. ˇr´ıjna 2000. V´ıce informac´ı na http://www.multicians.org. • pˇred poˇca´tkem práce na v´ yvojovém prostˇred´ı pro PDP-7 napsal Thompson program Space Travel, kter´ y byl vyvinut na jiném prostˇred´ı (Honeywell 635) a na p´ asce pˇrenesen na PDP-7. • celkem bylo 10 edic´ı tohoto manu´ alu, koresponduj´ıc´ı deseti verz´ım UNIXu vznikl´ ych v BTL. • UNIX V1 nemˇel pipe() !!! • za povˇsimnut´ı stoj´ı, ˇze UNIX je zhruba o 10 let starˇs´ı neˇz DOS • systém Multics mˇel 9 hlavn´ıch c´ıl˚ u, jak pops´ ano v ˇcl´ anku Introduction and Overview of the Multics System z roku 1965. Za nejzaj´ımavˇejˇs´ı c´ıl bych povaˇzoval poˇzadavek na nepˇreruˇsovan´ y bˇeh systému. • Multics byl napsan´ y v jazyce PL/I (Programming Language #1), tedy dˇr´ıve neˇz byl UNIX pˇrepsan´ y do C ! • Multicsu byl v roce 1980 udˇelen jako prvn´ımu systému level B2. Po nˇekolik let to byl jedin´ y systém s t´ımto bezpeˇcnost´ım levelem.

7

• GE byla zaloˇzena v roce 1892 slouˇcen´ım dvou spoleˇcnost´ı, z nichˇz jedna byla Edison General Electric Company zaloˇzená roku 1879 Thomasem Alvou Edisonem (vyn´ alezce ˇza´rovky, filmové kamery, . . . ); v souˇcasné dobˇe jej´ı dceˇrinné spoleˇcnosti pokr´ yvaj´ı mnoho oblast´ı, vˇcetnˇe dod´ avky jednoho ze dvou typ˚ u motor˚ u pro Airbus 380 nebo bankovnictv´ı. • PDP = Programmed Data Processor. Prvn´ı typ, PDP-1, se prod´ avala za $120.000 v dobˇe, kdy se jiné poˇc´ıtaˇce prod´ avaly za ceny pˇres mili´ on. To byla také strategie fy DEC - pojem computer tehdy znamenal drahou vˇec, potˇrebuj´ıc´ı s´ al a t´ ym lid´ı, kter´ y se o to vˇsechno bude starat. Proto DEC své maˇsiny nenaz´ yval poˇc´ıtaˇci, ale pravˇe slovem PDPs. • PDP-11 je legend´ arn´ı maˇsina od firmy DEC, postupnˇe vznikaly verze PDP1 az PDP-16, kromˇe PDP-2, PDP-13. Existuj´ı PDP-11 systémy, které jeˇstˇe dnes bˇeˇz´ı, a také firmy, které pro nˇe vyr´ abˇej´ı n´ ahradn´ı d´ıly.

Historie UNIXu, pokraˇ cov´ an´ı • u ´ nor 1973 – UNIX V3 obsahoval cc pˇrekladaˇc (jazyk C byl vytvoˇren Dennisem Ritchiem pro potˇreby UNIXu) • ˇr´ıjen 1973 – UNIX byl pˇredstaven veˇrejnosti ˇclánkem The UNIX Timesharing System na konferenci ACM • listopad 1973 – UNIX V4 pˇ reps´ an do jazyka C • 1975 – UNIX V6 byl prvn´ı verz´ı UNIXu bˇeˇznˇe k dost´ an´ı mimo BTL • 1979 – UNIX V7, pro mnohé “the last true UNIX”, obsahoval uucp, Bourne shell; velikost kernelu byla pouze 40KB !!! • 1979 – UNIX V7 portován na 32-bitov´ y VAX-11 • 1980 – Microsoft pˇr´ıch´ az´ı s XENIXem, kter´ y je zaloˇzen´ y na UNIXu V7

• ACM = Association for Computing Machinery, zaloˇzena 1947. • akt pˇ reps´ an´ı UNIXu do jazyka C byl moˇ zn´ a nejv´ yznamnˇ ejˇ s´ım momentem v historii tohoto syst´ emu ⇒ UNIX mohl b´ yt mnohem jednoduˇseji portován na jiné architektury • na verzi 6 je zaloˇzena legend´ arn´ı kniha A commentary on the Unix Operating System, jej´ıˇz autorem je John Lions. • Microsoft neprod´ aval XENIX pˇr´ımo, ale licencoval ho OEM v´ yrobc˚ um (Original Equipment Manufacturer) jako byl Intel, SCO a jin´ı. Jiné firmy pak XENIX d´ ale portovaly na 286 (Intel) a 386 (SCO, 1987). Na webu je moˇzné naj´ıt zaj´ımavé informace popisuj´ıc´ı tuto dobu a tehdy kladn´ y vztah Microsoftu k UNIXu. 8

• pokud vás v´ıce zaj´ım´ a historie unixu, pod´ıvejte se na wikipedii na heslo “unix” a skrz odkazy máte na dlouho co ˇc´ıst.

Divergence UNIXu • pol. 70. let – uvolˇ nován´ı UNIXu na univerzity: pˇredevˇs´ım University of California v Berkeley • 1979 – z UNIX/32V (zm´ınˇen´ y port na VAX) poskytnutého do Berkeley se vyv´ıj´ı BSD Unix (Berkeley Software Distribution) verze 3.0; posledn´ı verze 4.4 v roce 1993 • 1982 AT&T, vlastn´ık BTL, m˚ uˇze vstoupit na trh poˇc´ıtaˇc˚ u (zak´ azáno od roku 1956) a pˇr´ıch´ az´ı s verz´ı System III (1982) aˇz V.4 (1988) – tzv. SVR4 • vznikaj´ı UNIX International, OSF (Open Software Foundation), X/OPEN, . . . • 1991 – Linus Torvalds zahájil v´ yvoj OS Linux, verze jádra 1.0 byla dokonˇcena v r. 1994

• UNIX je univerz´ aln´ı operaˇcn´ı systém funguj´ıc´ı na ˇsiroké ˇsk´ ale poˇc´ıtaˇc˚ u od embedded a handheld systém˚ u (Linux), pˇres osobn´ı poˇc´ıtaˇce aˇz po velké servery a superpoˇc´ıtaˇce. • UNIX V3 = UNIX verze 3, UNIX V.4 = system 5 release 4 atd., tj. UNIX V3 != SVR3. • UNIX System III tedy nen´ı UNIX V3; v této dobˇe (pozdn´ı 70. léta) bylo v BTL nˇekolik skupin, které pˇr´ısp´ıvaly do v´ yvoje UNIXu. Vx verze byly vyv´ıjeny v r´ amci Computer Research Group, dalˇs´ı skupiny byly Unix System Group (USG), Programmer’s WorkBench (PWB). Dalˇs´ı vˇetv´ı UNIXu byl Columbus UNIX téˇz v r´ amci BT. Na tˇechto r˚ uzn´ ych verz´ıch je právˇe zaloˇzena verze System III. Z´ ajemce o v´ıce informac´ı odkazuji na web. • UNIX se rozˇstˇepil na dvˇe hlavn´ı vˇetve: AT&T a BSD, jednotliv´ı v´ yrobci pˇrich´ azeli s vlastn´ımi modifikacemi. Jednotliv´ e klony od sebe navz´ ajem pˇ reb´ıraly vlastnosti. • Berkeley univerzita z´ıskala jako jedna z prvn´ıch licenci UNIXu v roce 1974. Bˇehem nˇekolika let studenti (jedn´ım z nich byl Bill Joy, pozdˇejˇs´ı zakladatel firmy Sun Microsystems a autor C-shellu) vytvoˇrili SW bal´ık Berkeley Software Distribution (BSD) a prod´ avali ho v roce 1978 za $50. Tyto poˇca´teˇcn´ı verze BSD obsahovaly pouze SW a utility (prvn´ı verze: Pascal pˇrekladaˇc, editor ex ), ne systém ani ˇza´dné jeho zmˇeny. To pˇriˇslo aˇz s verz´ı 3BSD. verze 4BSD vzniká roku 1980 jiˇz jako projekt financovan´ y agenturou DARPA a veden´ y Billem Joyem. Trp´ı problémy spojen´ ymi s nedostateˇcn´ ym v´ ykonem a vzniká tak vyladˇen´ y systém 4.1BSD dod´ avan´ y od roku 1981. 9

• 4.1BSD mˇelo b´ yt p˚ uvodnˇe 5BSD, ale poté, co AT&T vzneslo n´ amitky, ˇze by si z´ akazn´ıci mohli plést 5BSD se systémem System V, pˇreˇslo BSD na ˇc´ıslován´ı 4.xBSD. Bˇeˇznou vˇec´ı bylo, ˇze neˇz psát vlastn´ı kód, v´ yvojáˇri z Berkeley se radˇeji nejdˇr´ıve pod´ıvali kolem, co je jiˇz hotové. Tak BSD napˇr´ıklad pˇrevzalo virtu´ aln´ı pamˇet’ z Machu a nebo NFS-compatibiln´ı kód vyvinut´ y na jedné kanadské univerzitˇe. • v´ yrobci hardware dod´ avali varianty UNIXu pro své poˇc´ıtaˇce a komercializace tak jeˇstˇe zhorˇsila situaci co t´ yˇce diverzifikace UNIXu • v 80-t´ ych letech se proto zaˇcaly objevovat snahy o standardizaci. Standard ˇr´ık´ a, jak má vypadat systém navenek (pro uˇzivatele, program´ atora a spr´ avce), nezab´ yv´ a se implementac´ı. C´ılem je pˇrenositelnost aplikac´ı i uˇzivatel˚ u. vˇsechny systémy totiˇz z d´ alky vypadaly jako UNIX, ale z bl´ızka se liˇsily v mnoha d˚ uleˇzit´ ych vlastnostech. System V a BSD se napˇr. liˇsily v pouˇzitém filesystému, s´ıt’ové architektuˇre i v architektuˇre virtu´ aln´ı pamˇeti. • kdyˇz v roce 1987 firmy AT&T a Sun (jehoˇz tehdejˇs´ı SunOS byl zaloˇzen´ y na BSD) spojily svoje u ´ sil´ı na vyvinut´ı jednoho systému, kter´ y by obsahoval to nejlepˇs´ı z obou vˇetv´ı, kromˇe nadˇsen´ ych reakc´ı to vzbudilo i strach u mnoha dalˇs´ıch v´ yrobc˚ u unixov´ ych systém˚ u, kteˇr´ı se b´ ali, ˇze by to pro obˇe firmy znamenalo obrovskou komerˇcn´ı v´ yhodu. Vznik´ a proto Open Software Foundation (nezamˇen ˇ ovat za FSF), a zakl´ adaj´ıc´ımi ˇcleny byly mimo jiné firmy Hewlett-Packard, IBM a Digital. Z toho vzeˇsl´ y systém OSF/1 ale nebyl pˇr´ıliˇs u ´ spˇeˇsn´ y, a dod´ aval ho pouze Digital, kter´ y ho pˇrejmenoval na Digital UNIX. Zaj´ımavost´ı je, ˇze systém je postaven´ y na mikrojádru Mach. Po akvizici Digitalu Compaqem byl systém pˇrejmenován na Tru64 a s t´ımto jménem je d´ ale podporován firmou Hewlett-Packard, kter´ a se v roce 2002 s Compaqem spojila. Mezit´ım firmy AT&T a Sun kontrovaly zaloˇzen´ım UNIX International. Toto obdob´ı pˇrelomu 80-t´ ych a 90-t´ ych let se naz´ yv´ a Unix Wars – boj o to, co bude “standardn´ım unixem”. • OSF a UI se staly velk´ ymi rivaly, ale velmi rychle se stˇretly s neˇcekan´ ym protivn´ıkem - s firmou Microsoft. • (1992) 386BSD zaloˇzené na Networking Release 2 ; Bill Jolitz vytvoˇril 6 chybˇej´ıc´ıch soubor˚ u a dal tak dohromady funkˇcn´ı BSD systém pro i386. Tento systém se stal z´ akladem systém˚ u NetBSD a FreeBSD (a dalˇs´ıch, z tˇechto dvou systém˚ u vych´ azej´ıc´ıch). • (1995) 4.4BSD-Lite Release 2, po které n´ asleduje rozpuˇstˇen´ı CSRG, kter´ a skoro 20 let pilotovala v´ yvoj BSD vˇetve. V´ıce jiˇz zm´ınˇen´ a kapitola o BSD Unixu.

10

Souˇ casn´ e UNIXy Hlavn´ı komerˇcn´ı unixové systémy: • Sun Microsystems: SunOS (nen´ı jiˇz d´ ale vyv´ıjen), Solaris • SGI: IRIX • IBM: AIX • HP: HP-UX • HP (pˇredt´ım Compaq): Tru64 UNIX • SCO: SCO Unix • Novell: UNIXware Open source: • FreeBSD, NetBSD, OpenBSD, OpenSolaris • Linux distribuce

• kdyˇz jsem cca v roce 1998 projel nmapem vˇsechny DNS root servery, abych zjistil na kter´ ych systémech bˇeˇz´ı, bylo 80% z nich na SunOS/Solaris. IRIX je zase systém, kter´ y po mnoho let ovl´ adal televizn´ı/filmov´ y pr˚ umysl (napˇr. Pixar studio kde na IRIXu vznikly filmy jako A Bug’s Life, Toy Story a dalˇs´ı). A na AIX napˇr´ıklad bˇeˇzel Blue Deep, paraleln´ı superpoˇc´ıtaˇc, kter´ y v roce 1997 porazil v ˇsesti fascinuj´ıc´ıch z´ apasech 3.5 ku 2.5 u ´ˇraduj´ıc´ıho velmistra ˇsachu Garriho Kasparova. Jin´ ymi slovy – kaˇzd´ y systém má svoje u ´ spˇechy. • jak jiˇz bylo zm´ınˇeno, Tru64 UNIX vych´ az´ı z OSF/1 firmy DEC. Ta pˇredt´ım dod´ avala Ultrix, zaloˇzen´ y na BSD unixu. • OpenSolaris je projekt vznikl´ y v ˇcervnu 2005 a je zaloˇzen na podmnoˇzinˇe zdrojov´ ych text˚ u v´ yvojové verze Solarisu (kernel, knihovny, pˇr´ıkazy) k datu uveden´ı. Ofici´ aln´ı distribuce zaloˇzená na OpenSolarisu se jmenuje Solarix Express. Distribuce vzeˇslé z komunity jsou napˇr´ıklad LiveCD BeleniX, SchilliX a Nexenta. • pozor na to, ˇze Linux je pouze jádro, ne systém, na rozd´ıl tˇreba od FreeBSD. OpenSolaris je nˇeco mezi t´ım, jádro + drivery, z´ akladn´ı pˇr´ıkazy a knihovny, a v bin´ arn´ı podobˇe to má nˇeco pˇres 100MB. V obou pˇr´ıpadech je tedy spr´ avné pouˇz´ıvat spojen´ı “Linux (OpenSolaris) distribuce”, kdyˇz se bav´ıme o celém systému. • kaˇzd´ a komerˇcn´ı varianta vych´ azela z jednoho ze dvou hlavn´ıch systém˚ u – UNIX V nebo BSD, a pˇrid´ avala si své vlastnosti • vzniká velk´ y poˇcet r˚ uzn´ ych standard˚ u (viz n´ asleduj´ıc´ı strana), skoro jako poˇcet r˚ uzn´ ych verz´ı UNIX˚ u. Nakonec se vˇetˇsina v´ yrobc˚ u shodla na nˇekolika z´ akladn´ıch standardech.

11

• graf zn´ azorˇ nuj´ıc´ı historii Unixu a z´ avislosti mezi systémy na 19-ti A4 listech ve formátu PS/PDF je k nalezen´ı na http://www.levenez.com/unix

12

Standardy UNIXu • SVID (System V Interface Definition) – ,,fialov´ a kniha”, kterou AT&T vydala poprvé v roce 1985 – dnes ve verzi SVID3 (odpov´ıd´ a SVR4)

• POSIX (Portable Operating System based on UNIX) – série standard˚ u organizace IEEE znaˇcen´ a P1003.xx, postupnˇe je pˇrej´ım´ a vrcholov´ y nadn´ arodn´ı org´ an ISO

• XPG (X/Open Portability Guide) – doporuˇcen´ı konsorcia X/Open, které bylo zaloˇzeno v r. 1984 pˇredn´ımi v´ yrobci platforem typu UNIX

• Single UNIX Specification – standard organizace The Open Group, vzniklé v roce 1996 slouˇcen´ım X/Open a OSF – dnes Version 3 (UNIX 03), pˇredchoz´ı Version 2 (UNIX 98) – splnˇen´ı je nutnou podm´ınkou pro uˇzit´ı obchodn´ıho n´ azvu UNIX

• AT&T dovolila v´ yrobc˚ um naz´ yvat svoji komerˇcn´ı UNIX variantu “System V” pouze pokud splˇ novala podm´ınky standardu SVID. AT&T také publikovala System V Verification Suite (SVVS), které ovˇeˇrilo, zda dan´ y systém odpov´ıdá standardu. • POSIX (Portable Operating System Interface) je standardizaˇcn´ı snaha organizace IEEE (Institute of Electrical and Electronics Engineers). Prvn´ım dokumentem je IEEE Std POSIX1003.1-1988, dˇr´ıve oznaˇcovan´ y prostˇe jako POSIX, dnes zn´ am´ y sp´ıˇse jako POSIX.1, protoˇze POSIXem se nyn´ı m´ın´ı sada vz´ ajemnˇe souvisej´ıc´ıch standard˚ u. POSIX.1 obsahuje programovac´ı API, tj. práce s procesy, signály, soubory, ˇcasovaˇci atd. S mal´ ymi zmˇenami byl pˇrevzat organizac´ı ISO, a oznaˇcovan´ y jako POSIX1990. Tento standard byl s´ am o sobˇe velk´ yu ´ spˇech, ale st´ ale jeˇstˇe nespojoval t´ abory System V a BSD, protoˇze v sobˇe napˇr´ıklad nezahrnoval BSD sockety nebo IPC (semafory, zpr´ avy, sd´ılená pamˇet’) ze System V. Oznaˇcen´ı POSIX vymyslel Richard Stallman, tedy ˇclovˇek, kter´ y v roce 1983 zaloˇzil GNU projekt. Souˇca´st´ı standardu je i “POSIX conformance test suite (PCTS)”, kter´ y je volnˇe k dispozici. • SUSV3 je spoleˇcn´ y standard The Open Group, IEEE (Std. 1003.1, 2003 Edition) a ISO (ISO/IEC 9945-2003). • dnes je asi nejd˚ uleˇzitˇejˇs´ı Single UNIX Specification, které se budeme drˇzet i my. Tato norma je podm´ınkou pro uˇzit´ı n´ azvu UNIX, Je postavena na b´ azi POSIXu. Popis datov´ ych struktur a algoritm˚ u jádra v tomto materi´ alu bude vˇetˇsinou vych´ azet ze System V Rel. 4.

13

Jazyk C • témˇeˇr cel´ y UNIX je napsan´ y v C, pouze nejniˇzˇs´ı strojovˇe z´ avislá ˇca´st v assembleru ⇒ pomˇernˇe snadn´ a pˇrenositelnost • navrhl Dennis Ritchie z Bell Laboratories v roce 1972. • n´ asledn´ık jazyka B od Kena Thomsona z Bell Laboratories. • vytvoˇren jako prostˇredek pro pˇrenos OS UNIX na jiné poˇc´ıtaˇce – siln´ a vazba na UNIX. • varianty jazyka: – p˚ uvodn´ı K&R C – standard ANSI/ISO C • u ´ spˇ ech jazyka C daleko pˇ res´ ahl u ´ spˇ ech samotn´ eho UNIXu

• CPL ⇒ BCPL ⇒ B (Thompson, interpret) ⇒ C • K&R C – jazyk C tak, jak je popsan´ y v klasické knize Brian W. Kernighan, Dennis M. Ritchie: The C Programming Language (Prentice-Hall, 1978). • v roce 1983 ANSI (American National Standards Institute) zformoval v´ ybor pro vytvoˇren´ı C standardu. Po dlouhém a pracném procesu byl v roce 1989 standard koneˇcnˇe hotov, a je zn´ am´ y nejˇcastˇeji jako “ANSI C”, pˇr´ıpadnˇe jako C89 (napˇr´ıklad pˇrekladaˇc pro tuto normu se v Sun Studiu jmenuje c89, jelikoˇz i to samotné jméno programu mus´ı b´ yt podle normy). Druhé vydán´ı K&R knihy (1988) je jiˇz upravené právˇe pro nadch´ azej´ıc´ı ANSI C. V roce 1990 bylo ANSI C adoptováno organizac´ı ISO jako ISO/IEC 9899:1990; tento C standard tak m˚ uˇze b´ yt nˇekdy oznaˇcován i jako C90. • se C standardem se pak nˇejakou dobu neh´ ybalo, aˇz na konci 90-t´ ych let proˇsel dalˇs´ı reviz´ı v r´ amci ISO a vzniká ISO 9899:1999, ˇcastˇeji oznaˇcovan´ y jako C99. V roce 2000 pak naopak tento standard pˇrevzal ANSI. • rozd´ıly mezi C89 a C99 jsou mimo jiné zahrnut´ı inline funkc´ı, definic´ı promˇenn´ ych napˇr´ıklad i do for konstrukce, jednoˇra´dkov´ ych koment´ aˇr˚ u pomoc´ı //, nov´ ych funkc´ı jako snprintf() apod.

14

Form´ aty dat • poˇrad´ı bajt˚ u – z´ avis´ı na architektuˇre poˇc´ıtaˇce –

–

big endian: 0x11223344 =

11

22

33

44

addr +

0

1

2

3

little endian: 0x11223344 =

44

33

22

11

addr +

0

1

2

3

• ˇra´dky textov´ ych soubor˚ u konˇc´ı v UNIXu znakem LF (nikoliv CRLF). Vol´ an´ı putc(’\n’) tedy p´ıˇse pouze jeden znak. • big endian – SPARC, MIPS, s´ıt’ové poˇrad´ı bajt˚ u • little endian – Intel

• velk´ y pozor na v´ ystupy program˚ u typu hexdump, které defaultnˇe vypisuj´ı soubor ve 2-bajtov´ ych ˇc´ıslech, coˇz sv´ ad´ı vidˇet soubor jinak, neˇz jak je opravdu zapsan´ y na disku; viz pˇr´ıklad (i386, FreeBSD): $ echo -n 1234 > test $ hexdump test 0000000 3231 3433 0000004 je samozˇrejmˇe moˇzné pouˇz´ıt jin´ y formát v´ ystupu: $ hexdump -C test 00000000 31 32 33 34 00000004

|1234|

• UNIX norma pˇr´ıkaz hexdump nem´ a, ale definuje od (octal dump), takˇze zde je jeho hexdumpu ekvivalentn´ı formát v´ ypisu na SPARCu (Solaris); vˇsimnˇete si zmˇeny oproti v´ ypisu pod FreeBSD! $ od -tx2 test 0000000 3132 3334 0000004

15

Deklarace a definice funkce • K&R – deklarace n´ avratov´ y_typ indentifik´ ator(); – definice n´ avratov´ y_typ indentifik´ ator(par [,par...]); typ par;... { /* tˇ elo funkce */ }

• ANSI – deklarace n´ avratov´ y_typ indentifik´ ator(typ par [,typ par...]); – definice n´ avratov´ y_typ indentifik´ ator(typ par [,typ par...]); { /* tˇ elo funkce */ }

• pouˇz´ıvejte pouze novˇejˇs´ı (ANSI) typ deklarac´ı a vˇzdy deklarujte prototypy funkc´ı, tj. inkludujte hlaviˇckové soubory. V´ yjimkou m˚ uˇze asi jen to, pokud budete pracovat s kódem, kter´ y byl napsan´ y podle K&R. • r˚ uzn´ ymi z´ apisy deklarac´ı se dost´ av´ ame rovnou i k r˚ uzn´ ym styl˚ um psan´ı zdrojov´ ych text˚ u. Nˇekteré systémy to pˇr´ıliˇs neˇreˇs´ı (Linux), jiné systémy maj´ı velmi striktn´ı pravidla pro psan´ı zdrojov´ ych text˚ u (napˇr. Solaris, viz on-line C Style and Coding Standards for SunOS ). Skoro kaˇzd´ y UNIXov´ y systém má program indent(1), kter´ y vám pomoc´ı pˇrep´ınaˇc˚ u pˇreformátuje jak´ ykoli C zdrojov´ y text do poˇzadovaného v´ ystupu.

16

C style • vˇec zd´ anlivˇe podˇradn´ a, pˇritom extrémnˇe d˚ uleˇzit´ a–u ´ prava zdrojov´ ych kód˚ u programu • mnoho zp˚ usob˚ u jak ano: int main(void) { char c; int i = 0; printf("%d\n", i); return (0); }

• u C stylu je nejd˚ uleˇzitˇejˇs´ı to, aby byl konzistentn´ı. Pokud skupina program´ ator˚ u pracuje na jednom projektu, nen´ı zas aˇz tak d˚ uleˇzité, na jakém stylu se dohodnout (pokud je alespoˇ n trochu rozumn´ y), ale aby se dohodli. Jednotn´ y a dobˇre zvolen´ y styl ˇsetˇr´ı ˇcas a brán´ı zbyteˇcn´ ym chybám.

17

C style (cont.) • mnoho zp˚ usob˚ u jak NE (tzv. assembler styl): int main(void) { int i = 0; char c; printf("%d\n", i); return (0); } • nebo (schizofrenn´ı styl): int main(void) { int i = 0; char c; if (1) printf("%d\n", i);i=2; return (0); }

• pamatujte na to, ˇze dobr´ y styl zdrojov´ ych kód˚ u je i vizitkou program´ atora. Kdyˇz se v r´ amci pˇrij´ımac´ıch pohovor˚ u odevzdávaj´ı i ukázkové kódy, tak hlavn´ı ´ d˚ uvod nen´ı ten, aby se zjistilo, ˇze vám dan´ y program funguje. . . Uprava samotného zdrojového textu je jedn´ım z kriteri´ı, protoˇze to pˇrenesenˇe m˚ uˇze svˇedˇcit i o dalˇs´ıch skuteˇcnostech – nˇekdo napˇr. bude odhadovat, ˇze pokud p´ıˇsete neˇcist´ y a neupraven´ y kód, tak jste moˇzn´ a jeˇstˇe nepracovali na nˇeˇcem opravdu sloˇzitém ˇci nˇeˇcem zahrnuj´ıc´ım spolupráci s v´ıce program´ atory, protoˇze v tom pˇr´ıpadˇe je rozumnˇe ˇcist´ y kód jednou z podm´ınek u ´ spˇechu a jednou ze zkuˇsenost´ı, které z takové spolupráce vych´ azej´ı. Toto je samozˇrejmˇe zˇca´sti subjektivn´ı n´ azor, ale ˇcist´ ym kódem nic nezkaz´ıte, minimálnˇe nekaz´ıte oˇci sv´ ym cviˇc´ıc´ım.

18

Utility cc, c99∗ , gcc† †

pˇrekladaˇc C

CC, g++

pˇrekladaˇc C++

ld

spojovac´ı program (linker)

ldd

pro zjistˇen´ı z´ avislost´ı dynamického objektu

cxref ∗

kˇr´ıˇzové odkazy ve zdrojov´ ych textech v C

∗

sccs , rcs,cvs make

∗

spr´ ava verz´ı zdrojového kódu ˇr´ızen´ı pˇrekladu podle z´ avislost´ı

∗

ar

spr´ ava knihoven objektov´ ych modul˚ u

dbx, gdb†

debuggery

prof, gprof † ∗

UNIX 03

profilery †

GNU

UNIX 03 • standardn´ı pˇr´ıkaz vol´ an´ı kompil´ atoru a linkeru C je c99 (podle ISO normy pro C z roku 1999) • cb (C program beautifier) nen´ı • pro spr´ avu verz´ı je sccs • debuggery a profilery nejsou

19

Konvence pro jm´ ena soubor˚ u *.c

jména zdrojov´ ych soubor˚ u program˚ uvC

*.cc

jména zdrojov´ ych soubor˚ u program˚ u v C++

*.h

jména hlaviˇckov´ ych soubor˚ u (header˚ u)

*.o

pˇreloˇzené moduly (object files)

a.out

jméno spustitelného souboru (v´ ysledek u ´ spˇeˇsné kompilace)

/usr/

koˇren stromu systémov´ ych header˚ u

/usr/lib/lib*.a

statické knihovny objektov´ ych modul˚ u

/usr/lib/lib*.so

um´ıstˇen´ı dynamick´ ych sd´ılen´ ych knihoven objektov´ ych modul˚ u

statick´ e knihovny – pˇri linkován´ı se stanou souˇca´st´ı v´ ysledného spustitelného programu. Dnes se uˇz moc nepouˇz´ıv´ a. sd´ılen´ e knihovny – program obsahuje pouze odkaz na knihovnu, pˇri spuˇstˇen´ı programu se potˇrebné knihovny naˇctou do pamˇeti ze soubor˚ u *.so a pˇrilinkuj´ı. • dnes se vˇetˇsinou pouˇz´ıvaj´ı sd´ılené knihovny, protoˇze nezab´ıraj´ı tolik diskového prostoru (knihovna je na disku jednou, nen´ı souˇca´st´ı kaˇzdého spustitelného souboru) a snadnˇeji se upgraduj´ı (staˇc´ı instalovat novou verzi knihovny, nen´ı tˇreba pˇrelinkovat programy). Posledn´ı verze Solarisu uˇz napˇr´ıklad v˚ ubec neobsahuje libc.a, d´ıky ˇcemuˇz jiˇz program´ ator nem˚ uˇze vytvoˇrit statickou bin´ arku, aniˇz by nemˇel dostateˇcné znalosti systému. • nˇekdy se bez statick´ ych knihoven neobejdeme. V nˇekter´ ych situac´ıch nen´ı moˇzné pouˇz´ıt knihovny dynamické, spustitelné soubory jsou takzvané standalone binaries a pouˇzit´ı naleznou napˇr´ıklad pˇri bootován´ı operaˇcn´ıho systému.

20

Princip pˇ rekladu

util.c msg() { puts(); }

systémová knihovna

program a.out

main msg ??

main msg

util.o msg puts ??

linker

main() { msg(); }

objektové moduly main.o

pˇrekladaˇc

zdrojové moduly main.c

msg puts

puts

puts

• u sloˇzitˇejˇs´ıch program˚ u b´ yv´ a zvykem rozdˇelit zdrojov´ y text programu do nˇekolika modul˚ u, které obsahuj´ı pˇr´ıbuzné funkce a tyto moduly se pak mohou pˇrekl´ adat zvláˇst’ (dokonce kaˇzd´ y modul m˚ uˇze b´ yt v jiném jazyce a pˇrekl´ ad´ an jin´ ym pˇrekladaˇcem). V´ yhodou je jednak urychlen´ı pˇrekladu (pˇrekl´ adaj´ı se vˇzdy jen moduly zmˇenˇené od posledn´ıho pˇrekladu) a jednak flexibilita (nˇekteré moduly se mohou pouˇz´ıvat v r˚ uzn´ ych programech). Pro ˇr´ızen´ı pˇrekladu se obvykle pouˇz´ıv´ a utilita make. • pˇrekladaˇc jednotlivé zdrojové moduly pˇreloˇz´ı do tvaru tzv. objektových modul˚ u, jeˇz obsahuj´ı kód programu (vˇcetnˇe volán´ı lokáln´ıch funkc´ı), ale nam´ısto vol´ an´ı extern´ıch funkc´ı obsahuj´ı jen tabulku jejich jmen. • po f´ azi pˇrekladu nastupuje spojovac´ı program (téˇz linker editor nebo loader ), kter´ y zkompletuje v´ ysledn´ y program vˇcetnˇe vyˇreˇsen´ı extern´ıch odkaz˚ u mezi moduly a systémov´ ymi knihovnami resp. mezi moduly navz´ ajem. • pouˇzité statické knihovny jsou zkop´ırovány do spustitelného souboru. Na sd´ılené knihovny jsou ve spustitelném souboru pouze odkazy a linkuje je runtime linker pˇri kaˇzdém spuˇstˇen´ı programu. V´ıce viz dynamick´ y linker na stranˇe 31. • pomoc´ı parametr˚ u linkeru lze urˇcit, zda se budou pouˇz´ıvat statické nebo dynamické knihovny. Zdrojov´ y kód je v obou pˇr´ıpadech stejn´ y. Existuje i mechanismus (dlopen(), dlsym(). . . ), pomoc´ı kterého se za bˇehu programu vybere sd´ılená knihovna a daj´ı se volat jej´ı funkce. T´ımto zp˚ usobem m˚ uˇzete také zjistit, zda v systému je pˇr´ıtomna pˇr´ısluˇsná funkcionalita a pokud ne, zachovat se podle toho.

21

Pˇ reklad jednoho modulu (preprocesor)

/usr/include/stdio.h int puts(char *s);

main.i int puts(char *s); preprocesor

main.c #include <stdio.h> #include "mydef.h" main() { puts(MSG); }

mydef.h #define MSG "Ahoj" extern int var a;

extern int var a; main() { puts("Ahoj"); }

• preprocesor provád´ı expanzi maker, ˇcten´ı vloˇzen´ ych () soubor˚ u a vynech´ av´ a koment´ aˇre. • v´ ystup preprocesoru lze z´ıskat pomoc´ı cc -E pˇr´ıpadnˇe pˇr´ımo zavolán´ım cpp, nemus´ı to b´ yt ale vˇzdz totéˇz protoˇze nˇekteré pˇrekladaˇce maj´ı preprocesor integrován v sobˇe. Preprocesor m˚ uˇzete samozˇrejmˇe pouˇz´ıvat i pro jiné projekty, které s pˇrekladem zdrojov´ ych soubor˚ u v jazyce C nemus´ı m´ıt v˚ ubec nic spoleˇcného. • pouˇzit´ı preprocesoru se m˚ uˇze velmi hodit v situaci, kdy potˇrebujete zas´ ahnout do ciz´ıho kódu, plného podm´ıneˇcn´ ych vkl´ ad´ an´ı r˚ uzn´ ych hlaviˇckov´ ych soubor˚ u a r˚ uzn´ ych definic z´ avisl´ ych na dan´ ych podm´ınk´ ach. Pˇri hled´ an´ı p˚ uvodce chyby vám právˇe m˚ uˇze hodnˇe pomoci samostatného zpracován´ı vstupn´ıho souboru pomoc´ı preprocesuru, kde problém jiˇz vˇetˇsinou rozpoznáte snadno. • cpp vám dok´ aˇze na standardn´ı chybov´ y v´ ystup zobrazit i cel´ y strom vkl´ adan´ ych soubor˚ u, coˇz opˇet pˇri podm´ıneˇcn´ ych pˇrekladech m˚ uˇze b´ yt velmi uˇziteˇcn´ a vˇec. Staˇc´ı pro to pouˇz´ıt volbu -H a pˇresmˇerovat v´ ystup do /dev/null ˇc´ımˇz dostanete pouze hierarchii vkl´ adan´ ych hlaviˇckov´ ych soubor˚ u.

22

Pˇ reklad jednoho modulu (kompil´ ator) main.s

main.i

.globl main .type main, @function main: pushhl %ebp movl %esp, %ebp pushl $.LC0 call puts addl $4, %esp .L1: leave ret

extern int var a; main() { puts("Ahoj"); }

kompilátor

int puts(char *s);

• pˇreklad z C do assembleru • v´ ystup této f´ aze pˇrekladu lze z´ıskat pomoc´ı cc -S.

23

Pˇ reklad jednoho modulu (assembler) main.s .globl main .type main, @function main: pushhl %ebp movl %esp, %ebp pushl $.LC0 call puts addl $4, %esp .L1: leave ret

assembler

main.o 457f 0000 0001 0000 00ec 0034

• pˇreklad z assembleru do strojového kódu • objektov´ y modul je v´ ysledkem pˇr´ıkazu cc -c.

24

464c 0000 0003 0000 0000 0000

0101 0000 0001 0000 0000 0000

0001 0000 0000 0000 0000 0028

Kompil´ ator • vol´ an´ı: cc [options ] soubor ... • nejd˚ uleˇzitˇejˇs´ı pˇrep´ınaˇce: -o soubor jméno v´ ysledného souboru -c

pouze pˇreklad (nelinkovat)

-E

pouze preprocesor (nepˇrekl´ adat)

-l

slinkuj s pˇr´ısluˇsnou knihovnou

-Ljm´ eno

pˇridej adres´ aˇr pro hled´ an´ı knihoven z -l

-Olevel

nastaven´ı u ´ rovnˇe optimalizace

-g

pˇreklad s ladic´ımi informacemi

-Djm´ eno

definuj makro pro preprocesor

-Iadres´ aˇ r

um´ıstˇen´ı #include soubor˚ u

• -l/-L jsou pˇrep´ınaˇce linker editoru, tj. kompil´ ator pˇr´ısluˇsné informace pˇred´ a, ale jsou pouˇz´ıv´ any tak ˇcasto, ˇze jsou vloˇzeny i do tohoto slajdu. • kompil´ ator a linker maj´ı mnoho dalˇs´ıch pˇrep´ınaˇc˚ u ovlivˇ nuj´ıc´ıch generovan´ y kód, vypisován´ı varovn´ ych hláˇsen´ı nebo variantu jazyka (K&R/ANSI). Je tˇreba nastudovat dokumentaci konkrétn´ıho produktu.

25

Pˇ reddefinovan´ a makra __FILE__, __LINE__, __DATE__, __TIME__, __cplusplus, apod. jsou standardn´ı makra kompil´ atoru C/C++ unix vˇzdy definováno v Unixu mips, i386, sparc hardwarová architektura linux, sgi, sun, bsd klon operaˇcn´ıho systému _POSIX_SOURCE, _XOPEN_SOURCE pˇreklad podle pˇr´ısluˇsné normy pro pˇreklad podle urˇcité normy by pˇred prvn´ım #include mˇel b´ yt ˇra´dek s definic´ı n´ asleduj´ıc´ıho makra. Pak naˇctˇete unistd.h. UNIX 98

#define _XOPEN_SOURCE 500

SUSv3

#define _XOPEN_SOURCE 600

POSIX1990

#define _POSIX_SOURCE

• funguje to tak, ˇze pomoc´ı konkrétn´ıch maker definujete co chcete (napˇr. POSIX SOURCE) a podle nastaven´ı jin´ ych maker (napˇr. POSIX VERSION) pak zjist´ıte, co jste dostali. Mus´ıte ale vˇzdy po nastaven´ı maker nainkludovat unistd.h. Napˇr´ıklad se pokus´ıme pˇreloˇzit program, kter´ y vyˇzaduje SUS3, na systému podporuj´ıc´ım SUS3 (Solaris 10), ale pˇrekladaˇcem, kter´ y podporuje pouze SUS2 (UNIX03 pˇrekladaˇc je c99). $ cat standards.c #define _XOPEN_SOURCE 600 /* you must #include at least one header !!! */ #include <stdio.h> int main(void) { return (0); } $ cc standards.c "/usr//sys/feature_tests.h", line 336: #error: "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99" cc: acomp failed for standards.c • zdroj maker pro standard tedy m˚ uˇze b´ yt /usr//sys/feature tests.h na Solarisu. Bud’ ho najdete pˇr´ımo na Solaris systému nebo pˇres code browser na www.opensolaris.org. • v dokumentaci konkrétn´ıho kompil´ atoru je moˇzné naj´ıt, kter´ a dalˇs´ı makra se pouˇz´ıvaj´ı. Mnoˇzstv´ı maker je definováno také v systémov´ ych hlaviˇckov´ ych souborech. 26

• POSIX.1 v sobˇe zahrnuje ANSI C; tedy C89, ne C99 (o C standardech v´ıce na stranˇe 13). • co se t´ yˇce maker k jednotliv´ ym standard˚ um, velmi dobr´ a je kapitola 1.5 v [Rochkind]. Také doporuˇcuji C program c1/suvreq.c k této kapitole, kter´ y je moˇzné naj´ıt i na m´ ych str´ ank´ ach v sekci ukázkov´ ych pˇr´ıklad˚ u. • mal´ y pˇr´ıklad na podm´ınˇen´ y pˇreklad: int main(void) { #ifdef unix printf("yeah\n"); #else printf("grr\n"); #endif return (0); }

Linker • Vol´ an´ı: ld [options ] soubor ... cc [options ] soubor ... • Nejd˚ uleˇzitˇejˇs´ı pˇrep´ınaˇce: -o soubor

jméno v´ ysledného souboru (default a.out)

-llib

linkuj s knihovnou liblib.so nebo liblib.a

-Lpath

cesta pro knihovny (-llib )

-shared

vytvoˇrit sd´ılenou knihovnu

-non shared

vytvoˇrit statick´ y program

• linker je program, kter´ y vezme typicky v´ıce objekt˚ u vygenerovan´ ych pˇrekladaˇcem a vytvoˇr´ı z nich bin´ arn´ı program, knihovnu nebo dalˇs´ı objekt vhodn´ y pro dalˇs´ı f´ azi linkován´ı. • pozor na to, ˇze na r˚ uzn´ ych systémech se nˇekteré pˇrep´ınaˇce mohou liˇsit, napˇr´ıklad ld na Solarisu nezn´ a pˇrep´ınaˇce -shared a -non shared, je nutné pouˇz´ıt jiné. • u mal´ ych program˚ u (v jednom souboru) lze provést pˇreklad a linkován´ı jedn´ım pˇr´ıkazem cc. U vˇetˇs´ıch program˚ u skládaj´ıc´ıch se z mnoha zdrojov´ ych 27

soubor˚ u a knihoven se obvykle oddˇeluje pˇreklad a linkov´ an´ı a cel´ y proces je ˇr´ızen utilitou make.

ˇ ızen´ı pˇ R´ rekladu a linkov´ an´ı (make) • zdrojov´ e texty main.c #include "util.h" main() { msg(); }

util.h void msg();

util.c #include "util.h" msg() { puts(); }

• soubor Makefile prog : main.o util.o main.c ց cc -o prog main.o util.o main.o main.o : main.c util.h ր ց util.h prog cc -c main.c ց ր util.o : util.c util.h util.o ր cc -c util.c util.c

• z´ avislosti

• program je moˇzné také pˇreloˇzit a slinkovat jedn´ım volán´ım kompil´ atoru, nebo definovat postup pˇrekladu a linkován´ı pomoc´ı shellového skriptu. D˚ uvodem pro pouˇzit´ı make je to, ˇze vyhodnocuje z´ avislosti mezi soubory a po zmˇenˇe ˇ y nˇekterého zdrojového souboru pˇrekl´ ad´ a jenom to, co na nˇem z´ avis´ı. Cast´ zp˚ usob pˇrekladu softwaru po aplikován´ı zmˇen zp˚ usobem “make clean; make all” je v situaci, kdy cel´ y pˇreklad trvá minuty (des´ıtky minut, hodiny. . . ), trochu nevhodn´ y – právˇe proto je d˚ uleˇzité m´ıt dobˇre napsan´ y Makefile. • ˇra´dek “prog : main.o util.o” definuje, ˇze se má nejprve rekurzivnˇe zajistit existence a aktuálnost soubor˚ u main.o a util.o. Pak se zkontroluje, zda soubor (c´ıl) prog existuje a je aktuáln´ı (datum posledn´ı modifikace souboru je mladˇs´ı neˇz main.o a util.o). Pokud ano, nedˇelá se nic. Kdyˇz ne, provede se pˇr´ıkaz na n´ asleduj´ıc´ım ˇra´dku. • make se spouˇst´ı typicky s parametrem urˇcuj´ıc´ı pˇr´ıˇsluˇsn´ y c´ıl (target ); pˇri spuˇstˇen´ı bez parametr˚ u se vezme prvn´ı target. Ten typicky b´ yv´ a all, coˇz vˇetˇsinou podle unixové konvence pˇreloˇz´ı vˇse, co se pˇreloˇzit má. N´ asleduje pak tˇreba zavol´ an´ı make s parametrem install apod. • make je samozˇrejmˇe univerz´ aln´ı n´ astroj, pouˇziteln´ y i jinde neˇz u pˇreklad˚ u

28

Syntaxe vstupn´ıho souboru (make) • popis z´ avislost´ı c´ıle:

targets : [files ]

• provádˇené pˇr´ıkazy:

command

• koment´ aˇr:

#comment

• pokraˇcovac´ı ˇra´dek:

line-begin \ line-continuation

• pozor na to, ˇ ze ˇ r´ adek s pˇ r´ıkazem zaˇ c´ın´ a tabul´ atorem, nikoliv mezerami. Kaˇzd´ y pˇr´ıkazov´ y ˇra´dek se provád´ı samostatn´ ym shellem, pokud je potˇreba provést v´ıce ˇra´dk˚ u pomoc´ı jednoho shellu, mus´ı se vˇsechny aˇz na posledn´ı ukonˇcit backslashem (shell je dostane jako jeden ˇra´dek). Viz pˇr´ıklad, ve kterém dva posledn´ı echo pˇr´ıkazy jsou souˇca´st´ı jednoho if pˇr´ıkazu, kter´ y je spuˇstˇen samostatn´ ym shellem: $ cat Makefile # Makefile test all: @echo $$$$ @echo $$$$ @if true; then \ echo $$$$; \ echo $$$$; \ fi $ make 5513 5514 5515 5515 • zdvojen´ım $ se potlaˇc´ı speci´ aln´ı v´ yznam dolaru (viz n´ asleduj´ıc´ı slajd) • znak @ na zaˇca´tku ˇra´dku potlaˇc´ı jeho v´ ypis – make jinak standardnˇe vypisuje nejdˇr´ıve to, co bude vykon´ avat.

29

• znak - na zaˇca´tku ˇra´dku zp˚ usob´ı ignorován´ı nenulové n´ avratové hodnoty; jinak make vˇzdy v takové situaci zahl´ as´ı chyby a okamˇzitˇe skonˇc´ı. • test1: false echo "OK" test2: -false echo "OK"

Makra (make) • definice makra: name = string • pokraˇcován´ı vkl´ ad´ a mezeru • nedefinovan´ a makra jsou prázdn´ a • nez´ aleˇz´ı na poˇrad´ı definic r˚ uzn´ ych maker • definice na pˇr´ıkazové ˇra´dce: make target name =string • vyvol´ an´ı makra: $name (pouze jednoznakové name ), ${name } nebo $(name ) • systémové promˇenné jsou pˇr´ıstupné jako makra

• kdyˇz je stejné makro definováno v´ıcekrát, plat´ı posledn´ı definice. • makra nen´ı moˇzné definovat rekurzivnˇe. $ cat Makefile M=value1 M=$(M) value2 all: echo $(M) $ make Variable M is recursive. • ˇcasto se pouˇz´ıvaj´ı r˚ uzné rozˇs´ıˇrené verze make (napˇr. GNU, BSD), které um´ı, podm´ınˇené sekce v Makefile, redefinice promˇenn´ ych, apod. • napsat Makefile kter´ y bude fungovat najednou pro r˚ uzné verze make nemus´ı b´ yt jednoduché, proto existuj´ı projekty jako je napˇr. GNU automake. Pro jednoduch´ y podm´ıneˇcn´ y pˇreklad v z´ avislosti na systému a kde se daj´ı oˇcek´ avat 30

r˚ uzné verze pˇr´ıkazu make, je moˇzné pouˇz´ıt napˇr´ıklad n´ asleduj´ıc´ı kód, kter´ y mi fungoval na vˇsech v nˇem zm´ınˇen´ ych systémech (znak ‘ je zpˇetná uvozovka, a ’ je norm´ aln´ı uvozovka): CFLAGS=‘x=\‘uname\‘; \ if [ $${x} = FreeBSD ]; then \ echo ’-Wall’; \ elif [ $${x} = SunOS ]; then \ echo ’-v’; \ elif [ $${x} = Linux ]; then \ echo ’-Wall -g’; \ fi‘ all: @echo "$(CFLAGS)" • v ostatn´ıch situac´ıch je vhodné, pˇr´ıpadnˇe nezbytné pouˇz´ıt programy typu autoconf nebo automake • make je velmi siln´ y n´ astroj, staˇc´ı se pod´ıvat do systémov´ ych Makefile soubor˚ u jakéhokoli Unixového systému. Typickou spoleˇcnou vlastnost´ı je to, ˇze neexistuje dokumentace jak je dan´ y makefile framework postaven.

Dynamick´ y linker Pˇri pˇrekladu je nutné m´ıt vˇsechny potˇrebné dynamické knihovny, protoˇze se kontroluje dosaˇzitelnost pouˇzit´ ych symbol˚ u, sestaven´ı kompletn´ıho programu se ale provede aˇ z pˇ ri spuˇ stˇ en´ı. To je u ´ kol pro dynamick´ y linker (run-time linker, loader ). • seznam dynamick´ ych knihoven zjist´ı ze sekce .dynamic • systém má nastaveno nˇekolik cest, kde se automaticky tyto knihovny hledaj´ı • v sekci .dynamic je moˇzné dalˇs´ı cesty ke knihovnám pˇridat pomoc´ı tag˚ u RUNPATH/RPATH • nalezené knihovny se pˇripoj´ı do pamˇet’ového procesu pomoc´ı vol´ an´ı mmap() (bude pozdˇeji)

Nasleduj´ıc´ı pˇ r´ıkazy a pˇ r´ıklady se t´ ykaj´ı Solarisu. Pokud to nebude fungovat na jin´ ych systémech, tak maj´ı ekvivaletn´ı n´ astroje s podobnou funkcionalitou. • proces spuˇstˇen´ı dynamicky slinkovaného programu prob´ıhá tak, ˇze kernel ve vol´ an´ı exec() namapuje dan´ y program do pamˇeti a zjist´ı, jak´ y dynamick´ y linker se má pouˇz´ıt (viz d´ ale). Pˇred t´ım, neˇz jádro pˇred´ a linkeru kontrolu, linker 31

namapuje do pamˇet’ového prostoru spouˇstˇeného procesu. Linker z hlaviˇcky programu zjist´ı, jaké dynamické knihovny se maj´ı d´ ale namapovat, provede to a teprve pak pˇred´ a ˇr´ızen´ı vaˇsemu programu. V´ aˇs program m˚ uˇze za bˇehu d´ ale vyuˇz´ıvat dynamick´ y linker pomoc´ı volán´ı typu dlopen() a spol. (k tomu se také dostaneme pozdˇeji). Uvˇedomte si, ˇze dynamick´ y linker zde nepracuje jako samostatn´ y proces, jeho kód se pouˇz´ıv´ a v r´ amci pamˇet’ového prostoru vaˇseho procesu; váˇs program, linker a knihovny dohromady tvoˇr´ı jeden proces. • seznam sekc´ı se zjist´ı pomoc´ı elfdump -c (GNU má pˇr´ıkaz readelf). O programov´ ych sekc´ıch bude v´ıce na stranˇe 115. • jak´ y dynamick´ y linker se pouˇzije kernel zjist´ı ze sekce .interp, viz ”elfdump -i” a “ld -I”. To znamen´ a, ˇze si m˚ uˇzete napsat vlastn´ı linker a pomoc´ı -I pro ld ho pak nastavit jako dynamick´ y linker pro váˇs program. • dynamická sekce se vyp´ıˇse pomoc´ı elfdump -d, dynamické knihovny jsou oznaˇcené tagem NEEDED • z´ avislosti na dynamick´ ych knihovnách je moˇzné dobˇre zjistit pomoc´ı pˇr´ıkazu ldd, kter´ y zjist´ı konkrétn´ı cesty ke knihovnám. Tento pˇr´ıkaz ˇreˇs´ı z´ avislosti rekurz´ıvnˇe, tj. uvid´ıte tedy i nepˇr´ımé z´ avislosti - tj. takové knihovny, které jsou pouˇzité knihovnami, které pˇr´ısluˇsn´ y program pouˇz´ıv´ a pˇr´ımo. Zjistit co je pˇresnˇe z´ avislé na ˇcem je moˇzné pomoc´ı volby -v. • jaké knihovny byly pˇri spuˇstˇen´ı nakonec pouˇzity m˚ uˇze b´ yt jiné neˇz co ukáˇze pˇr´ıkaz ldd, a to tˇreba d´ıky mechanismu LD PRELOAD, na Solarisu proto existuje pˇr´ıkaz pldd, kter´ y pomoc´ı ˇc´ısla procesu ukáˇze z´ avislosti konkrétn´ıho spuˇstˇeného programu. • v´ıce viz manu´ alová str´ anka pro dynamick´ y linker v Solarisu, ld.so.1, pˇr´ıpadnˇe Linker and Libraries Guide na docs.sun.com. Na FreeBSD se dynamick´ y linker naz´ yv´ a ld-elf.so.1, na Linuxu ld-linux.so.1, na IRIXu rld atd. • dynamick´ y linker se typicky d´ a konfigurovat pomoc´ı nastaven´ı promˇenn´ ych, napˇr´ıklad si zkuste na Solarisu spustit toto: LD_LIBRARY_PATH=/tmp LD_DEBUG=libs,detail date a pro vˇsechny moˇznosti jak debugovat dynamick´ y linker pouˇzijte: LD_DEBUG=help date • jin´ y pˇr´ıklad, kdy linker hled´ a knihovny i jinde neˇz v defaultn´ıch adres´ aˇr´ıch: $ cp /lib/libc.so.1 /tmp $ LD_LIBRARY_PATH=/tmp sleep 100 & [1] 104547 $ pldd 104547 104547: sleep 100 /tmp/libc.so.1 /usr/lib/locale/cs_CZ.ISO8859-2/cs_CZ.ISO8859-2.so.3

32

API vers ABI API – Application Programming Interface • rozhran´ı pouˇzité pouze ve zdrojovém kódu • rozhran´ı zdroj´ aku v˚ uˇci systému, knihovnˇe ˇci vlastn´ımu kódu, tj. napˇr. exit(1), printf("hello\n") nebo my function(1, 2) • . . . aby se stejn´ y zdrojov´ y text mohl pˇreloˇzit na vˇsech systémech podporuj´ıc´ı dané API ABI – Application Binary Interface • low-level rozhran´ı aplikace v˚ uˇci systému, knihovnˇe ˇci jiné ˇca´sti sama sebe • . . . aby se objektov´ y modul mohl pouˇz´ıt vˇsude tam, kde je podporováno stejné ABI

• pˇr´ıkladem API je tˇreba API definované normou POSIX.1 • ABI definuje konvenci vol´ an´ı (to jak program pˇred´ a parametry funkci a jak od n´ı pˇrevezme n´ avratovou hodnotu), jak´ a jsou ˇc´ısla systémov´ ych volán´ı, jak se systémové vol´ an´ı provede ˇci formát objektového modulu ˇci pˇrij´ıman´ ych argument˚ u, viz pˇr´ıklad dole. • ABI knihovny pak definuje mimo jiné mnoˇzinu volán´ı kter´ a jsou knihovnou definována, jejich parametry a typy tˇechto parametr˚ u • n´ asledn´ a uk´ azka je pˇr´ıklad na to, kdy v´ yvojáˇr zmˇen´ı velikost argument˚ u v bajtech (tj. zmˇen´ı ABI knihovny), a nahrad´ı novou verz´ı tu starou. Vˇsimnˇete si, ˇze dynamick´ y linker toto nezjist´ı; nem´ a totiˇz jak, ˇr´ıd´ı se podle jména knihovny v dynamické sekci programu, a to se nezmˇenilo. Uveden´ a zmˇena je sice i zmˇena v API a problém by se odstranil, kdybychom main.c znovu pˇreloˇzili se zmˇenˇen´ ym ˇra´dkem deklarace funkce add(). To je ale ˇcasto problém (pˇrekl´ adejte cel´ y systém jen kv˚ uli tomu), proto je tak d˚ uleˇzité dodrˇzovat zpˇetnou kompatibilitu v ABI u knihoven. V´ ysledek n´ asleduj´ıc´ıho pˇrekladu knihovny, programu a jeho spuˇstˇen´ı je jak bychom oˇcek´ avali (pouˇzit cc ze SunStudio, pro gcc pouˇzijte m´ısto -G volbu -shared; novˇejˇs´ı gcc nav´ıc neznaj´ı -R a je m´ısto toho nutné pouˇz´ıt -Xlinker -R -Xlinker .: $ cat main.c int my_add(int a, int b); int main(void)

33

{ printf("%d\n", my_add(128, 1)); return (0); } $ cat add.c int my_add(int a, int b) { return (a + b); } $ cc -G -o libadd.so add.c $ cc -L. -ladd -R. main.c $ ./a.out 129 Nyn´ı ale pˇriˇsla dalˇs´ı verze knihovny se stejn´ ym jménem, a ve funkci add() nastala zmˇena v typu argument˚ u. Program ale o niˇcem nev´ı, nech´ a se spustit a vr´ at´ı chybnou hodnotu: $ cat add2.c int my_add(char a, char b) { return (a + b); } $ cc -G -o libadd.so add2.c $ ./a.out -127 • zde pak pˇrich´ az´ı ke slovu verzován´ı knihoven, tj. je nutné “nˇeco” zmˇenit tak, aby po instalaci nové knihovny neˇslo program spustit bez jeho rekompilace.

34

Debugger dbx • Vol´ an´ı: dbx [ options ] [ program [ core ] ] • Nejbˇeˇznˇejˇs´ı pˇr´ıkazy: run [arglist ] where print expr set var = expr cont next, step stop condition trace condition command n help [name ] quit

start programu vypiˇs z´ asobn´ık vypiˇs v´ yraz zmˇen ˇ hodnotu promˇenné pokraˇcován´ı bˇehu programu proved’ ˇra´dku (bez/s vnoˇren´ım do funkce) nastaven´ı breakpointu nastaven´ı tracepointu akce na breakpointu (pˇr´ıkazy n´ asleduj´ı) n´ apovˇeda ukonˇcen´ı debuggeru

• z´ akladn´ı ˇra´dkov´ y symbolick´ y debugger, aby bylo moˇzné ho plnˇe vyuˇz´ıt, mus´ı b´ yt program pˇreloˇzen s ladic´ımi informacemi (cc -g). Ladˇen´ y program se startuje z debuggeru pˇr´ıkazem run, nebo se debugger pˇripoj´ı k jiˇz bˇeˇz´ıc´ımu procesu. Pomoc´ı dbx lze analyzovat i havarovan´ y program, kter´ y vygeneroval soubor core. • je moˇzné ho naj´ıt napˇr. na Solarisu, na Linuxu a FreeBSD defaultnˇe nen´ı. • pro debugging se zdrojov´ ymi kódy nestaˇc´ı pouˇz´ıt volbu -g, je z´ aroveˇ n nutné m´ıt i zdroj´ aky a objektové moduly tam, kde byly pˇri pˇrekladu. To je typicky bˇeˇzn´ a situace, protoˇze lad´ıte na stroji, kde z´ aroveˇ n i vyv´ıj´ıte. Pokud tomu tak nen´ı, je nutné si zdroj´ aky a objektové moduly zajistit, pokud k nim vede jiná cesta, lze pouˇz´ıt dbx pˇr´ıkaz pathmap. • gdb-kompatibiln´ı mód se spust´ı pˇres gdb on. Pokud vás zaj´ım´ a, jak´ y má dbx ekvivalentn´ı pˇr´ıkaz ke konkrétn´ımu gdb pˇr´ıkazu, pom˚ uˇze vám help FAQ; hned prvn´ı otázka je “A.1 Gdb does <something>; how do I do it in dbx?”

35

GNU debugger gdb • Vol´ an´ı: gdb [ options ] [ program [ core ] ] • Nejbˇeˇznˇejˇs´ı pˇr´ıkazy: run [arglist ] bt print expr set var = expr cont next, step break condition help [name ] quit

start programu vypiˇs z´ asobn´ık vypiˇs v´ yraz zmˇen ˇ hodnotu promˇenné pokraˇcován´ı bˇehu programu proved’ ˇra´dku (bez/s vnoˇren´ım do funkce) nastaven´ı breakpointu n´ apovˇeda ukonˇcen´ı debuggeru

• GNU obdoba dbx. M´ od kompatibiln´ı s dbx spust´ıte pˇres -dbx. • na r˚ uzn´ ych platform´ ach existuj´ı i debuggery s grafick´ ym rozhran´ım, napˇr. ˇ debugger (Solaris), cvd (IRIX), xxgdb (GNU), ddd (GNU). Casto funguj´ı jako nadstavby nad dbx, gdb. • #include <stdio.h> int main(void) { printf("hello, world\n"); return 0; } $ cc -g main.c $ gdb -q a.out (gdb) break main Breakpoint 1 at 0x8048548: file main.c, line 4. (gdb) run Starting program: /share/home/jp/src/gdb/a.out Breakpoint 1, main () at main.c:4 4 printf("hello, world\n"); (gdb) next hello, world 5 return 0; (gdb) c Continuing. Program exited normally. (gdb) q • debuggery jsou v´ yborn´ ymi pomocn´ıky pokud váˇs program konˇc´ı na chyby 36

typu “segmentation error” – tj. kdyˇz zkus´ıte nekorektnˇe pˇristoupit do pamˇeti, napˇr´ıklad tam kde nem´ ate co dˇelat. Kdyˇz pˇri pˇrekladu pouˇzijete option -g, uk´ aˇze vám pak debugger pˇresnˇe ˇc´ıslo ˇra´dku, kde nastal problém. Konkrétn´ı pˇr´ıklad (proˇc se vlastnˇe tento program chová jak se chová??? Hint: zkuste pˇreloˇzit na Solarisu pˇrekladaˇcem cc a spustit): $ cat -n main.c 1 int 2 main(void) 3 { 4 char *c = "hey world"; 5 c[0] = ’\0’; 6 return (0); 7 } } $ gcc -g main.c $ ./a.out Bus error (core dumped) $ gdb a.out a.out.core ... Core was generated by ‘a.out’. Program terminated with signal 10, Bus error. ... #0 0x080484e6 in main () at main.c:5 5 c[0] = ’\0’;


37

Standardn´ı hlaviˇ ckov´ e soubory (ANSI C) stdlib.h errno.h stdio.h ctype.h string.h time.h math.h setjmp.h assert.h stdarg.h limits.h signal.h

... ... ... ... ... ... ... ... ... ... ... ...

z´ akladn´ı makra a funkce oˇsetˇren´ı chyb vstup a v´ ystup práce se znaky práce s ˇretˇezci práce s datem a ˇcasem matematické funkce dlouhé skoky ladic´ı funkce práce s promˇenn´ ym poˇctem parametr˚ u implementaˇcnˇe z´ avislé konstanty oˇsetˇren´ı signál˚ u

• hlaviˇckov´ y soubor (header file) je soubor s deklaracemi funkc´ı (forward declaration), promˇenn´ ych a maker. Z pohledu preprocesoru je to obyˇcejn´ y soubor napsan´ y v jazyce C. • pozor na to, ˇze tyto hlaviˇckové soubory nejsou specifické pro UNIX. Jsou souˇca´st´ı standardu ANSI C, kter´ y jak jiˇz v´ıme (strana 13), je zahrnut v POSIX.1. • pˇr´ısluˇsn´ y hlaviˇckov´ y soubor pro konkrétn´ı funkci najdete v manu´ alové str´ ance dané funkce, toto je zaˇca´tek manu´ alové str´ anky na Solarisu pro memcpy(): Standard C Library Functions

memory(3C)

NAME memory, memccpy, memchr, memcmp, memcpy, memmove, memory operations

memset

-

SYNOPSIS #include <string.h> ... ... • jednotliv´ a makra obsaˇzen´ a v tˇechto souborech vˇetˇsinou nejsou vysvˇetlena, v´ yznam jednotliv´ ych maker je ale moˇzné si vyhledat v pˇr´ısluˇsn´ ych specifikac´ıch, které jsou on-line. Na nˇekter´ ych systémech (Solaris) maj´ı jednotlivé hlaviˇckové soubory svoji vlastn´ı manu´ alovou str´ anku (man stdlib.h). • makro assert() je moˇzné z bˇehem kompilace odstranit pomoc´ı makra NDEBUG

38

Standardn´ı hlaviˇ ckov´ e soubory (2) unistd.h

...

nejpouˇz´ıvanˇejˇs´ı systémová volán´ı

sys/types.h

...

datové typy pouˇz´ıvané v API UNIXu

fcntl.h

...

ˇr´ıd´ıc´ı operace pro soubory

sys/stat.h

...

informace o souborech

dirent.h

...

proch´ azen´ı adres´ aˇr˚ u

sys/wait.h

...

ˇcek´ an´ı na synovské procesy

sys/mman.h

...

mapován´ı pamˇeti

curses.h

...

ovl´ ad´ an´ı terminálu

regex.h

...

práce s regul´ arn´ımi v´ yrazy

• tyto headery uˇz patˇr´ı do UNIXu. • zaj´ımavé m˚ uˇze b´ yt pod´ıvat se do sys/types.h

39

Standardn´ı hlaviˇ ckov´ e soubory (3) semaphore.h

...

semafory (POSIX)

pthread.h

...

vl´ akna (POSIX threads)

sys/socket.h

...

s´ıt’ová komunikace

arpa/inet.h

...

manipulace se s´ıt’ov´ ymi adresami

sys/ipc.h

...

spoleˇcné deklarace pro System V IPC

sys/shm.h

...

sd´ılená pamˇet’ (System V)

sys/msg.h

...

fronty zpr´ av (System V)

sys/sem.h

...

semafory (System V)

• dokonˇcen´ı nejd˚ uleˇzitˇejˇs´ıch UNIXov´ ych header˚ u. Existuj´ı samozˇrejmˇe jeˇstˇe dalˇs´ı.

40

Funkce main() • pˇri spuˇstˇen´ı programu je pˇred´ ano ˇr´ızen´ı funkci main(). • int main (int argc, char *argv []); – argc . . . poˇcet argument˚ u pˇr´ıkazové ˇra´dky – argv . . . pole argument˚ u ∗ podle konvence je argv[0] cesta k programu ∗ posledn´ı prvek je argv[argc] == NULL

– n´ avrat z main() nebo volán´ı exit() ukonˇc´ı program – standardn´ı n´ avratové hodnoty EXIT_SUCCESS (0) a EXIT_FAILURE (1) ls -l / argc argv

3

argv[0] argv[1] argv[2] argv[3]

"ls" "-l" "/"

• prvn´ı parametr (typu int) ud´ av´ a poˇcet argument˚ u na pˇr´ıkazovém ˇra´dku (vˇcetnˇe parametru 0 – jména programu) a druh´ y parametr (typu char**) je pole ukazatel˚ u na tyto ˇretˇezce. Za posledn´ım ˇretˇezcem je jeˇstˇe NULL pointer – a to je nˇeco jiného neˇz prázdn´ y ˇretˇezec. • pˇri spuˇstˇen´ı programu pˇred´ a kód dynamického linkeru ˇr´ızen´ı funkci main(), viz strana 31. Staticky slinkovanému programu se ˇr´ızen´ı pˇred´ a pˇr´ımo. Nepˇr´ıtomnost main() v programu zp˚ usob´ı chybu pˇri pˇrekladu na u ´ rovni linkeru. Této funkci se pˇred´ a jméno spuˇstˇeného programu, argumenty z pˇr´ıkazové ˇra´dky a pˇr´ıpadnˇe i promˇenné prostˇred´ı. Ukonˇcen´ı této funkce znamen´ a konec programu a n´ avratová hodnota se pouˇzije jako kód ukonˇcen´ı programu pro OS. Jinou moˇznost´ı ukonˇcen´ı programu je pouˇzit´ı funkce exit() nebo _exit(), kterou lze pouˇz´ıt kdykoliv, nejen ve funkci main(). V C lze pouˇz´ıvat obˇe metody ukonˇcen´ı programu. • pˇred´ an´ı promˇenn´ ych prostˇred´ı tˇret´ım parametrem typu char** nen´ı souˇca´st´ı normativn´ı ˇca´sti C standardu, pouze informativn´ı. Pˇrekladaˇce to ale typicky podporuj´ı. Varianta main() s promˇenn´ ymi prostˇred´ı pak vypad´ a takto: int main(int argc, char *argv [], char *envp []); • n´ avratov´ y typ funkce main by mˇel b´ yt vˇzdy int; pˇrekladaˇc si jinak bude stˇeˇzovat. Z této hodnoty se ale pouˇzije pouze nejniˇzˇs´ıch 8 bit˚ u. Pozor na to, ˇze na rozd´ıl od jazyka C n´ avratová hodnota 0 má v shellu v´ yznam true (´ uspˇech) a nenula v´ yznam false (ne´ uspˇech). • rozd´ıl mezi funkcemi exit() a _exit() je v tom, ˇze exit() pˇred ukonˇcen´ım programu jeˇstˇe zavˇre streamy stdio a volá funkce zaregistrované pomoc´ı atexit(). V z´ avislosti na systému to mohou b´ yt i dalˇs´ı akce. Napˇr´ıklad ve FreeBSD je exit() systémové volán´ı a exit() knihovn´ı funkce. V Solarisu jsou obˇe systémov´ ymi vol´ an´ımi. 41

Promˇ enn´ e prostˇ red´ı • seznam vˇsech promˇenn´ ych prostˇred´ı (environment variables) se pˇred´ av´ a jako promˇenná extern char **environ; • je to pole ukazatel˚ u (ukonˇcené NULL) na ˇretˇezce ve tvaru: promˇ enn´ a =hodnota environ environ[0] environ[1] environ[2] environ[3]

"SHELL=/bin/bash" "DISPLAY=:0" "LOGNAME=beran"

• shell pˇred´ av´ a spuˇstˇenému programu ty promˇenné, které jsou oznaˇceny jako exportované (Bourne-like shellech pˇr´ıkazem export variable ). Po zmˇenˇe obsahu jiˇz jednou exportované promˇenné samozˇrejmˇe nen´ı potˇreba promˇennou znovu exportovat. Pˇr´ıkazem env vám shell vyp´ıˇse aktuáln´ı promˇenné prostˇred´ı, a pˇridat promˇennou do prostˇred´ı spouˇstˇeného programu pak staˇc´ı provést na pˇr´ıkazové ˇra´dce, aniˇz byste museli mˇenit prostˇred´ı vaˇseho shellu: $ date Sun Oct 7 13:13:58 PDT 2007 $ LC_TIME=fr date dimanche 7 octobre 2007 13 h 14 PDT • pˇri nahrazen´ı aktuáln´ıho obrazu procesu obrazem jin´ ym se pˇred´ av´ a, pokud se neˇrekne jinak, synovsk´ ym proces˚ um celé pole environ automaticky. Je moˇzné ve vol´ an´ı pˇr´ısluˇsné varianty funkce exec pˇredat pole jiné. • jaké promˇenné prostˇred´ı konkrétn´ı pˇr´ıkaz pouˇz´ıv´ a (a jak je pouˇz´ıv´ a) by mˇelo b´ yt v manu´ alové str´ ance. Typicky v sekci nazvané ENVIRONMENT nebo ENVIRONMENT VARIABLES • man napˇr´ıklad pouˇz´ıv´ a PAGER, vipw pak promˇennou EDITOR apod. • pokud je envp tˇret´ım parametrem funkce main, tak je to stejn´ a hodnota co je v ukazatelu environ.

42

Manipulace s promˇ enn´ ymi prostˇ red´ı • je moˇzné pˇr´ımo zmˇenit promˇennou environ • char *getenv (const char *name ); – vr´ at´ı hodnotu promˇenné name • int putenv (char *string ); – vloˇz´ı string ve tvaru jm´ eno =hodnota do prostˇred´ı (pˇrid´ a novou nebo modifikuje existuj´ıc´ı promˇennou) • zmˇeny se pˇren´ aˇsej´ı do synovsk´ ych proces˚ u • zmˇeny v prostˇred´ı syna samozˇrejmˇe prostˇred´ı otce neovlivn´ı • existuj´ı i funkce setenv() a unsetenv()

• u putenv() se vloˇzen´ y ˇretˇezec stane souˇca´st´ı prostˇred´ı (jeho pozdˇejˇs´ı zmˇena tak zmˇen´ı prostˇred´ı) a nesm´ıte proto pouˇz´ıvat retˇezce v automatick´ ych promˇenn´ ych, toto ˇreˇs´ı setenv(), kter´ y hodnotu promˇenné zkop´ıruje • d˚ uleˇzité je zapamatovat si, ˇze synovsk´ y proces zdˇed´ı v okamˇziku svého vzniku od rodiˇce vˇsechny promˇenné prostˇred´ı, ale jak´ akoliv manipulace s nimi v synovi je lokáln´ı a do otce se nepˇren´ aˇs´ı. Kaˇzd´ y proces má svou kopii promˇenn´ ych, proto ani n´ asledn´ a zmˇena prostˇred´ı otce nezmˇen´ı promˇenné jiˇz existuj´ıc´ıho potomka. • dalˇs´ı rozd´ıl mezi putenv a setenv je ten, ˇze v setenv mohu definovat, zda existuj´ıc´ı promˇennou chci nebo nechci pˇrepsat. putenv vˇzdy pˇrepisuje. • int main(void) { printf("%s\n", getenv("USER")); return 0; } $ ./a.out jp • jelikoˇz v´ıte, ˇze promˇenná environ je obyˇcejné pole ukazatel˚ u na ˇretˇezce, m˚ uˇzete s timto polem pracovat pˇr´ımo. Pozor vˇsak na to, ˇze v takovém pˇr´ıpadˇe pak jiˇz nesm´ıte pouˇz´ıvat zde uvedené funkce, jinak se m˚ uˇzete dostat do problém˚ u s jejich konkrétn´ı implementac´ı.

43

Zpracov´ an´ı argument˚ u programu • obvykl´ y z´ apis v shellu: program -pˇ rep´ ınaˇ ce argumenty • pˇrep´ınaˇce tvaru -x nebo -x hodnota , kde x je jedno p´ısmeno nebo ˇc´ıslice, hodnota je libovoln´ y ˇretˇezec • nˇekolik pˇrep´ınaˇc˚ u lze slouˇcit dohromady: ls -lRa • argument ’--’ nebo prvn´ı argument nezaˇc´ınaj´ıc´ı ’-’ ukonˇcuje pˇrep´ınaˇce, n´ asleduj´ıc´ı argumenty nejsou povaˇzov´ any za pˇrep´ınaˇce, i kdyˇz zaˇc´ınaj´ı znakem ’-’. • tento tvar argument˚ u poˇzaduje norma a lze je zpracovávat automaticky funkc´ı getopt().

• argumenty lze samozˇrejmˇe zpracovávat vlastn´ı funkc´ı, ale standardn´ı funkce je pohodlnˇejˇs´ı. • argumenty se typicky mohou opakovat, ale to má smysl jen v nˇekter´ ych situac´ıch • poˇrad´ı pˇrep´ınaˇc˚ u m˚ uˇze b´ yt d˚ uleˇzité a je na aplikaci, aby toto specifikovala • UNIX norma definuje pomoc´ı 13 pravidel velmi pˇresnˇe, jak by mˇely vypadat n´ azvy pˇr´ıkaz˚ u a formát pˇrep´ınaˇc˚ u. Napˇr´ıklad jméno pˇr´ıkazu by mˇelo b´ yt pouze mal´ ymi p´ısmeny, dlouhé 2–9 znak˚ u, z pˇrenositelné znakové sady. Pˇrep´ınaˇce bez argument˚ u by mˇelo b´ yt moˇzné d´ at do skupiny za jedn´ım znakem ’–’. Atd. • pouˇz´ıvat ˇc´ıslice jako pˇrep´ınaˇce je zastaralé; je to nˇekde v normˇe UNIX 03, i kdyˇz j´ a to v n´ı nenaˇsel. • pozor na Linux a jeho (ponˇekud zvláˇstn´ı a nestandardn´ı) permutován´ı argument˚ u (viz dalˇs´ı slidy). • pˇrep´ınaˇc -W by mˇel b´ yt rezervovan´ y pro vendor options, tj. pro nepˇrenositeln´ a rozˇs´ıˇren´ı

44

Zpracov´ an´ı pˇ rep´ınaˇ c˚ u: getopt() int getopt(int argc, char *const argv [], const char *optstring ); extern char *optarg ; extern int optind, opterr, optopt ; • funkce dostane parametry z pˇr´ıkazového ˇra´dku, pˇri kaˇzdém vol´ an´ı zpracuje a vr´ at´ı dalˇs´ı pˇrep´ınaˇc. Pokud má pˇrep´ınaˇc hodnotu, vr´ at´ı ji v optarg. • kdyˇz jsou vyˇcerp´ any vˇsechny pˇrep´ınaˇce, vr´ at´ı -1 a v optind je ˇc´ıslo prvn´ıho nezpracovaného argumentu. • moˇzné pˇrep´ınaˇce jsou zad´ any v optstring, kdyˇz za znakem pˇrep´ınaˇce n´ asleduje ’:’, má pˇrep´ınaˇc povinnou hodnotu. • pˇri chybˇe (nezn´ am´ y pˇrep´ınaˇc, chyb´ı hodnota) vr´ at´ı ’?’, uloˇz´ı znak pˇrep´ınaˇce do optopt a kdyˇz opterr nebylo nastaveno na nulu, vyp´ıˇse chybové hláˇsen´ı.

• obvykle se nejprve pomoc´ı getopt() naˇctou pˇrep´ınaˇce a pak se vlastn´ımi prostˇredky zpracuj´ı ostatn´ı argumenty (ˇcasto jsou to jména soubor˚ u). • je konvenc´ı, ˇze volby v parametru optstring jsou setˇr´ıdˇené.

45

Pˇ r´ıklad pouˇ zit´ı getopt() struct { int a, b; char c[128]; } opts; int opt; char *arg1; while((opt = getopt(argc, argv, "abc:")) != -1) switch(opt) { case ’a’: opts.a = 1; break; case ’b’: opts.b = 1; break; case ’c’: strcpy(opts.c, optarg); break; case ’?’: fprintf(stderr, "usage: %s [-ab] [-c Carg] arg1 arg2 ...\n", basename(argv[0])); break; } arg1 = argv[optind];

• dobr´ ym zvykem je pˇri detekován´ı nezn´ amého pˇrep´ınaˇce (nebo ˇspatného z´ apisu parametr˚ u programu) vypsat struˇcnou n´ apovˇedu (pˇr´ıpadnˇe s odkazem na podrobnˇejˇs´ı dokumentaci) a ukonˇcit program s chybou, tj. s nenulovou n´ avratovou hodnotou. • pˇr´ıklad také ukazuje nebezpeˇcné pouˇzit´ı funkce strcpy() • z pouˇzit´ı funkce getopt() je vidˇet, ˇze je stavová. Zpracovat dalˇs´ı pole argument˚ u, pˇr´ıpadnˇe znovuzpracovat p˚ uvodn´ı, je moˇzné nastaven´ım extern´ı promˇenné optreset na 1. • standardn´ı getopt() zachová poˇrad´ı pˇrep´ınaˇc˚ u pˇri zpracován´ı • pˇri pouˇzit´ı nedefinovaného pˇrep´ınaˇce funkce vyp´ıˇse chybu; to lze potlaˇcit nastaven´ım opterr na 0.

46

Dlouh´ y tvar pˇ rep´ınaˇ c˚ u • poprvé se objevilo v GNU knihovnˇe libiberty: --jm´ eno nebo --jm´ eno=hodnota • argumenty se permutuj´ı tak, aby pˇrep´ınaˇce byly na zaˇca´tku, napˇr. ls * -l je totéˇz jako ls -l *, standardn´ı chován´ı lze doc´ılit nastaven´ım promˇenné POSIXLY_CORRECT. • zpracovávaj´ı se funkc´ı getopt long(), kter´ a pouˇz´ıv´ a pole struktur popisuj´ıc´ıch jednotlivé pˇrep´ınaˇce: struct option { const char *name; /* jméno pˇrep´ınaˇce */ int has arg; /* hodnota: ano, ne, volitelnˇ e */ int *flag; /* kdyˇz je NULL, funkce vrac´ı val, jinak vrac´ı 0 a d´ a val do *flag */ int val; /* n´ avratová hodnota */ };

verze jak se objevila ve FreeBSD (funkce getopt long() nen´ı standarizovan´ a), má n´ asleduj´ıc´ı vlastnosti: • pokud vˇsechny dlouhé pˇrep´ınaˇce maj´ı nastaveny kr´ atkou variantu ve val, je chován´ı getopt long() kompatibiln´ı s getopt() • je moˇzné zad´ avat argument k dlouhému pˇrep´ınaˇci i s mezerou (napˇr´ıklad --color green) • pokud je nastaven flag, tak getopt long() vrac´ı 0, ˇc´ımˇz se tyto dlouhé pˇrep´ınaˇce bez kr´ atké varianty zpracuj´ı v jedné vˇetvi pˇr´ıkazu case • existuje i vol´ an´ı getopt long only(), které povoluje i dlouhé pˇrep´ınaˇce uvozené jednou uvozovkou (-option) • funkci getopt long() je moˇzné pouˇz´ıvat dvˇemi zp˚ usoby. Prvn´ı zp˚ usob je, ˇze kaˇzd´ y dlouh´ y pˇrep´ınaˇc má koresponduj´ıc´ı kr´ atk´ y – takto lze jednoduˇse pˇridat dlouhé pˇrep´ınaˇce do existuj´ıc´ıho programu a je kompatibiln´ı s getopt. Druh´ y zp˚ usob umoˇzn ˇ uje m´ıt samostatné dlouhé pˇrep´ınaˇce. V tom pˇr´ıpadˇe funkce vrac´ı vˇzdy 0 (nekompatibilita s getopt) a promˇenná *flag se nastav´ı na val. • na konkrétn´ım pˇr´ıkladu na n´ asleduj´ıc´ı str´ ance je vidˇet, jak to celé funguje

47

Dlouh´ e pˇ rep´ınaˇ ce (pokraˇ cov´ an´ı) int getopt long(int argc, char * const argv [], const char *optstring, const struct option *longopts, int *longindex ); • optstring obsahuje jednop´ısmenné pˇrep´ınaˇce, longopts obsahuje adresu pole struktur pro dlouhé pˇrep´ınaˇce (posledn´ı z´ aznam pole obsahuje samé nuly) • pokud funkce naraz´ı na dlouh´ y pˇrep´ınaˇc, vrac´ı odpov´ıdaj´ıc´ı val nebo nulu (pokud flag nebyl NULL), jinak je chován´ı shodné s getopt(). • do *longindex (kdyˇz nen´ı NULL) d´ a nav´ıc -1 nalezeného pˇrep´ınaˇce v longopts.

• toto je upraven´ y pˇr´ıklad z manu´ alové str´ anky na FreeBSD: #include <stdio.h> #include #include int ch, fd, daggerset, bflag = 0; static struct option longopts[] = { { "buffy", no_argument, { "fluoride", required_argument, { "daggerset", no_argument, { NULL, 0,

NULL, NULL, &daggerset, NULL,

’b’ }, ’f’ }, 1 }, 0 }};

int main(int argc, char **argv) { while ((ch = getopt_long(argc, argv, "bf:", longopts, NULL)) != -1) switch (ch) { case ’b’: bflag = 1; break; case ’f’: if ((fd = open(optarg, O_RDONLY, 0)) == -1) printf("unable to open %s", optarg); break; case 0: if (daggerset) { printf("Buffy will use her dagger to " "apply fluoride to dracula’s teeth\n"); } break; default: printf("usage: ...\n"); } argc -= optind; argv += optind; return 0; }

48

Struktura klasick´ eho OS UNIX uˇzivatelský proces pˇreruˇsen´ı návrat

uˇzivatelský reˇzim

rozhran´ı volán´ı jádra reˇzim jádra

subsystém ˇr´ızen´ı soubor˚ u buffery

subsystém ˇr´ızen´ı proces˚ u a pamˇeti

znakové blokové ovladaˇce

IPC plánovaˇc pˇridˇelován´ı pamˇeti

strojovˇe závislá vrstva ovládán´ı hardware hardware

• toto schéma je pˇrevzato z [Bach86], viz literatura. Zd˚ urazˇ nuje dva u ´ stˇredn´ı pojmy v modelu systému UNIX – soubory a procesy. V praxi se j´ adro od modelu typicky odliˇsuje, ale zde je d˚ uleˇzit´ a z´ akladn´ı pˇredstava. • UNIX rozliˇsuje dva reˇzimy bˇehu procesoru: uˇzivatelský reˇzim a reˇzim j´ adra. V uˇzivatelském reˇzimu nejsou pˇr´ıstupné privilegované instrukce (napˇr. mapován´ı pamˇeti, I/O, maskován´ı pˇreruˇsen´ı). Tyto dva reˇzimy mus´ı b´ yt podporovány na hardwarové u ´ rovni (procesorem). • procesy bˇeˇz´ı obvykle v uˇzivatelském reˇzimu, do reˇzimu jádra pˇrech´ az´ı bud’ instrukc´ı synchronn´ıho pˇreruˇsen´ı (trap) pro volán´ı sluˇzby jádra, nebo na z´ akladˇe asynchronn´ıch pˇreruˇsen´ı (hodiny, I/O). D´ ale se v reˇzimu jádra oˇsetˇruj´ı v´ yjimeˇcné stavy procesoru (v´ ypadek str´ anky, naruˇsen´ı ochrany pamˇeti, nezn´ am´ a instrukce apod.). Nˇekteré speci´ aln´ı akce jsou zajiˇst’ovány systémov´ ymi procesy, které bˇeˇz´ı celou dobu v reˇzimu jádra. • klasické UNIXové j´ adro je tvoˇreno monolitick´ ym kódem. P˚ uvodnˇe bylo potˇreba vygenerovat (tj. pˇreloˇzit ze zdrojov´ ych text˚ u a slinkovat) jádro pˇri zmˇenˇe nˇekterého parametru nebo pˇrid´ an´ı ovladaˇce zaˇr´ızen´ı. V novˇejˇs´ıch implementac´ıch je moˇzno nastavovat parametry jádra, nˇekdy i za bˇehu, pomoc´ı systémov´ ych utilit bez nutnosti rekompilace jádra. Modern´ı UNIXy umoˇzn ˇ uj´ı rozˇsiˇrovat kód j´ adra za bˇehu pomoc´ı tzv. modul˚ u jádra (loadable kernel modules). Napˇr´ıklad systém FreeBSD 5.4-RELEASE má 392 takov´ ych modul˚ u. • existuj´ı dva zp˚ usoby práce s perifériemi: bloková (block devices) a znaková zaˇr´ızen´ı (character, raw devices). Data z blokov´ ych zaˇr´ızen´ı (napˇr. disky) proch´ azej´ı pˇres vyrovn´ avac´ı pamˇeti (buffers) po bloc´ıch, znaková zaˇr´ızen´ı (napˇr. termin´ aly) umoˇzn ˇ uj´ı pracovat s jednotliv´ ymi bajty a nepouˇz´ıvaj´ı vyrovn´ avac´ı pamˇet’. 49

• j´ adro nen´ı samostatn´ y proces, ale je ˇca´st´ı kaˇzdého uˇzivatelského procesu. Kdyˇz j´ adro nˇeco vykon´ av´ a, tak vlastnˇe proces, bˇeˇz´ıc´ı v reˇzimu jádra, nˇeco provád´ı.

Procesy, vl´ akna, programy • proces je systémov´ y objekt charakterizovan´ y sv´ ym kontextem, identifikovan´ y jednoznaˇcn´ ym ˇc´ıslem (process ID, PID); jin´ ymi slovy ,,k´ od a data v pamˇeti” • vl´ akno (thread) je systémov´ y objekt, kter´ y existuje uvnitˇr procesu a je charakterizován sv´ ym stavem. Vˇsechna vl´ akna jednoho procesu sd´ıl´ı stejn´ y pamˇet’ov´ y prostor kromˇe registr˚ u procesoru a z´ asobn´ıku; ,,linie v´ ypoˇctu”, ,,to, co bˇeˇz´ı” • program ... soubor pˇresnˇe definovaného formátu obsahuj´ıc´ı instrukce, data a sluˇzebn´ı informace nutné ke spuˇstˇen´ı; ,,spustiteln´ y soubor na disku” ◦ pamˇ et’ se pˇridˇeluje proces˚ um. ◦ procesory se pˇridˇeluj´ı vl´ akn˚ um. ◦ vl´ akna jednoho procesu mohou bˇeˇzet na r˚ uzn´ ych procesorech.

• kontext je pamˇet’ov´ y prostor procesu, obsah registr˚ u a datové struktury jádra t´ ykaj´ıc´ı se daného procesu • jinak ˇreˇceno – kontext procesu je jeho stav. Kdyˇz systém vykon´ av´ a proces, ˇr´ık´ a se, ˇze bˇeˇz´ı v kontextu procesu. J´ adro (klasické) obsluhuje pˇreruˇsen´ı v kontextu pˇreruˇseného procesu. • vl´ akna se dostala do UNIXu aˇz pozdˇeji, p˚ uvodnˇe v nˇem existovaly pouze procesy (s jedin´ ym hlavn´ım vl´ aknem). Moˇznost pouˇz´ıt v procesu v´ıce vl´ aken byla zavedena, protoˇze se uk´ azalo, ˇze je vhodné m´ıt v´ıce paraleln´ıch lini´ı v´ ypoˇctu nad sd´ılen´ ymi daty. • pamˇet’ové prostory proces˚ u jsou navz´ ajem izolované, ale procesy spolu mohou komunikovat (pozdˇeji se dozv´ıme, ˇze mohou i ˇca´steˇcnˇe sd´ılet pamˇet’). • procesy jsou entity na u ´ rovni jádra, vl´ akna mohou b´ yt ˇca´steˇcnˇe nebo zcela implementována knihovn´ımi funkcemi (tj. vl´ akna nemus´ı jádro v˚ ubec podporovat). S vl´ akny je spojena menˇs´ı reˇzie neˇz s procesy. • systémov´ y proces, kter´ y bˇeˇz´ı na pozad´ı obvykle po celou dobu bˇehu systému a zajiˇst’uje nˇekteré systémové sluˇzby (inetd, cron, sendmail. . . ) se naz´ yv´ a démon (angl. daemon). Systém BSD tedy nem´ a ve znaku ˇcerta, ale démona.

50

J´ adro, reˇ zimy, pˇ reruˇ sen´ı (klasick´ y UNIX) • procesy typicky bˇeˇz´ı v uˇzivatelském reˇzimu • systémové vol´ an´ı zp˚ usob´ı pˇrepnut´ı do reˇzimu jádra • proces má pro kaˇzd´ y reˇzim samostatn´ y z´ asobn´ık • j´ adro je ˇca´st´ı kaˇzdého uˇzivatelského procesu, nen´ı to samostn´ y proces (procesy) • pˇrepnut´ı na jin´ y proces se naz´ yv´ a pˇrepnut´ı kontextu • obsluha pˇreruˇsen´ı se provád´ı v kontextu pˇreruˇseného procesu • klasické j´ adro je nepreemptivn´ı

• j´ adro nen´ı oddˇ elen´ a mnoˇ zina proces˚ u, bˇ eˇ z´ıc´ıch paralelnˇ e s uˇ zivatelsk´ ymi procesy, ale je ˇ c´ ast´ı kaˇ zd´ eho uˇ zivatelsk´ eho procesu. • pˇrechod mezi uˇzivatelsk´ ym reˇzimem a reˇzimem jádra nen´ı pˇrepnut´ı kontextu – proces bˇeˇz´ı poˇra´d v tom samém • pˇreruˇsen´ y proces nemusel pˇreruˇsen´ı v˚ ubec zp˚ usobit • v reˇzimu j´ adra m˚ uˇze proces pˇristupovat i k adres´ am jádra, kter´ a z uˇzivatelského reˇzimu pˇr´ıstupn´ a nejsou; taktéˇz m˚ uˇze pˇristupovat k instrukc´ım (napˇr. instrukce manipuluj´ıc´ı se stavov´ ym registrem), jejichˇz vykon´ an´ı v uˇzivatelském reˇzimu vede k chybˇe • pˇreruˇsovac´ı rutina se nem˚ uˇze zablokovat, protoˇze t´ım by zablokovala proces; proces se totiˇz m˚ uˇze zablokovat jen ze své vlastn´ı v˚ ule. Modern´ı Unixy dnes pouˇz´ıvaj´ı interrupt vl´ akna, v jejichˇz kontextu se mohou drivery zablokovat. • to, ˇze klasické unixové j´ adro je nepreemptivn´ı znamen´ a, ˇze jeden proces nem˚ uˇ ze zablokovat jin´ y proces • pˇri obsluze pˇreruˇsen´ı se m˚ uˇze stát, ˇze nastane dalˇs´ı pˇreruˇsen´ı. Pokud je jeho priorita vˇetˇs´ı, je procesorem pˇrijmuto. Posloupnost pˇrijmut´ ych pˇreruˇsen´ı je uchována v z´ asobn´ıku kontextových vrstev. • u modern´ıch kernel˚ u je situace ˇ casto velmi rozd´ıln´ a – obsluha pˇ reruˇ sen´ı, preeptivnost kernelu atd.; k nˇ ekter´ ym vˇ ecem se moˇ zn´ a dostaneme pozdˇ eji bˇ ehem semestru

51

Vol´ an´ı sluˇ zeb a komunikace mezi procesy • UNIX proces

proces

proces

rozhran´ı volán´ı jádra jádro • distribuovan´ y OS uˇzivatelský proces

uˇzivatelský proces

server

server

server

jádro

jádro

jádro

jádro

jádro

• pokud unixov´ y proces vyˇzaduje proveden´ı systémové sluˇzby, pomoc´ı systémového vol´ an´ı pˇred´ a ˇr´ızen´ı j´ adru. J´ adro je kus k´ odu sd´ılen´ y vˇsemi procesy (ovˇsem pˇr´ıstupn´ y jen pro ty, které jsou právˇe v reˇzimu jádra). J´ adro tedy nen´ı samostatn´ y privilegovan´ y proces, ale vˇzdy bˇeˇz´ı v r´ amci nˇekterého procesu (toho, kter´ y poˇza´dal j´ adro o sluˇzbu, nebo toho, kter´ y bˇeˇzel v okamˇziku pˇr´ıchodu pˇreruˇsen´ı). • komunikace mezi procesy v UNIXu je ˇreˇsena pomoc´ı systémov´ ych volán´ı, je tedy zprostˇredkovan´ a j´ adrem. • aby to nebylo tak jednoduché, mohou existovat systémové procesy (oznaˇcované jako kernel threads), které bˇeˇz´ı celou dobu v reˇzimu jádra. Naprostá vˇetˇsina systémov´ ych proces˚ u vˇsak bˇeˇz´ı v uˇzivatelském reˇzimu a liˇs´ı se jen t´ım, ˇze maj´ı vˇetˇs´ı pˇr´ıstupová práva. Plánovaˇc proces˚ u pˇrep´ıná mezi procesy a t´ım umoˇzn ˇ uje bˇeh v´ıce proces˚ u souˇcasnˇe i na jednom procesoru. Na multiprocesorov´ ych poˇc´ıtaˇc´ıch pak funguje skuteˇcn´ y paralelismus proces˚ u a vl´ aken (dokonce se proces m˚ uˇze pˇri pˇreplánován´ı dostat i na jin´ y procesor). • v distribuovaném operaˇcn´ım systému má jádro obvykle formu mikrojádra, tj. zajiˇst’uje pouze nejz´ akladnˇejˇs´ı sluˇzby ˇr´ızen´ı procesoru, pˇridˇelován´ı pamˇeti a komunikace mezi procesy. Vyˇsˇs´ı systémové sluˇzby, které jsou v UNIXu souˇca´st´ı j´ adra (napˇr. pˇr´ıstup k systému soubor˚ u) jsou realizovány speci´ aln´ımi procesy (servery) bˇeˇz´ıc´ımi v uˇzivatelském reˇzimu procesoru. J´ adro pˇred´ a poˇzadavek uˇzivatelského procesu pˇr´ısluˇsnému serveru, kter´ y m˚ uˇze bˇeˇzet i na jiném uzlu s´ıtˇe. • dostupn´ ych mikrokernel˚ u je v dneˇsn´ı dobˇe mnoho. M˚ uˇzete zkusit napˇr´ıklad Minix (unix-like v´ yukov´ y systém), pˇr´ıpadnˇe systém HURD, kter´ y bˇeˇz´ı nad mikroj´ adrem Mach. 52

Syst´ emov´ a vol´ an´ı, funkce • v UNIXu se rozliˇsuj´ı syst´ emov´ a vol´ an´ı a knihovn´ı funkce. Toto rozliˇsen´ı dodrˇzuj´ı i manu´ alové str´ anky: sekce 2 obsahuje systémová vol´ an´ı (syscalls), sekce 3 knihovn´ı funkce (library functions). – knihovn´ı funkce se vykon´ avaj´ı v uˇzivatelském reˇzimu, stejnˇe jako ostatn´ı kód programu. – systémová vol´ an´ı maj´ı také tvar volán´ı funkce. Pˇr´ısluˇsná funkce ale pouze dohodnut´ ym zp˚ usobem zpracuje argumenty vol´ an´ı a pˇred´ a ˇr´ızen´ı j´ adru pomoc´ı instrukce synchronn´ıho pˇreruˇsen´ı. Po n´ avratu z jádra funkce uprav´ı v´ ysledek a pˇred´ a ho volaj´ıc´ımu. • standardy tyto dvˇe kategorie nerozliˇsuj´ı, protoˇze z hlediska program´ atora je jedno, jestli urˇcitou funkci provede jádro nebo knihovna.

• zjednoduˇsenˇe lze ˇr´ıci, ˇze systémové volán´ı je funkce, kter´ a jen uprav´ı své argumenty do vhodné podoby, pˇrepne reˇzim procesoru a skuteˇcnou práci nech´ a na j´ adru. Nakonec zase uprav´ı v´ ysledek. Knihovn´ı funkce m˚ uˇze a nemus´ı volat jádro, ale vˇzdy sama dˇel´ a nˇejakou netrivi´ aln´ı ˇcinnost v uˇzivatelském reˇzimu. • v assembleru je moˇzné zavolat volán´ı jádra pˇr´ımo • API j´ adra je definované na u ´ rovni volán´ı funkc´ı standardn´ı knihovny, nikoliv na u ´ rovni pˇreruˇsen´ı a datov´ ych struktur pouˇz´ıvan´ ych tˇemito funkcemi pro pˇred´ an´ı ˇr´ızen´ı j´ adru. Mechanismus pˇrepnut´ı mezi uˇzivatelsk´ ym reˇzimem a reˇzimem j´ adra se totiˇz m˚ uˇze liˇsit nejen v z´ avislosti na hardwarové platformˇe, ale i mezi r˚ uzn´ ymi verzemi systému na stejném hardwaru.

53

N´ avratov´ e hodnoty syst´ emov´ ych vol´ an´ı • celoˇc´ıseln´ a n´ avratová hodnota (int, pid t, off t, apod.) – >= 0 . . . operace u ´ spˇeˇsnˇe provedena – == -1 . . . chyba • n´ avratová hodnota typu ukazatel – != NULL . . . operace u ´ spˇeˇsnˇe provedena – == NULL . . . chyba • po ne´ uspˇeˇsném systémovém volán´ı je kód chyby v glob´ aln´ı promˇenné extern int errno; • u ´ spˇeˇsné vol´ an´ı nemˇen´ı hodnotu v errno! Je tedy tˇreba nejprve otestovat n´ avratovou hodnotu a pak teprve errno. • chybové hláˇsen´ı podle hodnoty v errno vyp´ıˇse funkce void perror(const char *s ); • textov´ y popis chyby s dan´ ym ˇc´ıslem vr´ at´ı funkce char *strerror(int errnum );

• funkce pro práci s vl´ akny pthread *() nenastavuj´ı errno, ale vrac´ı bud’ nulu (´ uspˇech) nebo pˇr´ımo kód chyby. • pro nˇekter´ a vol´ an´ı m˚ uˇze m´ıt smysl i n´ avratová hodnota -1. Pak je tˇreba nejprve nastavit errno = 0 a po n´ avratu zkontrolovat, zda se errno zmˇenilo. Napˇr. funkce strtol() vrac´ı pˇri chybˇe 0, coˇz je platná hodnota i pro spr´ avn´ y v´ ysledek (a −1 je samozˇrejmˇe platn´ y v´ ysledek také). • je tedy vˇzdy nutné si pˇreˇc´ıst manu´ alovou str´ anku pro pˇr´ıˇsluˇsné volán´ı nebo knihovn´ı funkci • pozn.: u ´ spˇeˇsnost funkc´ı ze stdio.h je tˇreba testovat pomoc´ı int ferror(FILE *stream );, protoˇze jinak nelze rozliˇsit mezi chybou a koncem streamu. Vzhledem k tomu, ˇze tyto funkce nepouˇz´ıv´ ame (kromˇe printf/fprintf na stdout/stderr), nemˇeli byste ji potˇrebovat.

54

Obsah • u ´ vod, v´ yvoj UNIXu a C, program´ atorské n´ astroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇ r´ıstupov´ a pr´ ava, perifern´ı zaˇ r´ızen´ı, syst´ em soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • signály • synchronizace a komunikace proces˚ u • s´ıt’ová komunikace • vl´ akna, synchronizace vl´ aken • ??? - bude definováno pozdˇeji, podle toho kolik zbyde ˇcasu

Uˇ zivatel´ e a skupiny beran:x:1205:106:Martin Beran:/home/beran:/bin/bash v´ yznam jednotliv´ ych pol´ı: uˇzivatelské jméno, zak´ odované heslo (novˇe v /etc/shadow), ˇc´ıslo uˇzivatele (UID); superuˇzivatel (root) má UID 0, ˇc´ıslo prim´ arn´ı skupiny (GID), plné jméno, domovsk´ y adres´ aˇr, login-shell sisal:*:106:forst,beran v´ yznam jednotliv´ ych pol´ı: jméno skupiny, heslo pro pˇrepnut´ı do skupiny, ˇc´ıslo skupiny (GID), seznam ˇclen˚ u skupiny

55

• informace o uˇzivatel´ıch v souborech /etc/passwd, a /etc/group jsou zpracováv´ any r˚ uzn´ ymi systémov´ ymi programy, napˇr. login (pˇrihláˇsen´ı do systému na z´ akladˇe uˇzivatelského jména a hesla) nebo su (zmˇena identity). J´ adro o tˇ echto souborech nic nev´ı, pouˇ z´ıv´ a pouze numerickou identifikaci uˇ zivatele a skupiny. • dnes jiˇz hesla nejsou z bezpeˇcnostn´ıch d˚ uvod˚ u pˇr´ımo v /etc/passwd, ale napˇr´ıklad v /etc/shadow, kter´ y bˇeˇznému uˇzivateli pˇr´ıstupn´ y nen´ı. A napˇr. na FreeBSD se soubor /etc/passwd generuje ze souboru /etc/master.passwd, kter´ y zak´ odovan´ a hesla obsahuje. • existuj´ı i jiné systémy, které (nejen) pro autentizaci /etc/passwd nemus´ı v˚ ubec pouˇz´ıvat, napˇr´ıklad NIS (Network Information Service). • skupina uˇzivatele uveden´ a v /etc/passwd je prim´ arn´ı. Tuto skupinovou identifikaci dostanou napˇr. soubory vytvoˇrené procesy uˇzivatele. Dalˇs´ı skupiny, ve kter´ ych je uˇzivatel uveden v souboru /etc/group, jsou doplˇ nkové (supplementary) a rozˇsiˇruj´ı pˇr´ıstupová práva uˇzivatele: skupinov´ y pˇr´ıstup je povolen ke vˇsem objekt˚ um, jejichˇz skupinov´ y vlastn´ık je roven bud’ prim´ arn´ı, nebo jedné z doplˇ nkov´ ych skupin. • p˚ uvodnˇe mˇel v UNIXu kaˇzd´ y uˇzivatel vˇzdy aktivn´ı pouze jednu skupinovou identitu. Po nalogován´ı byl ve své prim´ arn´ı skupinˇe, pro z´ıskán´ı práv jiné skupiny bylo tˇreba se do n´ı pˇrepnout pˇr´ıkazem newgrp (skupinová obdoba su, ˇr´ıd´ı se obsahem souboru /etc/group), kter´ y spustil nov´ y shell. • v novˇejˇs´ıch UNIXech nen´ı tˇreba pro pˇr´ıstup k soubor˚ um mˇenit prim´ arn´ı skupinovou identitu procesu, pokud uˇzivatel patˇr´ı do potˇrebné skupiny. Zmˇena identity je nutná, pouze kdyˇz chceme vytváˇret soubory s jinou skupinovou identitou neˇz je prim´ arn´ı skupina uˇzivatele. Lok´ alnˇe pro urˇcit´ y adres´ aˇr toho lze dos´ ahnout nastaven´ım skupinového vlastn´ıka adres´ aˇre na poˇzadovanou skupinu a nastaven´ım bitu SGID v pˇr´ıstupov´ ych právech adres´ aˇre – to plat´ı pro systémy zaloˇzené na System V. U BSD staˇc´ı zmˇenit poˇzadovanou skupinu u adres´ aˇre. • druh´ a poloˇzka v ˇra´dc´ıch /etc/group obsahuje zak´ odované skupinové heslo pouˇz´ıvané pˇr´ıkazem newgrp, to se jiˇz dnes nepouˇz´ıv´ a. Napˇr´ıklad na FreeBSD je pˇr´ıkaz newgrp pˇr´ıstupn´ y uˇz jen superuˇzivateli (kv˚ uli volán´ı setgroups).

56

Name service switch • dneˇsn´ı systémy nejsou omezeny na pouˇz´ıv´ an´ı /etc/passwd a /etc/groups • systém pouˇz´ıv´ a datab´ aze (passwd, groups, protocols, . . . ) • data datab´ az´ı poch´ azej´ı ze zdroj˚ u (soubory, DNS, NIS, LDAP, ...) • soubor nsswitch.conf definuje jaké datab´ aze pouˇz´ıvaj´ı jaké zdroje • knihovn´ı funkce toto samozˇrejmˇe mus´ı explicitnˇe podporovat • je moˇzné nˇekteré zdroje kombinovat, napˇr´ıklad uˇzivatel se nejdˇr´ıve m˚ uˇze hledat v /etc/passwd a poté v NISu • poprvé se objevilo v Solarisu, poté pˇrevzato dalˇs´ımi systémy

• systémy maj´ı typicky manu´ alovou str´ anku nsswitch.conf(5), kde lze nalézt podrobnosti v z´ avislosti na konkrétn´ım operaˇcn´ım systému • zde je ˇca´st skuteˇcného souboru nsswitch.conf ze stroje u-us: passwd: group:

files ldap files ldap

# You must also set up the /etc/resolv.conf file for DNS name # server lookup. See resolv.conf(4). hosts: files dns # Note that IPv4 addresses are searched for in all of the # ipnodes databases before searching the hosts databases. ipnodes: files dns networks: protocols: rpc: ethers:

files files files files

57

Testov´ an´ı pˇ r´ıstupov´ ych pr´ av • uˇzivatel je identifikován ˇc´ıslem uˇzivatele (UID) a ˇc´ısly skupin, do kter´ ych patˇr´ı (primary GID, supplementary GIDs). • tuto identifikaci dˇed´ı kaˇzd´ y proces daného uˇzivatele. • soubor S má vlastn´ıka (U IDS ) a skupinového vlastn´ıka (GIDS ). • algoritmus testován´ı pˇr´ıstupov´ ych práv pro proces P (U IDP , GIDP , SU P G) a soubor S(U IDS , GIDS ): Jestliˇze

pak P roces má v˚ uˇci Souboru

if(U IDP == 0)

. . . vˇsechna práva

else if(U IDP == U IDS )

. . . práva vlastn´ıka

else if(GIDP == GIDS || GIDS ∈ SU P G)

. . . práva ˇclena skupiny . . . práva ostatn´ıch

else

• procesy superuˇzivatele root mohou mˇenit svoji uˇzivatelskou a skupinovou identitu. Toho vyuˇz´ıv´ a napˇr. proces login, kter´ y bˇeˇz´ı jako root a po zkontrolován´ı jména a hesla spust´ı shell s uˇzivatelskou identitou (pomoc´ı volán´ı setuid() – viz dalˇs´ı slajdy). • z algoritmu plyne, ˇze pro roota nen´ı relevantn´ı nastaven´ı práv (m´ a vˇzdy neomezen´ y pˇr´ıstup). Pokud se shoduje uˇzivatel, nepouˇzij´ı se nikdy práva skupiny nebo ostatn´ıch, i kdyˇz povoluj´ı v´ıce neˇz uˇzivatelsk´ a práva. Podobnˇe práva ostatn´ıch se nepouˇzij´ı, jestliˇze se shoduje skupinová identita. Tedy pokud má m˚ uj soubor nastaveny práva ---rwxrwx, nemohu ho ˇc´ıst, zapisovat ani spustit (dokud nastaven´ı práv nezmˇen´ım). • nˇekteré systémy se odkl´ anˇej´ı od klasického modelu, kdy mnoho proces˚ u bˇeˇzelo pod uˇzivatelem s UID 0 a pˇri bezpeˇcnostn´ı chybˇe v takové aplikaci ˇcasto u ´ toˇcn´ık z´ıskal vl´ adu nad cel´ ym systémem a zavádˇej´ı modely jako je least privilege model v Solarisu 10, systrace v OpenBSD, . . .

58

Re´ aln´ e a efektivn´ı UID/GID • u kaˇzdého procesu se rozliˇsuje: – re´ aln´ e UID (RUID) – kdo je skuteˇcn´ ym vlastn´ıkem procesu – efektivn´ı UID (EUID) – uˇzivatel, jehoˇz práva proces pouˇz´ıv´ a – uschovan´ e UID (saved SUID) – p˚ uvodn´ı efektivn´ı UID • podobnˇe se rozliˇsuje re´ alné, efektivn´ı a uschované GID procesu. • obvykle plat´ı RUID==EUID && RGID==EGID. • prop˚ ujˇ cov´ an´ı pr´ av . . . spuˇstˇen´ı programu s nastaven´ ym SUID (set user ID) bitem zmˇen´ı EUID procesu na UID vlastn´ıka programu, RUID se nezmˇen´ı. • podobnˇe SGID bit ovlivˇ nuje EGID procesu. • pˇri kontrole pˇr´ıstupov´ ych práv se pouˇz´ıvaj´ı vˇzdy EUID, EGID a supplementary GIDs.

• bity SUID a SGID se pouˇz´ıvaj´ı u program˚ u, které potˇrebuj´ı vˇetˇs´ı pˇr´ıstupová práva, neˇz má uˇzivatel, jenˇz je spouˇst´ı. Pˇr´ıkladem je program passwd, kter´ y mus´ı aktualizovat soubory /etc/passwd a /etc/shadow, kde ten prvn´ı nem˚ uˇze bˇeˇzn´ y uˇzivatel mˇenit a druh´ y z nich ani ˇc´ıst. Dalˇs´ı pˇr´ıklad je program su. Ten mus´ı m´ıt právo libovolnˇe zmˇenit uˇzivatelskou a skupinovou identitu, coˇz je privilegium proces˚ u s UID 0. • SUID a SGID programy by mˇely b´ yt peˇclivˇe naprogramovány, aby dovolily pouze ty operace, pro které jsou urˇceny, a neumoˇznily zneuˇz´ıt jejich privilegia pro neoprávnˇené akce (napˇr. spuˇstˇen´ı rootovského shellu). Zkuˇsenost ukazuje, ˇze tyto programy jsou jednou z nejˇcastˇejˇs´ıch pˇr´ıˇcin bezpeˇcnost´ıch problém˚ u UNIXov´ ych systém˚ u. • z´ akladn´ım pravidlem pro SUID programy je: nepiˇ ste je pokud to nen´ı opravdu nezbytné. Je to typické m´ısto pro generován´ı bezpeˇcnostn´ıch chyb protoˇze dobˇre (= bezpeˇcnˇe) napsat sloˇzitˇejˇs´ı SUID program nen´ı jednoduché. • toto jsou pravidla pro zmˇeny: – beˇzn´ y uˇzivatel nem˚ uˇze zmˇenit své RUID nebo uschované SUID (vyj´ımka je pˇri vol´ an´ı exec(), viz strana 113) – proces m˚ uˇze vˇzdy zmˇenit své EUID na to z RUID nebo z uschovaného UID. Toto zaruˇcuje, ˇze v SUID programu je moˇzné libovolnˇe mˇenit EUID mezi t´ım p˚ uvodn´ım kter´ ym proces z´ıskal práva vlastn´ıka a mezi UID skuteˇcného uˇzivatele kter´ y dan´ y proces spustil) – root m˚ uˇze vˇsechno, a kdyˇz zmˇen´ı RUID, tak se z´ aroveˇ n zmˇen´ı i uchované UID – nemˇelo by smysl mˇenit jen jedno z nich kdyˇz kterékoli m˚ uˇzete pouˇz´ıt pro nastaven´ı EUID.

59

Identifikace vlastn´ıka procesu • uid t getuid(void) vrac´ı re´ alné user ID volaj´ıc´ıho procesu. • uid t geteuid(void) vrac´ı efektivn´ı user ID volaj´ıc´ıho procesu. • gid t getgid(void) vrac´ı re´ alné group ID volaj´ıc´ıho procesu. • gid t getegid(void) vrac´ı efektivn´ı group ID volaj´ıc´ıho procesu. • int getgroups(int gidsz, gid t glist []) – do glist d´ a nejv´ yˇse gidsz supplementary group IDs volaj´ıc´ıho procesu a vr´ at´ı poˇcet vˇsech GIDs procesu.

• getgroups(): kdyˇz gidsz == 0, jen vr´ at´ı poˇcet skupin. Kdyˇz 0 < gidsz < #skupin, vr´ at´ı -1. • v UNIXu je mnoho typ˚ u jako uid_t, gid_t, size_t, apod. Vesmˇes jsou to celoˇc´ıselné typy, ˇcasto je najdete v /usr//sys/types.h

60

Zmˇ ena vlastn´ıka procesu • int setuid(uid t uid ); – v procesu s EUID == 0 nastav´ı RUID, EUID i saved-SUID na uid (viz také pozn´ amky na stranˇe 59). – pro ostatn´ı procesy nastavuje jen EUID, a uid mus´ı b´ yt bud’ rovné RUID nebo uschovanému SUID • int setgid(gid t gid ); obdoba setuid(), nastavuje group-IDs procesu. • int setgroups(int ngroups, gid t *gidset ) nastavuje supplementary GIDs procesu, m˚ uˇze b´ yt pouˇzito jen superuˇzivatelsk´ ym procesem.

• co v´ yˇse uvedené tedy znamen´ a: proces s efektivn´ımi pr´ avy superuˇzivatele m˚ uˇze libovolnˇe mˇenit identitu. Ostatn´ı procesory mohou pouze stˇr´ıdat sv´ a re´ aln´ a a efektivn´ı práva. • program login vyuˇz´ıv´ a vol´ an´ı setuid() • pokud chce process s UID == 0 zmˇenit svou identitu, mus´ı nejprve volat setgid() a setgroups(). Teprve pak lze zavolat setuid(). Pˇri opaˇcném poˇrad´ı vol´ an´ı by proces po proveden´ı setuid uˇz nemˇel práva na setgid() a setgroups(). • setgroups() nen´ı uvedeno v UNIX 98 ani UNIX 03. • RUID/EUID jsou uloˇzené v z´ aznamu tabulky proces˚ u pro pˇr´ısluˇsn´ y proces a z´ aroveˇ n v tzv. u-area (viz napˇr´ıklad [Bach]). EUID v tabulce proces˚ u se naz´ yv´ a jiˇz zm´ınˇené uschované UID, neboli saved UID. Jak jiˇz bylo ˇreˇceno, uschované UID se pouˇz´ıv´ a pro kontrolu, kdyˇz se proces chce vr´ atit k EUID, se kter´ ym byl spuˇstˇen (po té, co doˇcasnˇe nastavil své EUID na UID uˇzivatele, kter´ y proces spustil, tj. na RUID). • pokud tedy jako root vytvoˇr´ıte SUID program a v nˇem zavol´ ate setuid() pro jakéholi UID mimo 0, jiˇz se v programu k EUID==0 nem˚ uˇzete vr´ atit. V tom pˇr´ıpadˇe byste museli pouˇz´ıt volán´ı seteuid(), které nastavuje pouze EUID.

61

Syst´ em soubor˚ u • adres´ aˇre tvoˇr´ı strom, spolu se soubory acyklick´ y graf (na jeden soubor m˚ uˇze existovat v´ıce odkaz˚ u). • kaˇzd´ y adres´ aˇr nav´ıc obsahuje odkaz na sebe ’.’ (teˇcka) a na nadˇrazen´ y adres´ aˇr ’..’ (dvˇe teˇcky). • pomoc´ı rozhran´ı systému soubor˚ u se pˇristupuje i k dalˇs´ım entit´ am v systému: – – – – – –

perifern´ı zaˇr´ızen´ı pojmenované roury sokety procesy (/proc) pamˇet’ (/dev/mem, /dev/kmem) pseudosoubory (/dev/tty, /dev/fd/0,. . . )

• z pohledu j´ adra je kaˇzd´ y obyˇcejn´ y soubor pole bajt˚ u. • vˇsechny (i s´ıt’ové) disky jsou zapojeny do jednoho stromu.

• root m˚ uˇze v nˇekter´ ych systémech strukturu adres´ aˇr˚ u zacyklit, ale t´ım zmate utility pro proch´ azen´ı filesystému; moc se cyklické struktury nepouˇz´ıvaj´ı. Symbolické linky na adres´ aˇre funguj´ı vˇsude. • pojmenované roury (viz strana 81) lze pouˇz´ıt i mezi procesy, které nejsou pˇr´ıbuzensky spˇr´ıznˇené. Jinak funguj´ı stejnˇe jako nepojmenované roury. • zmiˇ nované sokety jsou v doménˇe UNIX, tj. slouˇz´ı pro komunikaci v r´ amci jednoho systému. Sokety z domény INET, pˇres které prob´ıhá s´ıt’ová komunikace, se v systému soubor˚ u neobjevuj´ı. S´ıt’ová komunikace zaˇc´ıná na stranˇe 155. • debuggery pouˇz´ıvaj´ı pamˇet’ové obrazy proces˚ u dostupné v /proc. Ve vˇetˇsinˇe unix-like systém˚ u obsahuje podstrom /proc u ´ daje o jádru systému a bˇeˇz´ıc´ıch procesech ve formˇe textov´ ych soubor˚ u. • dneˇsn´ı modern´ı unixy m´ıvaj´ı speci´ aln´ı filesystém devfs, jehoˇz obsah odráˇz´ı aktuáln´ı konfiguraci systému co se t´ yˇce pˇripojen´ ych zaˇr´ızen´ı. Tj. napˇr. pˇri pˇripojen´ı USB sticku se v /dev objev´ı pˇr´ısluˇsné diskové zaˇr´ızen´ı. Po fyzickém odpojen´ı zaˇr´ızen´ı odkaz z adres´ aˇrové struktury opˇet zmiz´ı.

62

Jednotn´ y hierarchick´ y syst´ em soubor˚ u /

etc

dev

usr

home

tty

• svazek (angl. file system) je ˇca´st souborového systému, kterou lze samostatnˇe vytvoˇrit, pˇripojit, zruˇsit... Kaˇzd´ y filesystém m˚ uˇze m´ıt jinou vnitˇrn´ı strukturu (s5, ufs, ext2, xfs, atd.) a m˚ uˇze b´ yt uloˇzen na lokáln´ım disku nebo na jiném poˇc´ıtaˇci a pˇr´ıstupn´ y po s´ıti (nfs, afs). • po startu j´ adra je pˇripojen´ y jen koˇrenov´ y filesystém, dalˇs´ı filesystémy se zapojuj´ı do hierarchie na m´ısta adres´ aˇr˚ u pˇr´ıkazem mount. Tento pˇr´ıkaz je moˇzné spustit ruˇcnˇe (uˇzivatel root libovolnˇe, ostatn´ı pouze na nˇekter´ ych systémech a s omezen´ımi) nebo automaticky bˇehem inicializace systému (ˇr´ıd´ı se obsahem souboru /etc/fstab). Pˇred zastaven´ım systému se filesystémy odpojuj´ı pˇr´ıkazem umount. • dalˇs´ı moˇznost je pˇripojen´ı filesystému na ˇza´dost (pˇri prvn´ım pˇr´ıstupu) a jeho odpojen´ı po urˇcité dobˇe neˇcinnosti. Tuto funkci zajiˇst’uje démon automounter (autofs, automount, amd). • UNIX nem´ a ˇza´dné A, B, C, D. . . disky apod.

63

Typick´ a skladba adres´ aˇ r˚ u /bin

...

z´ akladn´ı systémové pˇr´ıkazy

/dev

...

speci´ aln´ı soubory (zaˇr´ızen´ı, devices)

/etc

...

konfiguraˇcn´ı adres´ aˇr

/lib

...

z´ akladn´ı systémové knihovny

/tmp

...

veˇrejn´ y adres´ aˇr pro doˇcasné soubory

/home

...

koˇren domovsk´ ych adres´ aˇr˚ u

/var/adm

...

administrativn´ı soubory (ne na BSD)

/usr/

...

knihovny header˚ u pro C

/usr/local

...

lokálnˇe instalovan´ y software

/usr/man

...

manu´ alové str´ anky

/var/spool

...

spool (poˇsta, tisk,...)

• v /bin, /lib, /sbin jsou pˇr´ıkazy a knihovny potˇrebné pˇri startu systému, kdy je pˇripojen pouze koˇrenov´ y filesystém. Ostatn´ı pˇr´ıkazy a knihovny jsou typicky v /usr/bin, /usr/lib a /usr/sbin (/usr b´ yv´ a ˇcasto samostatn´ y filesystém, ˇc´ımˇz jeho obsah nen´ı dostupn´ y bˇehem startu systému). • podstrom /usr obsahuje soubory, které se nemˇen´ı pˇri bˇeˇzném provozu a nejsou z´ avislé na konkrétn´ım poˇc´ıtaˇci. Proto by mˇel j´ıt sd´ılet read-only. Na své stanici doma ho ale samozˇrejmˇe budete m´ıt read-write. • v podstromu /var jsou data, kter´ a se za provozu mˇen´ı a jsou specifická pro kaˇzd´ y poˇc´ıtaˇc. • r˚ uzné systémy (i instalace jednoho systému) se ˇcasto liˇs´ı. • hier(7) na FreeBSD popisuje adres´ aˇrovou hierarchii tohoto systému, Solaris má filesystem(5).

64

Pˇ r´ıstup k perifern´ım zaˇ r´ızen´ım • adres´ aˇr /dev obsahuje speci´ aln´ı soubory zaˇr´ızen´ı. Proces otevˇre speci´ aln´ı soubor systémov´ ym volán´ım open() a d´ ale komunikuje se zaˇr´ızen´ım pomoc´ı vol´ an´ı read(), write(), ioctl(), apod. • speci´ aln´ı soubory se dˇel´ı na – znakov´ e . . . data se pˇren´ aˇs´ı pˇr´ımo mezi procesem a ovladaˇcem zaˇr´ızen´ı, napˇr. sériové porty – blokov´ e . . . data proch´ az´ı systémovou vyrovn´ avac´ı pamˇet´ı (buffer cache) po bloc´ıch pevnˇe dané velikosti, napˇr. disky

• speci´ aln´ı soubor identifikuje zaˇr´ızen´ı dvˇema ˇc´ısly – hlavn´ı (major) ˇ c´ıslo . . . ˇc´ıslo ovladaˇce v j´ adru – vedlejˇ s´ı (minor) ˇ c´ıslo . . . ˇc´ıslo v r´ amci jednoho ovladaˇce

• vyrovn´ avac´ı pamˇeti urychluj´ı perifern´ı operace. Pˇri ˇcten´ı se data hledaj´ı nejprve v bufferu. Teprve kdyˇz nejsou k dispozici, tak se ˇctou z disku. Pˇri pˇr´ıˇst´ım ˇcten´ı stejného bloku jsou data v bufferu. Pˇri z´ apisu se data uloˇz´ı do bufferu. Na disk je systém pˇrep´ıˇse pozdˇeji. Lze si vynutit i okamˇzit´ y z´ apis dat na disk. • disky v UNIXu jsou obvykle pˇr´ıstupné pˇres znakové (pouˇz´ıvané pˇri mkfs – vytvoˇren´ı svazku – a fsck – kontrola konzistence) i blokové rozhran´ı (pouˇz´ıvané pˇri norm´ aln´ım provozu systému soubor˚ u). Nˇekteré systémy (FreeBSD) ale uˇz v /dev v˚ ubec soubory pro bloková zaˇr´ızen´ı nemaj´ı, pouze znaková. • dˇr´ıve musel administr´ ator systému po zmˇenˇe hardwarové konfigurace upravit obsah adres´ aˇre /dev skriptem MAKEDEV nebo ruˇcnˇe. Dnes (Linux, IRIX, FreeBSD, Solaris, . . . ) jiˇz speci´ aln´ı soubory dynamicky vznikaj´ı a zanikaj´ı podle toho, jak j´ adro detekuje pˇrid´ an´ı nebo odebr´ an´ı hardwarov´ ych komponent (viz devfs na stranˇe 62). • okamˇzit´ y z´ apis na disk lze vynutit pˇres O DIRECT command ve volán´ı fcntl()

65

Fyzick´ e uloˇ zen´ı syst´ emu soubor˚ u • syst´ em soubor˚ u (svazek, filesystem) lze vytvoˇrit na: – odd´ılu disku (partition) – ˇc´ ast disku, na jednom disku m˚ uˇze b´ yt v´ıce odd´ıl˚ u – logick´ em odd´ılu (logical volume) – takto lze spojit v´ıce odd´ıl˚ u, které mohou b´ yt i na nˇekolika disc´ıch, do jednoho svazku.

• dalˇs´ı moˇznosti: striping, mirroring, RAID /home

/

disk 1

/usr

disk 2

disk 3

• v´ yraz systém soubor˚ u se pouˇz´ıv´ a v nˇekolika v´ yznamech: – jeden filesystém, tj. to, co vyrob´ı pˇr´ıkaz mkfs – cel´ a hierarchie pˇripojen´ ych svazk˚ u v systému (v´ ystup pˇr´ıkazu mount) – zp˚ usob organizace svazku (tj. typ fs) a tomu odpov´ıdaj´ıc´ı modul jádra, kter´ y s daty manipuluje (UFS2, Ext3, XFS, ...) • striping je od slova stripe, ne strip; podle toho se také vyslovuje. Znamen´ a, ˇze za sebou n´ asleduj´ıc´ı bloky dat se ukl´ adaj´ı paralelnˇe na r˚ uzné disky a t´ım se zvyˇsuje pˇrenosová rychlost. • mirroring ukl´ ad´ a kopie dat pro pˇr´ıpad havárie prim´ arn´ıho disku. • paritn´ı disky: data se ukl´ adaj´ı na dva disky, na tˇret´ı se ukl´ ad´ a XOR prvn´ıch dvou, po havárii libovolného disku jsou vˇsechna data st´ ale ˇciteln´ a. • jednotlivé u ´ rovnˇe RAID (Redundant Array of Inexpensive Disks) zahrnuj´ı striping, mirroring a vyuˇzit´ı paritn´ıch disk˚ u. • na terminologii je tˇreba d´ at velk´ y pozor. Napˇr. to, co se v DOS svˇetˇe naz´ yv´ a partition, se v BSD naz´ yv´ a slice. Tam jsou pak partitions definovány v r´ amci jednoho slice a v nich se vytváˇrej´ı filesystémy. • pokud vás to zaj´ım´ a nebo se s t´ım setk´ av´ ate v praxi, doporuˇcuji vaˇs´ı pozornosti ZFS, coˇz je filesystém a manaˇzer logick´ ych odd´ıl˚ u v jednom. Ze Solarisu se jiˇz dostal do FreeBSD od verze 7.0 a také do Mac OS X Leopard (kter´ y byl ofici´ alnˇe vydán v ˇr´ıjnu 2007). M˚ uˇzete okamˇzitˇe zapomenout na jednotlivé disky, co je d˚ uleˇzité je pouze celková disková kapacita v systému.

66

Organizace syst´ emu soubor˚ u s5 blok ˇc. zavádˇec´ı blok (boot block) 0 superblok 1 2 oblast i-uzl˚ u (i-nodes)

0

9 12

... oblast datových blok˚ u

• p˚ uvodn´ı UNIXov´ y systém soubor˚ u standardnˇe pouˇz´ıvan´ y do verze System V Release 3; v BSD se prim´ arnˇe pouˇz´ıval do verze 4.1 • vlastnosti: – bloky délky 512, 1024 nebo 2048 bajt˚ u – jedin´ y (neduplikovan´ y) superblok – datov´ y prostor pevnˇe rozdˇelen´ y na oblast i-uzl˚ u a oblast datových blok˚ u – pˇri velikosti bloku 1024 bajt˚ u byla teoretická velikost filesystému pˇres 16 GB • boot block – pro uloˇzen´ı zavadˇeˇce OSu • superblok – z´ akladn´ı informace o svazku: poˇcet blok˚ u pro i-uzly, poˇcet blok˚ u svazku, seznam voln´ ych blok˚ u (pokraˇcuje ve voln´ ych bloc´ıch), seznam voln´ ych i-uzl˚ u (po vyˇcerp´ an´ı se prohled´ av´ a tabulka i-uzl˚ u), z´ amky pro seznamy voln´ ych blok˚ u a i-uzl˚ u, pˇr´ıznak modifikace (pro kontrolu korektn´ıho odpojen´ı svazku), ˇcas posledn´ı aktualizace, informace o zaˇr´ızen´ı • i-uzel – typ souboru, pˇr´ıstupová práva, vlastn´ık, skupina, ˇcasy posledn´ıho pˇr´ıstupu, modifikace dat a modifikace i-uzlu (ˇcas vytvoˇren´ı souboru nen´ı uloˇzen), poˇcet odkaz˚ u na soubor, velikost souboru, 10 odkaz˚ u na datové bloky a 3 odkazy na nepˇr´ımé bloky • maxim´ aln´ı velikost souboru: 2113674 blok˚ u, tj. pˇribliˇznˇe 1 GB pˇri pouˇzit´ı blok˚ u velikosti 512 B • jména soubor˚ u – max. 14 znak˚ u (14 + 2 = 16, tedy mocnina dvou a tedy bezproblémové uloˇzn´ı adres´ aˇrov´ ych poloˇzek do blok˚ u) 67

• pˇri pouˇzit´ı tohoto filesystému byla v´ ykonnost disk˚ u vyuˇzita jen cca na 2% a rychlost ˇcten´ı byla v ˇra´du jen nˇekolika des´ıtek kilobajt˚ u za sekundu (!!!) • pro srovn´ an´ı – MS-DOS 2.0 z roku 1983 podporoval pouze FAT12, poˇc´ıtaj´ıc´ı s maxim´ aln´ı velikost´ı filesystému 16 MB. Velikost svazku do 2 GB byla umoˇznˇena aˇz ve verzi 4.0 (1988); tato verze z´ aroveˇ n zavedla diskové vyrovn´ avac´ı pamˇeti, tedy to, co UNIX má od svého vzniku v roce 1970. . .

Navigace v adres´ aˇ rov´ e struktuˇ re /etc/passwd

i-nodes i-node 2

data

i-node 37

i-node 71

. ..

2 2

. ..

37 2

etc

37

passwd

71

root:x:0:...

• kdyˇz cesta zaˇc´ıná znakem ’/’, zaˇc´ıná navigace v koˇrenovém adres´ aˇri, jinak zaˇcne v pracovn´ım adres´ aˇri procesu. • koˇrenov´ y adres´ aˇr má typicky ˇc´ıslo 2. 0 je pro oznaˇcen´ı prázdného uzlu a 1 byla dˇr´ıve pouˇz´ıvan´ a pro soubor, do kterého se vkl´ adaly vadné bloky, aby je systém uˇz d´ ale nepouˇz´ıval. • cesta ve které je v´ıce lom´ıtek za sebou je stále platná, tj. ///a///b///c je ekvivaletn´ı /a/b/c.

68

Linky hard link /var password

originál /etc 20

passwd

... i-nodes

0

data

symbolický link /usr 20

... 20

...

passwd

31

... ...

root:x:0:...

31 ../etc/passwd

Hard linky lze vytváˇret pouze v r´ amci jednoho (logického) filesystému.

hardlink • odkaz na stejn´ y i-uzel • vlastnˇe druhé jméno souboru • nen´ı rozd´ıl mezi originálem a hardlinkem • lze vytváˇret jen v r´ amci filesystému • nelze vytváˇret pro adres´ aˇre symbolick´ y link (symlink, softlink) • pouze odkaz na skuteˇcnou cestu k souboru jiného typu (ls -l ho oznaˇcuje ’l’), tj. symbolick´ y link je typem odliˇsn´ y od bˇeˇzného souboru a jeho data obsahuj´ı obyˇcejn´ y ˇretˇezec – jméno cesty, at’ jiˇz relativn´ı nebo absolutn´ı • odliˇsné chován´ı pro originál a link (napˇr. pˇri maz´ an´ı) • pozor na relativn´ı a absolutn´ı cesty pˇri pˇresouván´ı symbolického linku • m˚ uˇze ukazovat i na adres´ aˇr nebo na neexistuj´ıc´ı soubor Nejjednoˇsˇs´ı zp˚ usob jak si ovˇeˇrit, zda dané dva linky ukazuj´ı na stejn´ y soubor na disku je pouˇz´ıt -i pˇrep´ınaˇc pˇr´ıkazu ls. $ ls -i /etc/passwd 172789 /etc/passwd

69

Vylepˇ sen´ı syst´ emu soubor˚ u • c´ıl: sn´ıˇzen´ı fragmentace soubor˚ u, omezen´ı pohybu hlav disku um´ıstˇen´ım i-uzl˚ u a datov´ ych blok˚ u bl´ıˇz k sobˇe • UFS (Unix File System), p˚ uvodnˇe Berkeley FFS (Fast File System) • ˇclenˇen´ı na skupiny cylindr˚ u, kaˇzd´ a skupina obsahuje – kopii superbloku – ˇr´ıdic´ı blok skupiny – tabulku i-uzl˚ u – bitmapy voln´ ych i-uzl˚ u a datov´ ych blok˚ u – datové bloky • bloky velikosti 4 aˇz 8 kB, fragmenty blok˚ u • jména dlouh´ a 255 znak˚ u

• superblok v kaˇzdé cylinder skupinˇe posunut tak, aby superbloky nebyly na stejné plotnˇe • dalˇs´ı typy filesystém˚ u: UFS2, Ext3, ReiserFS, XFS, ZFS aj. • v http://www.devnull.cz/mff/pvu/common/docs/filesystems.ps je porovn´ an´ı osmi r˚ uzn´ ych filesystém˚ u podle r˚ uzn´ ych implementaˇcn´ıch kritéri´ı; nezahrnuje v sobˇe ale v´ yvoj posledn´ıch let. • UFS byl st´ ale 32-bitov´ y, coˇz se odráˇzelo na maxim´ aln´ı délce souboru i na maxim´ aln´ı velikosti filesystému • ˇzurn´ alován´ı (XFS, Ext3, ReiserFS) – snaha o zmenˇsen´ı nebezpeˇc´ı ztr´ aty dat v pˇr´ıpadˇe havárie, urychlen´ı zotaven´ı po havárii • ZFS – modern´ı 128-bitov´ y filesystém vyvinut´ y Sunem, nyn´ı open-source, v Solarisu 10, ted’ jiˇz také v Mac OS X 10.5 a FreeBSD 7.

70

V´ yvoj ve spr´ avˇ e adres´ aˇ rov´ ych poloˇ zek • maxim´ aln´ı délka jména souboru 14 znak˚ u nebyla dostaˇcuj´ıc´ı • FFS – délka aˇz 255; kaˇzd´ a poloˇzka z´ aroveˇ n obsahuje i jej´ı délku • nové filesystémy pouˇz´ıvaj´ı pro vnitˇrn´ı strukturu adres´ aˇr˚ u r˚ uzné varianty B-strom˚ u – v´ yraznˇe zrychluje práci s adres´ aˇri obsahuj´ıc´ı velké mnoˇzstv´ı soubor˚ u – XFS, JFS, ReiserFS, . . . • UFS2 zavád´ı zpˇetnˇe kompatibiln´ı tzv. dirhash pro zrychlen´ı pˇr´ıstupu k adres´ aˇr˚ um s velk´ ym poˇctem soubor˚ u

• dirhash pracuje tak, ˇze pˇri prvn´ım pˇreˇcten´ı adres´ aˇre se vytvoˇr´ı v pamˇeti hash struktura, n´ asledné pˇr´ıstupy do adres´ aˇre jsou pak srovnatelné se systémy pouˇz´ıvaj´ıc´ı B-stromy. T´ımto zp˚ usobem je dosaˇzeno zlepˇsen´ı bez toho, aby se mˇenila struktura filesystému na disku. Nelze to ale takto dˇelat do nekoneˇcna, bude zaj´ımavé jestli FreeBSD v budoucnu pˇrejde na ZFS jako jejich hlavn´ı filesystém. • malé soubory se ˇcasto ukl´ adaj´ı v i-nodech, ˇc´ımˇz se uˇsetˇr´ı dalˇs´ı pˇr´ıstupy na disk

71

Virtu´ aln´ı syst´ em soubor˚ u (Virtual File System) struct struct struct struct struct file file file file file *file f vnode f vnode f vnode f vnode VNODE

VNODE

VNODE

VNODE

VNODE

v data INODE

v data INODE

v data INODE

v data INODE

v data INODE s realvp

ufs vnodeops ufs file system

s5 vnodeops s5 file system

spec vnodeops spec file system

• FFS uveden´ y ve 4.2BSD byl historicky druh´ y unixov´ y filesystém. Nˇekteˇr´ı dodavatelé unixov´ ych systém˚ u ho zaˇcali preferovat vzhledem k jeho lepˇs´ımu v´ ykonu a nov´ ym moˇznostem, jin´ y z˚ ust´ avali d´ ale u s5fs z d˚ uvodu zpˇetné kompatibility. To d´ ale prohlubovalo problém jiˇz tak nedostateˇcné interoperability mezi r˚ uzn´ ymi unixov´ ymi systémy. Nˇekter´ ym aplikac´ım nav´ıc plnˇe nevyhovoval ani jeden z tˇechto filesystém˚ u. Postupnˇe se také objevovala potˇreba pracovat s ne-unixov´ ymi filesystémy, napˇr. FAT. A s rostouc´ı popularitou poˇc´ıtaˇcov´ ych s´ıt´ı se zvyˇsovala poptávka po sd´ılen´ı soubor˚ u mezi jednotliv´ ymi systémy, coˇz mˇelo za n´ asledek vznik distribuovan´ ych filesystém˚ u – napˇr. NFS (Network File System). • FFS zaveden´ y do systému s VFS se zaˇcal naz´ yvat UFS. • vzhledem k v´ yˇse popsané situaci bylo jen otázkou ˇcasu, kdy dojde k fundament´ aln´ım zmˇen´ am v infrastruktuˇre systému soubor˚ u, aby souˇcasnˇe podporoval v´ıce typ˚ u filesystém˚ u. Vzniklo nˇekolik r˚ uzn´ ych implementac´ı od r˚ uzn´ ych v´ yrobc˚ u, aˇz se nakonec de facto standardem stala VFS/vnode architektura od firmy Sun Microsystems. V dneˇsn´ı dobˇe prakticky vˇsechny unixové a unixlike systémy podporuj´ı VFS, i kdyˇz ˇcasto se vz´ ajemnˇe nekompatibiln´ımi u ´ pravami. VFS se poprvé objevilo v roce 1985 v Solarisu 2.0; brzy bylo pˇrevzato BSD – FFS s podporou VFS je právˇe UFS. • hlavn´ı myˇslenka: kaˇzdému otevˇrenému souboru v systému pˇr´ısluˇs´ı struktura file (to by vlastnˇe byl jeden slot v n´ ami jiˇz zn´ amé systémové tabulce otevˇren´ ych soubor˚ u). Ta ukazuje na vnode (virtual node). Vnode obsahuje ˇca´st nez´ avislou na konkrétn´ım systému soubor˚ u a ˇca´st z´ avislou, coˇz m˚ uˇze b´ yt napˇr´ıklad struktura inode. Ta je specifická pro kaˇzd´ y typ souborového systému. Kaˇ zd´ y typ filesyst´ emu implementuje pevnˇ e danou

72

sadu funkc´ı pro jednotliv´ e operace nad soubory, na kterou se odkazuj´ı vˇsechny virtu´ aln´ı uzly odpov´ıdaj´ıc´ı danému typu filesystému. Tato sada funkc´ı tedy definuje vnode interface. Kdyˇz tedy zavoláte napˇr´ıklad open(), j´ adro zavol´ a pˇr´ısluˇsnou implementaci v z´ avislosti na typu filesystému (napˇr. z modulu ext2fs). Implementaˇcnˇe z´ avislá ˇca´st struktury vnode je pˇr´ıstupn´ a pouze z funkc´ı pˇr´ısluˇsného typu filesystému; jádro do n´ı tedy ,,nevid´ı” pˇr´ımo. Jak uvid´ıte na dalˇs´ım slajdu, existuje jeˇstˇe jedna sada funkc´ı, kter´ a se t´ yka práce s filesystémy jako takov´ ymi. Ta pak definuje VFS interface. Tyto dvˇe sady spoleˇcnˇe tvoˇr´ı vnode/VFS rozhran´ı, kterému se bˇeˇznˇe ˇr´ık´ a jen VFS. • (nebudu zkouˇset) – u speci´ aln´ıch soubor˚ u je situace sloˇzitˇejˇs´ı, v SVR4 struktura file ukazuje na snode (shadow-special-vnode), kter´ y definuje operace se zaˇr´ızen´ım (pomoc´ı souborového systému spec) a prostˇrednictv´ım ukazatele aln´ y vnode pro operace se speci´ aln´ım souborem; s realvp se odkazuje na re´ ten je potˇreba napˇr´ıklad pro kontrolu práv pˇr´ıstupu. Kaˇzdému zaˇr´ızen´ı m˚ uˇze odpov´ıdat v´ıce speci´ aln´ıch soubor˚ u, a tedy v´ıce snodes a pˇr´ısluˇsn´ ych reáln´ ych vnodes. Vˇsechny takové snodes pro jedno zaˇr´ızen´ı maj´ı ukazatel s commonvp na jeden spoleˇcn´ y snode (toto nen´ı na obr´ azku zachyceno). Pˇri otevˇren´ı speci´ aln´ıho souboru se hled´ a v hash tabulce snodes otevˇren´ ych zaˇr´ızen´ı poloˇzka odpov´ıdaj´ıc´ı speci´ aln´ımu souboru (podle major a minor ˇc´ısla zaˇr´ızen´ı). Kdyˇz snode nen´ı nalezen, vytvoˇr´ı se nov´ y. Tento snode se pak pouˇz´ıv´ a pˇri operac´ıch se zaˇr´ızen´ım. V´ıce viz napˇr´ıklad [Vahalia].

Hierarchie souborov´ ych syst´ em˚ u struct file f vnode

vfs mount list rootvfs VFS

v vfsp VNODE

VFS

vfs next vfs data

vfs data

root vnode super block

root vnode super block

vfs op

v op

vfs next

INODE

vnodeops vfs mountedhere

vfs op

vfs vnodecovered v vfsp

vfsops

VNODE

vfsops

v op INODE

vfssw[]

vsw vfsops

mount point in rootvfs

vnodeops

• struktura vfs obsahuje implementaˇcnˇe nezávislé informace o filesystému, nez´ avislé na konkrént´ım typu filesystému (podobnˇe jako vnode funguje pro soubory). Tato struktura nereprezentuje konkrétn´ı typ filesystému, ale filesystém pˇrimontovan´ y do hierarchie soubor˚ u. V tomto vázaném seznamu tedy m˚ uˇze b´ yt v´ıce struktur stejného typu souborového systému. 73

• rootvfs – odkaz na root file system • vfsops – tabulka funkc´ı pro konkrétn´ı typ systému soubor˚ u • vfssw[] – pole odkaz˚ u na tabulky vfsops pro vˇsechny systémem podporované typy filesystém˚ u, z tabulky se vyb´ır´ a pˇri pˇripojován´ı svazku podle typu filesystému zadaného pˇri vol´ an´ı mount() • v vfsp – odkaz z vnode na filesystém (strukturu vfs), na kterém leˇz´ı soubor reprezentovan´ y pomoc´ı vnode y reprezentuje mount point (ad• v vfsmountedhere – pouze ve vnode, kter´ res´ aˇr, na kterém je pˇripojen koˇren jiného filesystému); odkazuje na strukturu vfs reprezentuj´ıc´ı pˇripojen´ y filesystém • v vnodecovered – odkaz na vnode adres´ aˇre, na kterém je filesystém pˇripojen

Otevˇ ren´ e soubory z pohledu j´ adra I. user file descriptor table file table : count 1 process A WRONLY Z Z Z Z ZZ ~ count 2 3 RDONLY process B - count 1 RDWR

inode table @ @ @ R count 1 @

/etc/group

Q Q QQ s

count 3

: /etc/passwd

• toto je nejjednoduˇsˇs´ı pohled na tabulky v jádˇre které se t´ ykaj´ı soubor˚ u, je to pˇrevzato z [Bach]; dnes to je o nˇeco sloˇzitˇejˇs´ı, myˇslenka je ale poˇra´d stejn´ a. Realitˇe v´ıce se podobaj´ıc´ı obr´ azek je na pˇr´ıˇst´ım slajdu. • kaˇzd´ y proces má svoji tabulku souborov´ ych deskriptor˚ u (user file descriptor table) • z této tabulky je odkazovn´ ano na systémovou tabulku otevˇren´ ych soubor˚ u systému (file table; ano, tato tabulka je pouze jedna). Zde je mód otevˇren´ı souboru a také aktu´ aln´ı pozice v souboru. • z tabulky otevˇren´ ych soubor˚ u je odkazováno do tabulky naˇcten´ ych inod˚ uv pamˇeti (dnes jsou to tzv. vnodes – virtual nodes, ale to n´ am nyn´ı m˚ uˇze b´ yt u ´ plnˇe jedno) 74

• tabulka otevˇren´ ych soubor˚ u systému, kter´ a vlastnˇe vytváˇr´ı o jednu u ´ roveˇ n odkaz˚ u nav´ıc, je zde proto, aby r˚ uzné procesy mohly sd´ılet stejnou aktuáln´ı pozici v souboru. • pˇri otevˇren´ı souboru pomoc´ı volán´ı open() se vˇzdy alokuje nov´ y slot v tabulce deskriptor˚ u a také v systémové tabulce otevˇren´ ych soubor˚ u (to je d˚ uleˇzité!). Sd´ılen´ı se pak v r´ amci jednoho procesu dos´ ahne duplikac´ı deskriptor˚ u, kdy v´ıce deskriptor˚ u sd´ıl´ı stejn´ y slot v tabulce otevˇren´ ych soubor˚ u systému nebo v pˇr´ıpadˇe r˚ uzn´ ych proces˚ u pak pomoc´ı vytvoˇren´ı nového procesu pomoc´ı vol´ an´ı fork(), viz strana 119.

Otevˇ ren´ e soubory z pohledu j´ adra II. struct proc uf next

uf next

struct ufchunk

struct ufchunk

struct ufchunk

... 2 1 0

... 2 1 0

... 2 1 0

u proc

u first

struct user p cred uf ofile[]

struct cred

f cred

f next

struct file

struct file

struct file

struct file

struct file

VNODE

VNODE

VNODE

VNODE

f prev

VNODE

struct file *file

f vnode

• struktury proc a user vytváˇr´ı jádro pro kaˇzd´ y proces a drˇz´ı v nich sluˇzebn´ı informace o procesu. • struktura ufchunk obsahuje NFPCHUNK (obvykle 24) deskriptor˚ u soubor˚ u, po zaplnˇen´ı se alokuje dalˇs´ı ufchunk. • struktura file (otevˇren´ı souboru) obsahuje mód souboru (otevˇren pro ˇcten´ı, z´ apis, atd.), poˇcet deskriptor˚ u, které se na ni odkazuj´ı, ukazatel na vnode a pozici v souboru. Jedno otevˇren´ı souboru m˚ uˇze b´ yt sd´ıleno v´ıce deskriptory, jestliˇze byl p˚ uvodn´ı deskriptor zkop´ırován, napˇr. volán´ım fork() nebo dup(). • struktura cred obsahuje uˇzivatelskou a skupinovou identitu procesu, kter´ y otevˇrel soubor. • jeden vnode odpov´ıdaj´ıc´ı jednomu souboru m˚ uˇze b´ yt sd´ılen nˇekolika strukturami file, pokud byl dan´ y soubor v´ıcekrát otevˇren. • ne vˇsechny vnodes jsou asociovány s tabulkou otevˇren´ ych soubor˚ u. Napˇr. pˇri spuˇstˇen´ı programu je potˇreba pˇristupovat do spustitelného souboru a proto se alokuje vnode. 75

Oprava konzistence souborov´ eho syst´ emu • pokud nen´ı filesystém pˇred zastaven´ım systému korektnˇe odpojen, mohou b´ yt data v nekonzistentn´ım stavu. • ke kontrole a opravˇe svazku slouˇz´ı pˇr´ıkaz fsck. Postupnˇe testuje moˇzné nekonzistence: – v´ıcen´ asobné odkazy na stejn´ y blok – odkazy na bloky mimo rozsah datové oblasti systému soubor˚ u – ˇspatn´ y poˇcet odkaz˚ u na i-uzly – nespr´ avn´ a velikost soubor˚ u a adres´ aˇr˚ u – neplatn´ y formát i-uzl˚ u – bloky které nejsou obsazené ani volné – chybn´ y obsah adres´ aˇr˚ u – neplatn´ y obsah superbloku • operace fsck je ˇcasovˇe n´ aroˇcn´ a. • ˇzurn´ alové systémy soubor˚ u (napˇr. XFS v IRIXu, Ext3 v Linuxu) nepotˇrebuj´ı fsck.

• data se pˇrepisuj´ı na disky z vyrovnávac´ıch pamˇet´ı se zpoˇzdˇen´ım. Uloˇzen´ı vˇsech vyrovn´ avac´ıch pamˇet´ı lze vynutit systémov´ ym volán´ım sync(). Periodicky vyrovn´ avac´ı pamˇeti ukl´ ad´ a zvláˇstn´ı systémov´ y proces (démon). • zde je uk´ azka fsck na odpojen´ y filesystém: toor@shewolf:~# fsck /dev/ad0a ** /dev/ad0a ** Last Mounted on /mnt/flashcard ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 24 files, 8848 used, 12951 free (7 frags, 1618 blocks, 0.0% fragmentation)

76

Dalˇ s´ı zp˚ usoby zajiˇ stˇ en´ı konzistence filesyst´ emu • tradiˇcn´ı UFS – synchronn´ı z´ apis metadat – aplikace vytváˇrej´ıc´ı nov´ y soubor ˇcek´ a na inicializaci inode na disku; tyto operace pracuj´ı rychlost´ı disku a ne rychlost´ı CPU – asynchronn´ı z´ apis ale ˇcastˇeji zp˚ usob´ı nekontistenci metadat • ˇreˇsen´ı problém˚ u s nekonzistenc´ı metadat na disku: – journalling – skupina na sobˇe z´ avisl´ ych operac´ı se nejdˇr´ıve atomicky uloˇz´ı do ˇzurn´ alu; pˇri problémech se pak ˇzurn´ al m˚ uˇze “pˇrehrát” – bloky metadat se nejdˇr´ıve zap´ıˇs´ı do non-volatile pamˇeti – soft-updates – sleduje z´ avislosti mezi ukazately na diskové struktury a zapisuje data na disk metodou write-back tak, ˇze data na disku jsou vˇzdy konzistentn´ı – ZFS je nov´ y filesystém v Solarisu, kter´ y pouˇz´ıv´ a copy-on-write

• filesystem metadata = inodes, directories, free block maps • ext2 dokonce defaultnˇe pouˇz´ıv´ a asynchronn´ı z´ apis metadat a je pˇri pouˇz´ıt´ı synchronn´ıho z´ apisu v´ yraznˇe pomalejˇs´ı neˇz UFS • z´ avislé operace jsou napˇr´ıklad smaz´ an´ı poloˇzky z adres´ aˇre a smaz´ an´ı diskového inode. Pokud by se stalo, ˇze se nejdˇr´ıve smaˇze diskov´ y inode a pak teprve poloˇzka v adres´ aˇri, pˇri v´ ypadku mezi tˇemito dvˇemi operacemi vnik´ a nekonzistence – link ukazuje na diskov´ y soubor, kter´ y neexistuje. Nen´ı problém se tomuto vyhnout pˇri synchronn´ım z´ apisu metadat (v´ıme kdy a co zapisujeme, urˇcujeme tedy poˇrad´ı z´ apisu), ale pˇri metodˇe write-back je jiˇz nutné ˇreˇsit z´ avislosti jednotliv´ ych blok˚ u na sebe, protoˇze pˇri klasické synchronizaci vyrovn´ avac´ıch pamˇet´ı na disk jádro nezaj´ım´ a, kter´ y blok se zap´ıˇse dˇr´ıv a kter´ y pozdˇeji. • ˇcasto jsou bloky na sobˇe z´ avislé ve smyˇcce. Soft updates dok´ aˇze takovou smyˇcku rozb´ıt t´ım, ˇze provede roll-back a po z´ apisu pak roll-forward • v´ ykon soft updates je srovnateln´ y v´ ykonu UFS filesystému s asynchronn´ım z´ apisem metadat • teoreticky soft updates zaruˇcuj´ı, ˇze po rebootu nen´ı potˇreba pouˇz´ıt fsck, tj. ˇze filesystém bude v takovém stavu, ˇze je moˇzné nabootovat. Je vˇsak nutné pouˇz´ıt tzv. background fsck pro opravy nezávaˇzn´ ych chyb – to je povaˇzováno st´ ale za velkou nev´ yhodu soft updates zvláˇstˇe s t´ım, jak rostou velikosti bˇeˇznˇe pouˇz´ıvan´ ych disk˚ u. Takovou chybou, kter´ a nebr´ an´ı nabootován´ı, ale je nutné ji odstranit je napˇr´ıklad blok, kter´ y je oznaˇcen jako pouˇzit´ y, ale ˇza´dn´ y soubor ho nepouˇz´ıv´ a.

77

• soft updates nejsou vˇzdy doporuˇcovány pro root filesystém. Problém je to, ˇze ztr´ ata metadat na root filesystému (viz 30-ti sekundová perioda z´ apisu) m˚ uˇze b´ yt v´ yraznˇe vˇetˇs´ı hrozbou zde neˇz na /usr, /home atd. Dalˇs´ı nev´ yhodou m˚ uˇze b´ yt i to, ˇze u soft updates mi smaz´ an´ı velkého souboru hned neuvoln´ı m´ısto. • pˇr´ıklad: na bezpeˇcnou operaci rename potˇrebuju pˇri synchronn´ım z´ apisu metadat 4 z´ apisy – zv´ yˇsen´ı poˇctu odkaz˚ u v inode, vytvoˇren´ı nové adres´ aˇrové poloˇzky, smaz´ an´ı staré, a opˇetné sn´ıˇzen´ı poˇctu odkaz˚ u v inode. Kdykoli by systém spadnul, nenastane nebezpeˇcn´ a situace. Napˇr´ıklad 2 odkazy z adres´ aˇr˚ u na inode s referenˇcn´ım poˇctem 1 je problém, protoˇze po zruˇsen´ı jednoho odkazu to bude vypadat, ˇze soubor je stále na disku, kdyˇz uˇz byls jeho data d´ avno smaz´ ana. Nen´ı teˇzké si asi pˇredstavit, co by to mohlo znamenat v pˇr´ıpadˇe, ˇze soubor obsahoval opravdu d˚ uleˇzit´ a data – napˇr´ıklad z´ alohu. Opaˇcn´ a situace, tj. jeden odkaz na inode s referenc´ı 2 sice také nen´ı spr´ avn´ a situace, ale neohroˇzuje to moˇznost filesystém namontovat a normálnˇe pouˇz´ıvat. V nejhorˇs´ım se stane, ˇze soubor vypad´ a ˇze jiˇz na disku nen´ı a pˇritom stále existuje. U soft updates operace rename vytvoˇr´ı kruˇznici, protoˇze nejdˇr´ıve je potˇreba zapsat zv´ yˇsen´ı poˇctu referenc´ı, pak adres´ aˇrové bloky a poté sn´ıˇzen´ı referenc´ı. A protoˇze zv´ yˇsen´ı/sn´ıˇzen´ı se t´ yk´ a stejného inode, tak je pˇri z´ apisu tˇreba udˇelat roll-back na (ˇreknˇeme) 2, zapsat inode na disk, zapsat bloky adres´ ar˚ u a pak roll-forward na poˇcet referenc´ı 1. Pˇri této akci je nad inodem drˇzen z´ amek, takˇze nikdo nenaˇcte starˇs´ı data. Je jednoduché ukázat, ˇze nelze zapsat ˇza´dn´ y z tˇech tˇr´ı blok˚ u v kruˇznici tak, jak to je na konci operace rename, ˇze je opravdu nutn´ y ten roll-back – mohli bychom uvaˇzovat, ˇze inode se vlastnˇe nezmˇenil a nen´ı tˇreba ˇreˇsit zda se m˚ uˇze/nem˚ uˇze zapsat; z´ apis nového adres´ aˇrového odkazu bez zv´ yˇsen´ı poˇctu odkaz˚ u v inodu by n´ as totiˇz mohl dostat pˇresnˇe do situace, kter´ a je pops´ ana o p´ ar ˇra´dk˚ u v´ yˇse.

Pˇ r´ıstupov´ a pr´ ava nejvyˇsˇs´ı bit

vlastn´ık (u) skupina (g) ostatn´ı (o) z }| { z }| { z }| {

4 2

suid sgid sticky

1

r w x

• SGID pro soubor bez práva spuˇstˇen´ı pro skupinu v System V: kontrola z´ amk˚ u pˇri kaˇzdém pˇr´ıstupu (mandatory locking) • sticky bit pro adres´ aˇre: právo mazat a pˇrejmenovávat soubory maj´ı jen vlastn´ıci soubor˚ u • SGID pro adres´ aˇr: nové soubory budou m´ıt stejnou skupinu jako adres´ aˇr (System V; u BSD systém˚ u to funguje jinak, viz pozn´ amky)

78

• SGID pro adres´ aˇre u BSD systém˚ u zp˚ usob´ı, ˇze soubory a podadres´ aˇre vytvoˇrené v tomto adres´ aˇri budou m´ıt stejného majitele jako je majitel daného adres´ aˇre. Nutn´ ym pˇredpokladem je d´ ale to, ˇze dan´ y UFS filesystém mus´ı b´ yt namontován s suiddir pˇr´ıznakem a v jádru je option SUIDDIR (a to nen´ı default). Nav´ıc to nefunguje pro roota. Tato moˇznost existuje kv˚ uli Sambˇe a Nettalku. • sticky bit pro adres´ aˇre: pˇrejmenovat nebo smazat soubor m˚ uˇze jen jeho vlastn´ık (v nˇekter´ ych implementac´ıch staˇc´ı i právo z´ apisu do souboru), nestaˇc´ı právo z´ apisu do adres´ aˇre. Toto nastaven´ı se pouˇz´ıv´ a pro veˇrejné adres´ aˇre (napˇr. /tmp). • p˚ uvodnˇe mˇel sticky bit v´ yznam i pro spustitelné soubory: program s nastaven´ ym sticky bitem z˚ ustal po ukonˇcen´ı v pamˇeti a jeho opˇetovné spuˇstˇen´ı bylo rychlejˇs´ı. Dnes se sticky bit v tomto v´ yznamu uˇz nepouˇz´ıv´ a. • nˇekteré filesystémy (XFS, AFS, UFS2, ZFS) maj´ı tzv. access control lists (ACL´s), které dovoluj´ı jemnˇejˇs´ı pˇridˇelován´ı práv jednotliv´ ym uˇzivatel˚ um a skupin´ am.

API pro soubory • pˇred pouˇzit´ım mus´ı proces kaˇzd´ y soubor nejprve otevˇr´ıt volán´ım open() nebo creat(). • otevˇrené soubory jsou dostupné pˇres deskriptory soubor˚ u (file descriptors), ˇc´ıslované od 0, v´ıce deskriptor˚ u m˚ uˇze sd´ılet jedno otevˇ ren´ı souboru (m´ od ˇcten´ı/z´ apis, ukazovátko pozice) • standardn´ı deskriptory: – 0 . . . standardn´ı vstup (jen pro ˇcten´ı) – 1 . . . standardn´ı v´ ystup (jen pro z´ apis) – 2 . . . chybov´ y v´ ystup (jen pro z´ apis) • ˇcten´ı a z´ apis z/do souboru: read(), write() • zmˇena pozice: lseek(), zavˇren´ı: close(), informace: stat(), ˇr´ıdic´ı funkce: fcntl(), práva: chmod(), . . .

• kaˇzd´ a funkce, kter´ a alokuje deskriptory (nejen open() a creat(), ale napˇr. i pipe(), dup(), socket()) alokuje vˇzdy volné deskriptory s nejniˇzˇs´ım ˇc´ıslem. • proces dˇed´ı otevˇrené soubory od rodiˇce, tyto soubory nemus´ı znovu otv´ırat. Obvykle (ale ne vˇzdy) proces dostane otevˇrené alespoˇ n deskriptory 0, 1 a 2. • funkce ze souboru stdio.h (napˇr. fopen(), fprintf(), fscanf()) a odkazy na soubory pomoc´ı ukazatele na FILE jsou definovány ve standardn´ı knihovnˇe a pro svoj´ı ˇcinnost pouˇz´ıvaj´ı volán´ı jádra (napˇr. open(), write(), read()). My se nebudeme knihovnou stdio zab´ yvat. 79

Otevˇ ren´ı souboru: open() int open(const char *path, int oflag, ... ); • otevˇre soubor dan´ y jménem (cestou) path, vr´ at´ı ˇc´ıslo jeho deskriptoru (pouˇzije prvn´ı volné), oflag je OR-kombinace pˇr´ıznak˚ u – O RDONLY/O WRONLY/O RDWR . . . otevˇr´ıt pouze pro ˇcten´ı / pouze pro z´ apis / pro ˇcten´ı i z´ apis – O APPEND . . . pˇripojován´ı na konec – O CREAT . . . vytvoˇrit, kdyˇz neexistuje – O EXCL . . . chyba, kdyˇz existuje (pouˇzit´ı s O CREATE) avo z´ apisu nutné) – O TRUNC . . . zruˇsit pˇredchoz´ı obsah (pr´ – ... • pˇri O CREAT definuje tˇret´ı parametr mode pˇr´ıstupová práva

• pˇri pouˇzit´ı O CREAT se mode jeˇstˇe modifikuje podle umask. • mode nem´ a defaultn´ı hodnotu, tj. vezme se to, co je na z´ asobn´ıku i kdyˇz tento parametr nen´ı pˇr´ıtomen! Pˇr´ıznaky i mód jsou uloˇzeny v systémové tabulce otevˇren´ ych soubor˚ u. • pokud se znovu pouˇzije dˇr´ıve vyuˇz´ıvan´ a poloˇzka v tabulce deskriptor˚ u nebo v tabulce otevˇren´ ych soubor˚ u, vˇse potˇrebné se vynuluje (pozice v souboru, flagy deskriptoru, . . . ) • existuj´ı jeˇstˇe dalˇs´ı nastavitelné pˇr´ıznaky: – O SYNC (O DSYNC, O RSYNC – nen´ı na BSD) . . . operace se souborem skonˇc´ı aˇz po fyzickém uloˇzen´ı dat (synchronized I/O) – O NOCTTY . . . pˇri otv´ır´ an´ı terminálu procesem, kter´ y nem´ a ˇr´ıdic´ı termin´ al, se tento termin´ al nestane ˇr´ıd´ıc´ım terminálem procesu – O NONBLOCK . . . pokud nelze ˇcten´ı nebo z´ apis provést okamˇzitˇe, volán´ı read()/write() skonˇc´ı s chybou m´ısto zablokován´ı procesu • v pˇr´ıstupov´ ych právech se vynuluj´ı ty bity, které jsou nastavené pomoc´ı umask(). • pro ˇcten´ı a z´ apis nelze pouˇz´ıt O RDONLY | O WRONLY, protoˇze implementace pouˇzily 0 pro read-only flag. Norma proto definuje, ˇze aplikace mus´ı pouˇz´ıt právˇe jeden z tˇechto tˇr´ı flag˚ u. • je moˇzné otevˇr´ıt a z´ aroveˇ n vytvoˇrit soubor pro z´ apis tak, ˇze jeho mód z´ apis nedovoluje. Pˇri pˇr´ıˇst´ım otevˇren´ı souboru se ale jiˇz tento mód uplatn´ı pˇri kontrole pˇr´ıstupu a pro z´ apis ho otevˇr´ıt nep˚ ujde. Pro O TRUNC také plat´ı, ˇze mus´ıte m´ıt pro dan´ y soubor právo z´ apisu. 80

Vytvoˇ ren´ı souboru int creat(const char *path, mode t mode ); • open() s pˇr´ıznakem O CREAT vytvoˇr´ı soubor, pokud jeˇstˇe neexistuje. V zadané hodnotˇe pˇr´ıstupov´ ych práv se vynuluj´ı bity, které byly nastaveny pomoc´ı funkce mode t umask(mode t cmask ); • funkce je ekvivalentn´ı vol´ an´ı open(path, O WRONLY|O CREAT|O TRUNC, mode); int mknod(const char *path, mode t mode, dev t dev ); • vytvoˇr´ı speci´ aln´ı soubor zaˇr´ızen´ı. int mkfifo(const char *path, mode t mode ); • vytvoˇr´ı pojmenovanou rouru.

• vol´ an´ı vrac´ı nejniˇzˇs´ı deskriptor, kter´ y v dané chv´ıli nebyl otevˇren´ y pro proces • open() dok´ aˇze otevˇr´ıt regul´ arn´ı soubor, zaˇr´ızen´ı i pojmenovanou rouru, ale vytvoˇrit dok´ aˇze jen regul´ arn´ı soubor; pro ostatn´ı typy soubor˚ u je nutné pouˇz´ıt speci´ aln´ı vol´ an´ı. • test, zda soubor existuje, a jeho pˇr´ıpadné vytvoˇren´ı je atomická operace. Toho se vyuˇz´ıv´ a pˇri pouˇz´ıv´ an´ı lock soubor˚ u. • speci´ aln´ı soubory m˚ uˇze vytváˇret pouze root, protoˇze se pomoc´ı nich definuj´ı pˇr´ıstupová práva k perifern´ım zaˇr´ızen´ım. • hodnoty pro mode je moˇzné nalézt vˇetˇsinou v manu´ alové str´ ankce pro chmod

81

ˇ Cten´ ı a z´ apis soubor˚ u: read(), write() ssize t read(int fildes, void *buf, size t nbyte ); • z otevˇreného souboru s ˇc´ıslem deskriptoru fildes pˇreˇcte od aktuáln´ı pozice max. nbyte bajt˚ u dat a uloˇz´ı je od adresy buf. • vrac´ı poˇcet skuteˇcnˇe pˇreˇcten´ ych bajt˚ u (<= nbyte), 0 znamen´ a konec souboru. ssize t write(int fildes, const void *buf, size t nbyte ); – do otevˇreného souboru s ˇc´ıslem deskriptoru fildes zap´ıˇse na aktuáln´ı pozici max. nbyte bajt˚ u dat uloˇzen´ ych od adresy buf. – vrac´ı velikost skuteˇcnˇe zapsan´ ych dat (<= nbyte).

• pro UNIX je kaˇzd´ y soubor posloupnost bajt˚ u bez dalˇs´ı vnitˇrn´ı struktury. • chován´ı read() a write() z´ avis´ı na typu souboru (regul´ arn´ı, zaˇr´ızen´ı, roura, soket) a na tom, zda je soubor v blokuj´ıc´ım nebo neblokuj´ıc´ım módu (flag O NONBLOCK pˇri otevˇren´ı souboru). • vol´ an´ı read() vr´ at´ı nenulov´ y poˇcet bajt˚ u menˇs´ı neˇz nbyte, pokud v souboru zb´ yv´ a ménˇe neˇz nbyte bajt˚ u, nebo volán´ı bylo pˇreruˇseno signálem, nebo soubor je roura, zaˇr´ızen´ı ˇci soket a aktuálnˇe je k dispozici ménˇe neˇz nbyte bajt˚ u. Pˇri neexistenci dat se blokuj´ıc´ı read() zablokuje, dokud se nˇejak´ a data neobjev´ı, neblokuj´ıc´ı read() vr´ at´ı -1 a nastav´ı errno na EAGAIN. • vol´ an´ı write() vr´ at´ı nenulov´ y poˇcet bajt˚ u menˇs´ı neˇz nbyte, jestliˇze se do souboru nevejde v´ıc dat (napˇr. zaplnˇen´ y disk), z´ apis je pˇreruˇsen signálem nebo je nastaveno O_NONBLOCK a do roury, soketu nebo zaˇr´ızen´ı se vejde pouze ˇca´st zapisovan´ ych dat. Bez O_NONBLOCK se ˇcek´ a, dokud se nepodaˇr´ı zapsat vˇse. Pokud nelze aktuálnˇe zapsat nic, blokuj´ıc´ı write() se zablokuje, dokud nen´ı moˇzné zapisovat, neblokuj´ıc´ı write() vr´ at´ı -1 a nastav´ı errno na EAGAIN. • d˚ uleˇ zit´ e v´ yjimky vzhledem k rour´ am jsou uvedeny na stranˇe 85. • kdyˇz read() nebo write() vr´ at´ı ménˇe neˇz nbyte z d˚ uvodu chyby, opakované vol´ an´ı téˇze funkce vr´ at´ı -1 a nastav´ı kód chyby v errno. • pˇreruˇsen´ı read(), write() signálem dˇr´ıv, neˇz se podaˇr´ı pˇreˇc´ıst, resp. zapsat aspoˇ n jeden bajt, zp˚ usob´ı n´ avrat s hodnotou -1 a nastaven´ı errno na EINTR. • pˇr´ıznak otevˇren´ı souboru O_APPEND zajist´ı atomick´ y z´ apis na konec souboru (pouze na lokáln´ım disku), tj. kaˇ zd´ y z´ apis se provede na konec souboru.

82

Uzavˇ ren´ı souboru: close() int close(int fildes ); • uvoln´ı deskriptor fildes, pokud to byl posledn´ı deskriptor, kter´ y odkazoval na otevˇren´ı souboru, zavˇre soubor a uvoln´ı z´ aznam o otevˇren´ı souboru. • kdyˇz je poˇcet odkaz˚ u na soubor 0, jádro uvoln´ı data souboru. Tedy i po zruˇsen´ı vˇsech odkaz˚ u (jmen) mohou se souborem pracovat procesy, které ho maj´ı otevˇren´ y. Soubor se smaˇze, aˇz kdyˇz ho zavˇre posledn´ı proces. • kdyˇz se zavˇre posledn´ı deskriptor roury, vˇsechna zb´ yvaj´ıc´ı data v rouˇre se zruˇs´ı. • pˇri skonˇcen´ı procesu se automaticky provede close() na vˇsechny deskriptory.

• pokud proces potˇrebuje doˇcasn´ y soubor, m˚ uˇze ho vytvoˇrit, ihned smazat a pak s n´ım pracovat pˇres existuj´ıc´ı deskriptor (tento deskriptor lze pˇredat synovsk´ ym proces˚ um). Kdyˇz je takov´ y soubor zavˇren vˇsemi procesy, jádro smaˇze jeho data z disku. • i operace close() m˚ uˇze selhat. Napˇr. nˇekteré filesystémy zapisuj´ı data na disk aˇz v okamˇziku zavˇren´ı souboru, kdyˇz z´ apis skonˇc´ı chybou, close() vr´ at´ı -1. • otev´ır´ an´ı soubor˚ u a nezav´ır´ an´ı je pˇri ukonˇcen´ı práce s nimi vede k alokované pamˇeti, kterou jiˇz nem´ ame jak uvolnit (ztratili jsme na ni odkaz) – situace kde takto pamˇet’ “ztrác´ıme” se naz´ yv´ a memory leak

83

Pˇ r´ıklad: kop´ırov´ an´ı soubor˚ u #include #include int main(int argc, char *argv[]) { char buf[4096]; int inf, outf, ilen; inf = open(argv[1], O RDONLY); outf = creat(argv[2], 0666); while ((ilen = read(inf, buf, 4096)) > 0) write(outf, buf, ilen); close(inf); close(outf); exit(0); }

• je neefektivn´ı ˇc´ıst a zapisovat soubor po jednotliv´ ych bajtech, lepˇs´ı je najednou zpracovávat rozumnˇe velké bloky. • pokud potˇrebujete pracovat s mal´ ymi ˇca´stmi/buffery, je lepˇs´ı pouˇz´ıt stream orintované knihovn´ı funkce fopen(), fread(), . . . které data vnitˇrnˇe bufferuj´ı

84

Pr´ ace s pojmenovanou rourou • nemus´ı b´ yt moˇzné vytvoˇrit FIFO na s´ıt’ovém filesystému (NFS, AFS) • je nutné zn´ at sémantiku otev´ır´ an´ı pojmenované roury: – otevˇren´ı roury pouze pro ˇcten´ı se zablokuje do té doby, dokud se neobjev´ı zapisovatel (pokud jiˇz neexistuje) – otevˇren´ı roury pouze pro z´ apis se zablokuje do té doby, dokud se neobjev´ı ˇcten´ aˇr (pokud jiˇz neexistuje) – toto chován´ı je moˇzné ovlivnit flagem O NONBLOCK • sémantika ˇcten´ı a z´ apisu je jeˇstˇe o nˇeco sloˇzitˇejˇs´ı, vˇenujte velkou pozornost pozn´ amk´ am pod t´ımto slajdem – a je to stejné jako u nepojmenované roury (strana 118)

• je moˇzné otevˇr´ıt rouru pro z´ apis i ˇcten´ı stejn´ ym procesem najednou, aniˇz by pˇredt´ım existoval ˇcten´ aˇr nebo zapisovatel • pokud rouru nem´ a ˇza´dn´ y proces otevˇrenou pro z´ apis, pro okamˇzité vr´ acen´ı deskriptoru pouze pro ˇcten´ı je nutné otevˇ r´ıt rouru s flagem O NONBLOCK, proces se jinak na rouˇre zablokuje ˇcek´ an´ım na zapisovatele. Pozor ale na to, ˇze pokus o ˇ cten´ı z roury bez zapisovatele okamˇzitˇe vr´ at´ı 0 jako indikaci konce souboru; proces se nezablokuje ˇ cek´ an´ım na zapisovatele. Pˇri z´ apisu do roury bez ˇcten´ aˇre (tj. zapisovatel otevˇrel rouru jeˇstˇe v dobˇe, kdy ˇcten´ aˇr existoval) poˇsle kernel procesu signál EPIPE (“broken pipe”). aˇre • v pˇr´ıpadˇe otev´ır´ an´ı pouze pro z´ apis s O NONBLOCK bez existuj´ıc´ıho ˇcten´ se vr´ at´ı chyba a errno se nastav´ı na ENXIO. Tato asymetrie je snahou, aby v rouˇre nebyla data, kter´ a nebudou v kr´ atké dobˇe pˇreˇctena – systém nem´ a zp˚ usob, jak uschovávat data v rouˇre bez ˇcasového omezen´ı. Bez O NONBLOCK flagu se proces zablokuje. • z uvedeného tedy vypl´ yv´ a, ˇze pokud chcete vytvoˇrit proces, kter´ y ˇcek´ a na pojmenované rouˇre a vykon´ av´ a poˇzadavky, mus´ıte ji otevˇr´ıt s flagem O RDWR i kdyˇz do roury nehodláte zapisovat; jinak po prvn´ım zablokován´ı v open() pˇri ˇcek´ an´ı na otevˇren´ı roury zapisovatelem by dalˇs´ı volán´ı read() pro akceptován´ı dalˇs´ıho poˇzadavku typicky vr´ atilo 0, pokud by n´ ahodou roura nebyla mezit´ım pro z´ apis otevˇrena dalˇs´ım procesem. • z´ apis maxim´ aln´ı velikosti PIPE BUF (limits.h) je zaruˇcen´ y jako atomick´ y. Napˇr. v OpenSolarisu to je to 5120 bajt˚ u, ve FreeBSD 5.4 je to 512 bajt˚ u. Pokud zapisujete v´ıce, m˚ uˇze write() provést ˇca´steˇcn´ y z´ apis (a vr´ at´ı tak menˇs´ı ˇc´ıslo neˇz velikost dat kter´ a se mˇela zapsat). • roura nem´ a pozici v souboru, z´ apis tak vˇzdy pˇrid´ av´ a na konec. 85

• stejnˇe se vzhledem ke ˇcten´ı a z´ apisu chová i nepojmenovan´ a roura, viz strana 118.

Nastaven´ı pozice: lseek() off t lseek(int fildes, off t offset, int whence ); • nastav´ı pozici pro ˇcten´ı a z´ apis v otevˇreném souboru daném ˇc´ıslem deskriptoru fildes na hodnotu offset. • podle hodnoty whence se offset poˇc´ıtá: – SEEK SET . . . od zaˇca´tku souboru – SEEK CUR . . . od aktuáln´ı pozice – SEEK END . . . od konce souboru • vrac´ı v´ yslednou pozici poˇc´ıtanou od zaˇca´tku souboru. at´ı aktuáln´ı pozici. • lseek(fildes, 0, SEEK CUR) pouze vr´

• lze se pˇresunout i na pozici za koncem souboru. Pokud se pak provede z´ apis, soubor se prodlouˇz´ı a v pˇreskoˇcené ˇca´sti budou samé nuly (samotné lseek() nestaˇc´ı). Nˇekteré filesystémy takové bloky cel´ ych nul pro u ´ sporu m´ısta neukl´ adaj´ı. • velikost souboru je moˇzné zjistit pomoc´ı lseek(fildes, 0, SEEK END). • nejˇcastˇejˇs´ı operace s lseek jsou tˇ ri: nastaven´ı konkrétn´ı pozice od zaˇca´tku souboru, nastaven´ı pozice na konec souboru a zjiˇstˇen´ı aktuáln´ı pozice v souboru (0 spoleˇcnˇe se SEEK CUR) • pˇri pouˇzit´ı lseek se ˇza´dné I/O neprovede, ˇza´dn´ y pˇr´ıkaz se nepoˇsle na ˇradiˇc disku • lseek nemus´ı slouˇzit jen pro operace read a write, ale také pro n´ aslednou operaci lseek • ukl´ ad´ an´ı nul m˚ uˇ ze v´ est k probl´ em˚ um se z´ alohami

86

Zmˇ ena velikosti: truncate() int truncate(const char *path, off t length ); int ftruncate(int fildes, off t length ); • zmˇen´ı délku souboru zadaného cestou nebo ˇc´ıslem deskriptoru na poˇzadovanou hodnotu. • pˇri zkrácen´ı souboru zruˇs´ı nadbyteˇcn´ a data. • standard ponech´ av´ a nespecifikované, jestli funguje prodlouˇzen´ı souboru (s vyplnˇen´ım pˇridaného u ´ seku nulami). Proto je lepˇs´ı k prodlouˇzen´ı souboru pouˇz´ıt char buf = ’\0’; lseek(fildes, length-1, SEEK_SET); write(fildes, buf, 1);

• zruˇsit veˇsker´ y obsah souboru pˇri otevˇren´ı se d´ a pˇr´ıznakem O TRUNC ve funkci open(). • podrobnosti je tˇreba hledat v manu´ alové str´ ance, napˇr. ve FreeBSD v sekci BUGS nalezneme toto: Use of truncate() to extend a file is not portable.

87

Duplikace deskriptoru: dup(), dup2() int dup(int fildes ); • duplikuje deskriptor fildes na prvn´ı voln´ y deskriptor, vr´ at´ı nov´ y deskriptor, kter´ y odkazuje na stejné otevˇren´ı souboru. • ekvivalent fcntl(fildes, F DUPFD, 0); int dup2(int fildes, int fildes2 ); • duplikuje deskriptor fildes na deskriptor fildes2. • ekvivalent close(fildes2); fcntl(fildes, F DUPFD, fildes2);

• prvn´ı voln´ y deskriptor se pouˇzije i u otev´ır´ an´ı a vytváˇren´ı soubor˚ u, viz strany 80 a 81. • duplikovan´ y a p˚ uvodn´ı deskriptor sd´ıl´ı stejné otevˇren´ı souboru a tedy i aktu´ aln´ı pozici a mód ˇcten´ı/z´ apis. • ekvivalent pro dup2 nen´ı zcela ekvivalentn´ı, napˇr. pokud je fildes rovn´ y fildes2. V´ıce viz norma.

88

Pˇ r´ıklad: implementace shellov´ eho pˇ resmˇ erov´ an´ı • $ program < in > out 2>> err close(0); open("in", O_RDONLY); close(1); open("out", O_WRONLY | O_CREAT | O_TRUNC, 0666); close(2); open("err", O_WRONLY | O_CREAT | O_APPEND, 0666); • $ program > out 2>&1 close(1); open("out", O_WRONLY | O_CREAT | O_TRUNC, 0666); close(2); dup(1);

• dalˇs´ı pˇr´ıklad pouˇzit´ı dup() uvid´ıme, aˇz se budeme zab´ yvat rourami. • je potˇreba si d´ at pozor na stav deskriptor˚ u. Druh´ y pˇr´ıklad nebude fungovat, kdyˇz bude deskriptor 0 uzavˇren, protoˇze open() vr´ at´ı deskriptor 0 (prvn´ı voln´ y) a dup() vr´ at´ı chybu (pokus o duplikaci uzavˇreného deskriptoru). Moˇzné ˇreˇsen´ı: close(1); if((fd = open("out", O WRONLY | O CREAT | O TRUNC, 0666)) == 0) dup(0); close(2); dup(1); if(fd == 0) close(0); nebo fd = open("out", O WRONLY | O CREAT | O TRUNC, 0666); if(fd != 1) { dup2(fd, 1); close(fd); } dup2(1, 2);

89

ˇ ıdic´ı funkce soubor˚ R´ u a zaˇ r´ızen´ı: fcntl(), ioctl() int fcntl(int fildes, int cmd, ...); • slouˇz´ı pro duplikaci deskriptor˚ u, nastavován´ı z´ amk˚ u, testován´ı a nastavován´ı r˚ uzn´ ych pˇr´ıznak˚ u souboru. pˇr´ıklad: zavˇren´ı standardn´ıho vstupu pˇri spuˇstˇen´ı programu (vol´ an´ı typu exec) fcntl(0, F SETFD, FD CLOEXEC); int ioctl(int fildes, int request, ... ); • rozhran´ı pro ˇr´ıdic´ı funkce perifern´ıch zaˇr´ızen´ı • pouˇz´ıv´ a se jako univerz´ aln´ı rozhran´ı pro ovl´ ad´ an´ı zaˇr´ızen´ı, kaˇzdé zaˇr´ızen´ı definuje mnoˇzinu pˇr´ıkaz˚ u, kter´ ym rozum´ı.

• moˇzné hodnoty cmd ve funkci fcntl(): – F DUPFD . . . duplikace deskriptoru – F GETFD . . . zjiˇstˇen´ı pˇr´ıznak˚ u deskriptoru (FD CLOEXEC – uzavˇren´ı pˇri exec). FD CLOEXEC je jedin´ y flag pro deskriptory, definovan´ y v normˇe UNIX 03. u deskriptoru – F SETFD . . . nastaven´ı pˇr´ıznak˚ – F GETFL . . . zjiˇstˇen´ı módu ˇcten´ı/z´ apis a pˇr´ıznak˚ u otevˇren´ı souboru (jako u open()) u otevˇren´ı souboru (O APPEND, O DSYNC, – F SETFL . . . nastaven´ı pˇr´ıznak˚ O NONBLOCK, O RSYNC, O SYNC). Nemohu nastavit pˇr´ıznaky pro ro/rw a ani pˇr´ıznaky pro vytvoˇren´ı, zkrácen´ı nebo exkluzivn´ı pˇr´ıstup k souboru. – F GETLK, F SETLK, F SETLKW . . . nastavován´ı z´ amk˚ u • je d˚ uleˇzité si uvˇedomit, ˇze jsou dva druhy pˇr´ıznak˚ u – pˇr´ıznak(y) pro souborov´ y deskriptor a pˇr´ıznaky pro otevˇren´ y soubor – tj. pˇr´ıznaky jsou uloˇzené ve dvou r˚ uzn´ ych tabulk´ ach. • perifern´ı zaˇr´ızen´ı podporuj´ı ˇcten´ı a z´ apis dat pomoc´ı read(), write() a mapován´ı dat do pamˇeti (mmap()), veˇskeré dalˇs´ı operace se zaˇr´ızen´ım (napˇr. nastaven´ı parametr˚ u, zamˇcen´ı nebo eject) se dˇelaj´ı funkc´ı ioctl(). • pˇri nastavován´ı pˇr´ıznak˚ u nejdˇr´ıv vˇzdy zjistˇete, jaké byly pˇredt´ım. I kdyˇz jste si jisti, ˇze v dané chv´ıli jsou nulové a je tedy moˇzné provést fcntl(fd, uˇzete vˇedˇet, co se m˚ uˇze zmˇenit (napˇr´ıklad o pár ˇra´dk˚ u v´ yˇse O APPEND), nem˚ nˇejak´ y flag pˇrid´ ate, aniˇz byste vˇedˇeli, ˇze jste ovlivnˇeni kódem dole). Tedy vˇzdy pouˇzijte napˇr´ıklad toto:

90

flags = fcntl(fd, F_GETFL); if (fcntl(fd, F_SETFL, flags | O_APPEND) == -1) ... . . . a podobnˇe pro odebr´ an´ı flagu – je ˇspatné ˇreˇsen´ı nastavit hodnot˚ u flag˚ u na nulu, m´ısto toho je tˇreba pouˇz´ıt bitového jedniˇckového doplˇ nku pˇr´ısluˇsného flagu

Informace o souboru: stat() int stat(const char *path, struct stat *buf ); int fstat(int fildes, struct stat *buf ); • pro soubor zadan´ y cestou, resp. ˇc´ıslem deskriptoru, vr´ at´ı strukturu obsahuj´ıc´ı informace o souboru, napˇr.: – st ino . . . ˇc´ıslo i-uzlu – st dev . . . ˇc´ıslo zaˇr´ızen´ı obsahuj´ıc´ıho soubor – st uid, st gid . . . vlastn´ık a skupina souboru – st mode . . . typ a pˇr´ıstupová práva – st size, st blksize, st blocks . . . velikost souboru v bajtech, velikost bloku a poˇcet blok˚ u – st atime, st mtime, st ctime . . . ˇcasy posledn´ıho pˇr´ıstupu, modifikace souboru a modifikace i-uzlu – st nlink . . . poˇcet odkaz˚ u na soubor

• metadata jsou informace o souboru – tedy mód, ˇcasy pˇr´ıstupu, délka, vlastn´ık a skupina atd. Nepatˇr´ı mezi nˇe skuteˇcn´ a data souboru, a ani jméno, které nen´ı uloˇzeno v r´ amci daného souboru, ale v adres´ aˇri ˇci v adres´ aˇr´ıch. • metadata je moˇzné pˇreˇc´ıst, i kdyˇz proces nem´ a práva pro ˇcten´ı obsahu souboru. • touto funkc´ı nez´ısk´ am flagy deskriptoru ani flagy z pole tabulky otevˇren´ ych soubor˚ u v systému, zde jde o informace ohlednˇe souboru uloˇzeného na pamˇet’ovém médiu. • c time nen´ı ˇcas vytvoˇren´ı soubor (creation time), ale ˇcas zmˇeny (change time) • norma nespecifikuje poˇrad´ı poloˇzek ve struktuˇre ani nezakazuje pˇridat dalˇs´ı

91

Informace o souboru (2) • pro typ souboru jsou v <sys/stat.h> definovány konstanty S_IFMT (maska pro typ), S_IFBLK (blokov´ y speci´ aln´ı), S_IFCHR (znakov´ y speci´ aln´ı), S_IFIFO (FIFO), S_IFREG (obyˇcejn´ y), S_IFDIR (adres´ aˇr), S_IFLNK (symlink). • typ lze testovat pomoc´ı maker S_ISBLK(m), S_ISCHR(m), S_ISFIFO(m), S_ISREG(m), S_ISDIR(m), S_ISLNK(m). • konstanty pro pˇr´ıstupová práva: S_IRUSR (ˇcten´ı pro vlastn´ıka), S_IWGRP (zápis pro skupinu), atd. int lstat(const char *path, struct stat *buf ); • kdyˇz je zkouman´ y soubor symlink, stat() vr´ at´ı informace o souboru, na kter´ y ukazuje. Tato funkce vrac´ı informace o symlinku.

• typ a práva souboru jsou uloˇzena spoleˇcnˇe v st_mode, proto existuj´ı zmiˇ novan´ a makra. u, které jsou vˇenované typu souboru, makra pro • S IFMT specifikuje tu ˇca´st bit˚ jednotlivé typy pak nejsou masky, ale hodnoty, takˇze test na typ souboru je nutné udˇelat takto: (st mode & S IFMT == S IFREG). Vˇsechna makra jsou v normˇe, takˇze jejich pouˇz´ıv´ an´ım zaruˇc´ıme pˇrenositeln´ y kód.

92

Nastaven´ı ˇ cas˚ u souboru int utime(const char *path, const struct utimbuf *times ); • nastav´ı ˇcas posledn´ı modifikace souboru a ˇcas posledn´ıho pˇr´ıstupu k souboru. • nelze zmˇenit ˇcas posledn´ı modifikace i-uzlu. • volaj´ıc´ı proces mus´ı m´ıt právo z´ apisu pro soubor.

• tuto funkci pouˇz´ıvaj´ı hlavnˇe kop´ırovac´ı a archivaˇcn´ı programy, aby zajistily stejné ˇcasy kopie a originálu. • shellové rozhran´ı pro funkci utime() pˇredstavuje pˇr´ıkaz touch.

93

Test pˇ r´ıstupov´ ych pr´ av: access() int access(const char *path, int amode ); • otestuje, zda volaj´ıc´ı proces má k souboru path práva daná OR-kombinac´ı konstant v amode: – R_OK . . . test práva na ˇcten´ı – W_OK . . . test práva na z´ apis – X_OK . . . test práva na spuˇstˇen´ı – F_OK . . . test existence souboru • na rozd´ıl od stat(), v´ ysledek z´ avis´ı na RUID a RGID procesu • toto vol´ an´ı se nedá pouˇz´ıt bezpeˇcnˇe, proto ho nikdy nepouˇz´ıvejte procesu

• vol´ an´ı access() aplikuje mechanismus testován´ı pˇr´ıstupov´ ych práv k zadanému souboru pro volaj´ıc´ı proces a vr´ at´ı v´ ysledek. • funkce access() vol´ an´ı byla pro setuid proces, aby si mohl ovˇeˇrit, zda uˇzivatel bˇeˇz´ıc´ı dan´ y setuid proces by mˇel za normáln´ıch okolnost´ı k pˇr´ısluˇsnému souboru pˇr´ıstup. Z toho vypl´ yv´ a, ˇze toto volán´ı je security hole – mezi testem a n´ aslednou akc´ı se soubor m˚ uˇze zmˇenit, coˇz proces nem˚ uˇze nikdy oˇsetˇrit. ˇ sen´ım je vr´ Reˇ atit se zp´ atky k reáln´ ym UID/GID a pˇr´ıstup vyzkouˇset.

94

Nastaven´ı pˇ r´ıstupov´ ych pr´ av int chmod(const char *path, mode t mode ); • zmˇen´ı pˇr´ıstupová práva souboru path na hodnotu mode. • tuto sluˇzbu m˚ uˇze volat pouze vlastn´ık souboru nebo superuˇzivatel (root). int chown(const char *path, uid t owner, gid t group ); • zmˇen´ı vlastn´ıka a skupinu souboru path. Hodnota -1 znamen´ a zachovat vlastn´ıka, resp. skupinu. • mˇenit vlastn´ıka m˚ uˇze jen superuˇzivatel, aby uˇzivatelé nemohli obch´ azet nastavené quoty t´ım, ˇze své soubory pˇredaj´ı nˇekomu jinému. • bˇeˇzn´ y uˇzivatel m˚ uˇze mˇenit skupinu sv´ ych soubor˚ u a mus´ı pˇritom patˇrit do c´ılové skupiny.

• parametr mode zde samozˇrejmˇe neobsahuje typ souboru, jako tomu je napˇr´ıklad u vol´ an´ı stat(). Hodnoty mode viz chmod(2). • pokud nejsem vlastn´ık, nemohu celkem logicky zmˇenit mód ani u souboru s nastaven´ ym pˇr´ıstupem rw-rw-rw• v nˇekter´ ych implementac´ıch m˚ uˇze vlastn´ık souboru pˇredat vlastnictv´ı nˇekomu jinému, napˇr. v IRIXu je chován´ı chown() nastavitelné jako parametr jádra. • nen´ı bˇeˇzné volat funkci chmod() z uˇzivatelsk´ ych aplikac´ı, na to se pouˇz´ıvaj´ı flagy u vol´ an´ı open(), hlavn´ı pouˇzit´ı je v aplikaci chmod(1)

95

Manipulace se jm´ eny soubor˚ u int link(const char *path1, const char *path2 ); • vytvoˇr´ı nov´ y odkaz (poloˇzku adres´ aˇre) path2 na soubor path1. Funguje pouze v r´ amci jednoho svazku. int unlink(const char *path ); • zruˇs´ı odkaz na soubor. Po zruˇsen´ı posledn´ıho odkazu na soubor a uzavˇren´ı souboru vˇsemi procesy je soubor smaz´ an. int rename(const char *old, const char *new ); • zmˇen´ı jméno souboru (pˇresnˇe odkazu na soubor) z old na new. Funguje pouze v r´ amci jednoho svazku.

• vol´ an´ı link() vytváˇr´ı hardlinky, tj. zobrazen´ı ze jména souboru na ˇc´ıslo iˇ ısla i-uzl˚ uzlu. C´ u jsou jednoznaˇcn´ a pouze v r´ amci svazku, proto pro linky mezi filesystémy je nutné pouˇz´ıt symlinky. • parametr path2 nesm´ı existovat, tedy nelze takto pˇrejmenovávat • unlink() nefunguje na adres´ aˇre • shellov´ y pˇr´ıkaz mv pouˇz´ıv´ a rename pro pˇresuny v r´ amci jednoho svazku. Pˇresun souboru mezi filesystémy vyˇzaduje nejprve soubor zkop´ırovat a pak smazat originál vol´ an´ım unlink. • rename() funguje nad symlinky, ne nad soubory, na které symlink ukazuje

96

Symbolick´ e linky int symlink(const char *path1, const char *path2 ); • vytvoˇr´ı symbolick´ y link path2 → path1. • c´ıl symbolického linku m˚ uˇze b´ yt i na jiném svazku, popˇr´ıpadˇe nemus´ı v˚ ubec existovat. int readlink(const char *path, char *buf, size t bufsize ); • do buf d´ a max. bufsize znak˚ u z cesty, na kterou ukazuje symlink path. • vr´ at´ı poˇcet znak˚ u uloˇzen´ ych do buf. • obsah buf nen´ı zakonˇcen nulou (znakem ’\0’)!

• shellov´ y pˇr´ıkaz ln vol´ a symlink() nebo link(), podle toho, jestli je pouˇzit pˇrep´ınaˇc -l nebo ne. • smaz´ an´ı hardlinku nesmaˇze soubor, pokud na nˇej vede jeˇstˇe jin´ y hardlink. Naopak soubor (poloˇzku adres´ aˇre i data) je moˇzné smazat, i kdyˇz na nˇej ukazuj´ı nˇejaké symlinky. • readlink() je pouˇziteln´ y v situaci, pokud chci smazat soubor, na kter´ y dan´ y symlink ukazuje • bufsize se typicky d´ av´ a o 1 menˇs´ı neˇz velikost bufferu, to pro ukonˇcen´ı znakem ’\0’

97

Manipulace s adres´ aˇ ri int mkdir(const char *path, mode t mode ); • vytvoˇr´ı nov´ y prázdn´ y adres´ aˇr, (bude obsahovat pouze poloˇzky ’.’ a ’..’). int rmdir(const char *path ); • smaˇze adres´ aˇr path. Adres´ aˇr mus´ı b´ yt prázdn´ y. DIR *opendir(const char *dirname ); struct dirent *readdir(DIR *dirp ); int closedir(DIR *dirp ); • slouˇz´ı k sekvenˇcn´ımu proch´ azen´ı adres´ aˇr˚ u. • struktura dirent obsahuje poloˇzky – d_ino . . . ˇc´ıslo i-uzlu – d_name . . . jméno souboru

• poloˇzky adres´ aˇre nejsou nijak uspoˇra´d´ any, readdir() je m˚ uˇze vracet v libovolném poˇrad´ı. • v nˇekter´ ych implementac´ıch (napˇr. FreeBSD) lze adres´ aˇr otevˇr´ıt pro ˇcten´ı (ne pro z´ apis) jako norm´ aln´ı soubor a ˇc´ıst ho pomoc´ı read(), ale je tˇreba zn´ at jeho vnitˇrn´ı organizaci. Proto je readdir() pro zpracován´ı obsahu adres´ aˇre lepˇs´ı neˇz read(), kter´ y vrac´ı raw data adres´ aˇre. Kromˇe toho, norma nevyˇzaduje, aby adres´ aˇr bylo moˇzné ˇc´ıst funkc´ı read(), Linux to napˇr´ıklad nedovol´ı. • readdir() je stavová funkce. Pro vr´ acen´ı se na zaˇca´tek je moˇzné pouˇz´ıt funkci rewinddir(). S vl´ akny pak pouˇz´ıvat readdir r(), protoˇze struktura dirent je statická. y adres´ aˇr je mount point, • d ino nen´ı moc uˇziteˇcné, protoˇze v pˇr´ıpadˇe, kdy dan´ tak ukazuje na adres´ aˇr, na kter´ y je dalˇs´ı filesystém namontován, ne na koˇren namontovaného filesystému • rmdir nefunguje na nepr´ azn´ y adres´ aˇr, je moˇzné pouˇz´ıt napˇr´ıklad toto: system("rm -r xxx")

98

Pˇ r´ıklad: proch´ azen´ı adres´ aˇ re int main(int argc, char *argv[]) { int i; DIR *d; struct dirent *de; for(i = 1; i < argc; i++) { d = opendir(argv[i]); while(de = readdir(d)) printf("%s\n", de->d_name); closedir(d); } exit(0); }

• pˇr´ıkaz ls je zaloˇzen na takovéto smyˇcce, nav´ıc provád´ı napˇr. tˇr´ıdˇen´ı jmen soubor˚ u a zjiˇst’ován´ı dalˇs´ıch informac´ı pomoc´ı stat(). • konec adres´ aˇre se pozn´ a tak, ˇze readdir() vr´ at´ı NULL. To vˇsak vr´ at´ı i v pˇr´ıpadˇe, pokud nastala chyba. V takovém pˇr´ıpadˇe je kód chyby v promˇenné errno, v pˇr´ıpadˇe prvn´ım je errno nezmˇenˇena. Proto by errno mˇelo b´ yt vˇzdy nastavené na nulu pˇred volán´ım readdir(). V pˇr´ıkladu tomu tak nen´ı, protoˇze z d˚ uvodu málo m´ısta nekontrolujeme errno v˚ ubec.

99

Aktu´ aln´ı adres´ aˇ r procesu • kaˇzd´ y proces má sv˚ uj aktuáln´ı (pracovn´ı) adres´ aˇr, v˚ uˇci kterému jsou ud´ av´ any relativn´ı cesty k soubor˚ um. Poˇca´teˇcn´ı nastaven´ı pracovn´ıho adres´ aˇre se dˇed´ı od otce pˇri vzniku procesu. int chdir(const char *path ); int fchdir(int fildes ); • nastav´ı nov´ y pracovn´ı adres´ aˇr procesu. char *getcwd(char *buf, size t size ); • uloˇz´ı absolutn´ı cestu k aktuáln´ımu adres´ aˇri do pole buf, jeho délka (size) mus´ı b´ yt aspoˇ n o 1 vˇetˇs´ı neˇz délka cesty.

• funkci fchdir() se pˇred´ av´ a deskriptor z´ıskan´ y volán´ım open() na adres´ aˇr. • funkce getcwd() m˚ uˇze vr´ atit jinou cestu neˇz tu, po které jsme se do aktu´ aln´ıho adres´ aˇre dostali, jesliˇze ˇca´st cesty v chdir() byl symlink nebo doˇslo k pˇresunu (pˇrejmenován´ı) nˇekterého adres´ aˇre na cestˇe od koˇrene. U souˇcasn´ ych ˚ u by se to ale uˇz st´ at nemˇelo.

100

Obsah • u ´ vod, v´ yvoj UNIXu a C, program´ atorské n´ astroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupová práva, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇ stˇ en´ı program˚ u • signály • synchronizace a komunikace proces˚ u • s´ıt’ová komunikace • vl´ akna, synchronizace vl´ aken • ??? - bude definováno pozdˇeji, podle toho kolik zbyde ˇcasu

101

Pamˇ et’ procesu v uˇ zivatelsk´ em reˇ zimu text data bss

nelze adresovat uˇziv. programem

{

zásobn´ık oblast user

                adresovatelné

 uˇziv. programem               

• text . . . kód programu • data . . . inicializované promˇenné • sekce text a data jsou uloˇzeny ve spustitelném souboru • bss . . . neinicializované promˇenné (bss poch´ az´ı z assembleru IBM 7090 a znamen´ a ,,block started by symbol”). Za bˇehu programu tvoˇr´ı sekce data a bss dohromady datov´ y segment procesu. Velikost datového segmentu lze mˇenit pomoc´ı systémov´ ych volán´ı brk() a sbrk(). • (uˇzivatelský) z´ asobn´ık . . . automatické promˇenné, parametry funkc´ı, n´ avratové adresy. Kaˇzd´ y proces má dva z´ asobn´ıky, jeden pro uˇzivatelsk´ y reˇzim a jeden pro reˇzim j´ adra. Uˇzivatelsk´ y z´ asobn´ık procesu automaticky roste podle potˇreby (neplat´ı, pokud se pouˇz´ıvaj´ı vl´ akna). • oblast user (u-area) . . . obsahuje informace o procesu pouˇz´ıvané jádrem, které nejsou potˇrebné, kdyˇz je proces odloˇzen na disku (poˇcet otevˇren´ ych soubor˚ u, nastaven´ı oˇsetˇren´ı signál˚ u, poˇcet segment˚ u sd´ılené pamˇeti, argumenty programu, promˇenné prostˇred´ı, aktuáln´ı adres´ aˇr, atd.). Tato oblast je pˇr´ıstupn´ a pouze pro j´ adro, které vˇzdy vid´ı právˇe jednu u-oblast patˇr´ıc´ı právˇe bˇeˇz´ıc´ımu procesu. Dalˇs´ı informace o procesu, které jádro m˚ uˇze potˇrebovat i pro jin´ y neˇz právˇe bˇeˇz´ıc´ı proces, nebo i kdyˇz je proces odloˇzen, jsou ve struktuˇre proc. Struktury proc pro vˇsechny procesy jsou stále rezidentn´ı v pamˇeti a viditelné v reˇzimu j´ adra.

102

Pamˇ et’ procesu v reˇ zimu j´ adra text jádra data a bss jádra (tabulky, promˇenné, apod.) struktura user beˇz´ıc´ıho procesu

extern struct user u; zásobn´ık jádra

• proces se dostane do reˇzimu j´ adra bud’ pˇr´ıchodem pˇreruˇsen´ı vyvolaného procesorem (v´ ypadek str´ anky, nezn´ am´ a instrukce,...), ˇcasovaˇcem (v pravideln´ ych intervalech je potˇreba aktivovat plánovaˇc proces˚ u), perifern´ım zaˇr´ızen´ım, nebo instrukc´ı synchronn´ıho pˇreruˇsen´ı (standardn´ı knihovna takto pˇred´ av´ a ˇr´ızen´ı j´ adru, aby obslouˇzilo systémové vol´ an´ı). • v pamˇeti je pouze jedna kopie kódu a dat jádra, sd´ılená vˇsemi procesy. Kód jádra je vˇzdy cel´ y rezidentn´ı v pamˇeti, nen´ı odkl´ ad´ an na disk. • text j´ adra . . . kód j´ adra operaˇcn´ıho systému, zaveden´ y pˇri startu systému a rezidentn´ı v pamˇeti po celou dobu bˇehu systému. Nˇekteré implementace umoˇzn ˇ uj´ı pˇrid´ avat funkˇcn´ı moduly do jádra za bˇehu (napˇr. pˇri pˇrid´ an´ı nového zaˇr´ızen´ı se do j´ adra dynamicky pˇrid´ a nov´ y ovladaˇc), nen´ı proto tˇreba kv˚ uli kaˇzdé zmˇenˇe regenerovat j´ adro a restartovat systém. • data a bss j´ adra . . . datové struktury pouˇz´ıvané jádrem, souˇca´st´ı je i u-oblast právˇe bˇeˇz´ıc´ıho procesu. • z´ asobn´ık j´ adra . . . samostatn´ y pro kaˇzd´ y proces, je prázdn´ y, jestliˇze je proces v uˇzivatelském reˇzimu (a tedy pouˇz´ıv´ a uˇzivatelsk´ y z´ asobn´ık).

103

Pamˇ et’ov´ e segmenty procesu a segs struct as

read only shared

s as s prev

text

s next

read/write private

data

read/write private

zásobn´ık

read/write shared

sd´ılená pamˇet’

struct proc

• kaˇzd´ y proces má tˇri z´ akladn´ı segmenty (pamˇet’ové segmenty, nemluv´ıme o hardwarov´ ych segmentech): – text – data – z´ asobn´ık • d´ ale lze do adresového prostoru pˇripojit segmenty sd´ılené pamˇeti (shmat()) nebo soubory (mmap()). • text je sd´ılen vˇsemi procesy, které provád´ı stejn´ y k´ od. Datov´ y segment a z´ asobn´ık jsou priv´ atn´ı pro kaˇzd´ y proces. • z´ akladn´ım rysem této architektury je tzv. memory object, coˇz je abstrakce mapován´ı mezi kusem pamˇeti a m´ıstem, kde jsou data norm´ alnˇe uloˇzena (tzv. backing store nebo data object ). Takové m´ısto uloˇzen´ı m˚ uˇze b´ yt napˇr´ıklad swap nebo soubor. Adresov´ y prostor procesu je pak mnoˇzina mapován´ı na r˚ uzné datové objekty. Existuje i anonymn´ı objekt, kter´ y nem´ a m´ısto trvalého uloˇzen´ı (pouˇz´ıv´ a se napˇr´ıklad pro z´ asobn´ık). Fyzická pamˇet’ pak slouˇz´ı jako cache pro data tˇechto namapovan´ ych datov´ ych objekt˚ u. • tato zde velmi hrubˇe popsaná architektura se naz´ yv´ a VM (od Virtual Memory), a objevila se v SunOS 4.0. Na této architektuˇre je zaloˇzena architektura viru´ aln´ı pamˇeti v SVR4. V´ıce informac´ı viz [Vahalia], p˚ uvodn´ı ˇclánek z roku 1987 pˇredstavuj´ıc´ı tuto architekturu: Gingell, R. A., Moran J. P., Shannon, W. A. – Virtual Memory Architecture in SunOS nebo pˇredn´ aˇska o operaˇcn´ıch systémech na MFF ve ˇctvrtém (?) roˇcn´ıku.

104

Virtu´ aln´ı pamˇ et’ pamˇet’ procesu 1 000 111

111 000 000 111 000 111 000 111 000 111 000 111 000 111

reálná pamˇet’

pamˇet’ procesu 2

111 000 000 111 000 111 000 111 000 111

11 00 0 1 0 1 00 11 0 1 0 1 00 11 0 1 001010 11

1 0 0 1 0 1 0 1 0 1 0 1 0 1


1 0 0 1 0 1 0 1 0 1 0 1 0 1


111111 000000 000000 111111 000000 111111 000000 111111 11 00 00 11 00 11 00 11

1 0 0 1 0 1 0 1 0 1 0 1 0 1

• kaˇzd´ y proces vid´ı sv˚ uj adresov´ y prostor jako souvisl´ y interval (virtuáln´ıch) adres od nuly po nˇejakou maxim´ aln´ı hodnotu. Pˇr´ıstupné jsou pouze ty adresy, na kter´ ych je namapován nˇekter´ y segment procesu (to je právˇe to mapován´ı, o kterém se mluv´ı na pˇredchoz´ım slajdu). • jádro d´ ale rozdˇeluje pamˇet’ procesu na str´ anky. Kaˇzd´ a str´ anka má své um´ıstˇen´ı v r´ amci fyzické pamˇeti. Toto um´ıstˇen´ı je d´ ano str´ ankovac´ımi tabulkami jádra a str´ anky mohou b´ yt v r´ amc´ıch libovolnˇe prom´ıch´ any v˚ uˇci jejich poˇrad´ı ve virtu´ aln´ı adresovém prostoru. • pokud nen´ı str´ anka právˇe pouˇz´ıv´ ana, m˚ uˇze b´ yt také odloˇzena na disk. • pamˇet’ov´ y manager j´ adra zajiˇst’uje mapován´ı mezi virtu´ aln´ımi adresami pouˇz´ıvan´ ymi kódem uˇzivatelsk´ ych proces˚ u i jádra na fyzické adresy a naˇcten´ı odloˇzen´ ych str´ anek z disku pˇri v´ ypadku str´ anky.

105

Implementace virtu´ aln´ı pamˇ eti • procesy v UNIXu pouˇz´ıvaj´ı k pˇr´ıstupu do pamˇeti virtu´ aln´ı adresy, které na fyzické adresy pˇrevád´ı hardware ve spolupráci s j´ adrem systému. • pˇri nedostatku volné pamˇeti se odkl´ adaj´ı nepouˇz´ıvané u ´ seky pamˇeti do odkl´ adac´ı oblasti (swap) na disk. • pˇred verz´ı SVR2 se procesem swapper (nyn´ı sched) odkl´ adaly celé procesy. • od verze SVR2 se pouˇz´ıv´ a str´ ankován´ı na ˇza´dost (demand paging) a copy-on-write. Str´ anky se alokuj´ı aˇz pˇri prvn´ım pouˇzit´ı a priv´ atn´ı str´ anky se kop´ıruj´ı pˇri prvn´ı modifikaci. Uvolˇ nován´ı a odkl´ ad´ an´ı jednotliv´ ych str´ anek provád´ı proces pageout, odkl´ ad´ an´ı cel´ ych proces˚ u nastupuje aˇz pˇri kritickém nedostatku pamˇeti.

pˇ reklad adres: pˇr´ıstup na neplatnou adresu nebo pokus o z´ apis do pamˇeti pouze pro ˇcten´ı vyvol´ a signál SIGSEGV. swap: odkl´ adac´ı prostor se vytváˇr´ı na samostatném odd´ılu disku, od SVR4 m˚ uˇze b´ yt i v souboru. swapper: proces swapper se snaˇz´ı odloˇzit na disk nˇejak´ y proces, kter´ y nen´ı zamˇcen v pamˇeti, a na uvolnˇené m´ısto zavést dˇr´ıve odloˇzen´ y proces. demand paging: pˇri ˇza´dosti procesu o pamˇet’ se pouze uprav´ı tabulka str´ anek. Prvn´ı instrukce adresuj´ıc´ı obsah str´ anky vyvolá v´ yjimku. J´ adro ji oˇsetˇr´ı t´ım, ˇze alokuje str´ anku. copy-on-write: v´ıce proces˚ u m˚ uˇze sd´ılet zapisovatelnou fyzickou str´ anku, kter´ a je ale logicky priv´ atn´ı pro kaˇzd´ y proces (tato situace nastane napˇr. po vytvoˇren´ı procesu vol´ an´ım fork()). Dokud procesy z pamˇeti pouze ˇctou, pˇristupuj´ı ke sd´ılené str´ ance. Pokud se proces pokus´ı obsah str´ anky zmˇenit, vyvolá v´ yjimku. J´ adro zkop´ıruje str´ anku, pˇridˇel´ı procesu kopii, kter´ a uˇz je priv´ atn´ı a proces ji m˚ uˇze d´ ale libovolnˇe mˇenit. Ostatn´ı procesy pouˇz´ıvaj´ı stále nezmˇenˇenou p˚ uvodn´ı str´ anku. str´ anky k odloˇzen´ı se hledaj´ı algoritmem NRU (not recently used): kaˇzd´ a str´ anka má pˇr´ıznaky referenced a modified, na zaˇca´tku vynulované. Pˇri prvn´ım pˇr´ıstupu se nastav´ı referenced, pˇri zmˇenˇe modified. Oba pˇr´ıznaky se periodicky nuluj´ı. Pˇrednostnˇe se uvolˇ nuj´ı str´ anky, které nejsou modifikované ani pouˇzité. Str´ anky kódu programu a mapovan´ ych soubor˚ u se neukl´ adaj´ı do odkl´ adac´ıho prostoru, ale obnovuj´ı se z pˇr´ısluˇsného souboru.

106

Stavy procesu bˇeˇz´ı v uˇziv. reˇzimu

vznik

*

pˇreruˇsen´ı

návrat

bˇeˇz´ı v reˇzimu jádra pˇridˇelen´ı procesoru

zánik

†

wait

exit kill

mátoha (zombie)

preempce pˇripraven v pamˇeti odloˇzen´ı

zaveden´ı

pˇripraven na disku

probuzen´ı probuzen´ı

uspán´ı sp´ı v pamˇeti odloˇzen´ı sp´ı na disku

• po ukonˇcen´ı procesu vol´ an´ım exit() nebo v reakci na signál pˇrech´ az´ı proces do stavu mátoha (zombie), protoˇze jádro si mus´ı pamatovat k ˇc´ıslu procesu jeho n´ avratovou hodnotu. Celá pamˇet’ procesu je uvolnˇena, zb´ yv´ a pouze struktura proc. Proces lze definitivnˇe zruˇsit, aˇz kdyˇz se jeho rodiˇc zept´ a na n´ avratovou hodnotu vol´ an´ım typu wait(). • v dneˇsn´ıch UNIXech se obvykle do odkl´ adac´ı oblasti na disku (swap area) neodkl´ adaj´ı celé procesy, ale jednotlivé str´ anky pamˇeti. • proces je usp´ an, kdyˇz o to s´ am poˇza´d´ a, napˇr. zaˇcne ˇcekat na dokonˇcen´ı perifern´ı operace. Preempce je naopak nedobrovolné odebr´ an´ı procesoru plánovaˇcem.

107

Pl´ anov´ an´ı proces˚ u • preemptivn´ı pl´ anov´ an´ı – jestliˇze se proces nevzdá procesoru (neusp´ı se ˇcek´ an´ım na nˇejakou ud´ alost), je mu odebr´ an procesor po uplynut´ı ˇcasového kvanta. • procesy jsou zaˇrazeny do front podle priority, procesor je pˇridˇelen vˇzdy prvn´ımu pˇripravenému procesu z fronty, kter´ a má nejvyˇsˇs´ı prioritu. • v SVR4 byly zavedeny prioritn´ı tˇr´ıdy a podpora proces˚ u reálného ˇcasu (real-time) s garantovanou maxim´ aln´ı dobou odezvy. • na rozd´ıl od pˇredchoz´ıch verz´ı znamen´ a v SVR4 vyˇsˇs´ı ˇc´ıslo vyˇsˇs´ı prioritu.

• z´ akladem preemptivn´ıho plánován´ı jsou pravidelná pˇreruˇsen´ı od ˇcasovaˇce, kter´ a odeberou procesor bˇeˇz´ıc´ımu procesu a pˇredaj´ı ˇr´ızen´ı jádru (aktivuje se plánovaˇc proces˚ u). • jiná varianta je nepreemptivn´ı (kooperativn´ı) plánován´ı, kdy proces bˇeˇz´ı, dokud se s´ am nevzd´ a procesoru, tj. dokud nezavolá takovou systémovou funkci, kter´ a pˇrepne kontext na jin´ y proces. Nev´ yhodou kooperativn´ıho plánován´ı je, ˇze jeden proces m˚ uˇze st´ ale blokovat procesor a ostatn´ı procesy se nikdy nedostanou na ˇradu. • UNIX pouˇz´ıv´ a pouze preemptivn´ı plánován´ı pro uˇzivatelské procesy. • tradiˇcn´ı UNIXové j´ adro funguje kooperativn´ım zp˚ usobem, tj. proces bˇeˇz´ıc´ı v reˇzimu j´ adra nen´ı pˇreplánován, dokud se s´ am nevzdá procesoru. J´ adra modern´ıch UNIX˚ u jsou jiˇz preemtivn´ı – je to hlavnˇe kv˚ uli real-time systém˚ um; tam je potˇreba m´ıt moˇznost bˇeˇz´ıc´ı proces zbavit procesoru okamˇzitˇe, neˇcekat na to, aˇz se vr´ at´ı z reˇzimu j´ adra nebo se s´ am usp´ı. • pˇri preemptivn´ım plánován´ı m˚ uˇze b´ yt proces kdykoliv pˇreruˇsen a ˇr´ızen´ı pˇred´ ano jinému procesu. Proces si proto nikdy nem˚ uˇze b´ yt jist´ y, ˇze urˇcitou operaci (v´ıce neˇz jednu intstrukci, kromˇe systémov´ ych volán´ı se zaruˇcenou atomiˇcnost´ı) provede atomicky, bez ovlivnˇen´ı ostatn´ımi procesy. Pokud je tˇreba zajistit atomiˇcnost nˇejaké akce, mus´ı se procesy navz´ ajem synchronizovat. Pˇri kooperativn´ım plánován´ı problém synchronizace odpadá (atomická posloupnost operac´ı se zajist´ı t´ım, ˇze se proces bˇehem n´ı nevzdá procesoru).

108

Prioritn´ı tˇ r´ıdy • syst´ emov´ a – priorita 60 aˇz 99 – rezervována pro systémové procesy (pageout, sched, . . . ) – pevn´ a priorita • real-time – priorita 100 aˇz 159 – pevn´ a priorita – pro kaˇzdou hodnotu priority definováno ˇcasové kvantum • sd´ılen´ı ˇ casu (time-shared) – priorita 0 aˇz 59 – promˇenná dvousloˇzková priorita, pevn´ a uˇzivatelsk´ aa promˇenná systémová ˇca´st – pokud proces hodnˇe vyuˇz´ıv´ a procesor, je mu sniˇzována priorita (a zvˇetˇsováno ˇcasové kvantum)

• systémová tˇr´ıda je pouˇz´ıv´ ana pouze jádrem, uˇzivatelsk´ y proces bˇeˇz´ıc´ı v reˇzimu j´ adra si ponech´ av´ a svou plánovac´ı charakteristiku. • procesy ve tˇr´ıdˇe re´ alného ˇcasu maj´ı nejvyˇsˇs´ı prioritu, proto mus´ı b´ yt spr´ avnˇe nakonfigurovány, aby nezablokovaly zbytek systému. • jestliˇze je proces ve tˇr´ıdˇe sd´ılen´ı ˇcasu uspán a ˇcek´ a na nˇejakou ud´ alost, je mu doˇcasnˇe pˇriˇrazena systémová priorita. Po probuzen´ı se takov´ y proces dostane na procesor dˇr´ıve, neˇz ostatn´ı procesy, které nesp´ı. • pevn´ a ˇca´st priority procesu ve tˇr´ıdˇe sd´ılen´ı ˇcasu se d´ a nastavit pomoc´ı int setpriority(int which, id t who, int nice ); nebo int nice(int 1 );

109

Skupiny proces˚ u, ˇ r´ızen´ı termin´ al˚ u • kaˇzd´ y proces patˇr´ı do skupiny proces˚ u, tzv. process group • kaˇzd´ a skupina m˚ uˇze m´ıt vedouc´ı proces, tzv. group leader • kaˇzd´ y proces m˚ uˇze m´ıt ˇr´ıd´ıc´ı terminál (je to obvykle login termin´ al), tzv. controlling terminal • speci´ aln´ı soubor /dev/tty je asociován s ˇr´ıd´ıc´ım terminálem kaˇzdého procesu • kaˇzd´ y termin´ al je asociován se skupinou proces˚ u, tato skupina se naz´ yv´ a ˇr´ıd´ıc´ı skupina (controlling group) • kontrola job˚ u (job control ) je mechanizmus, jak pozastavovat a probouzet skupiny proces˚ u a ˇr´ıdit jejich pˇr´ıstup k terminál˚ um • session (relace) je kolekce skupin proces˚ u vytvoˇren´ a pro u ´ˇcely ˇr´ızen´ı job˚ u

• kdyˇz se uˇzivatel pˇrihl´ as´ı do systému, je vytvoˇren´ a nová relace, kter´ a se sklád´ a z jedné skupiny proces˚ u, ve které je jeden proces – ten kter´ y vykon´ av´ a uˇzivatel˚ uv shell. Tento proces je z´ aroveˇ n vedouc´ı této jediné skupiny proces˚ u a také je vedouc´ı relace. V pˇr´ıpadˇe, ˇze job control je povolen, kaˇzd´ y pˇr´ıkaz nebo kolona pˇr´ıkaz˚ u vytvoˇr´ı novou skupinu proces˚ u, jeden z proces˚ u v kaˇzdé skupinˇe se vˇzdy stane vedouc´ım procesem dané skupiny. Jedna ze skupin m˚ uˇze bˇeˇzet na popˇred´ı, ostatn´ı bˇeˇz´ı na pozad´ı. Sign´ aly které jsou generované z kl´ avesnice (tj. stiskem kombinace kl´ aves, nemysl´ı se t´ım spuˇstˇen´ı pˇr´ıkazu kill!) jsou zasl´ any pouze skupinˇe, kter´ a bˇeˇz´ı na popˇred´ı. • pokud job control nen´ı zapnut, znamen´ a spustˇen´ı pˇr´ıkazu na pozad´ı pouze to, ˇze shell neˇcek´ a na jeho ukonˇcen´ı. Existuje pouze jedna skupina proces˚ u, signály z kl´ avesnice se pos´ılaj´ı vˇsem proces˚ um beˇz´ıc´ım na popˇred´ı i na pozad´ı. Nelze pˇresouvat procesy z pozad´ı na popˇred´ı a naopak. • kdyˇz proces, kter´ y má kontroln´ı terminál, otevˇre soubor /dev/tty, tak se asociuje se sv´ ym kontroln´ım terminálem. Tj. pokud dva r˚ uzné procesy z r˚ uzn´ ych relac´ı otevˇrou tento soubor, pˇristupuj´ı oba k r˚ uzn´ ym terminál˚ um.

110

Identifikace procesu pid t getpid(void); • vrac´ı process ID volaj´ıc´ıho procesu. pid t getpgrp(void); • vrac´ı ID skupiny proces˚ u, do které patˇr´ı volaj´ıc´ı proces. pid t getppid(void); • vrac´ı process ID rodiˇce. pid t getsid(pid t pid ); • vrac´ı group ID vedouc´ıho procesu session (sezen´ı, terminálové relace) pro proces pid (0 znamen´ a pro volaj´ıc´ı proces)

skupiny proces˚ u umoˇzn ˇ uj´ı pos´ılat signály najednou celé skupinˇe. session (relace, sezen´ı) je kolekce proces˚ u vytvoˇren´ a pro u ´ˇcely ˇr´ızen´ı prac´ı (job control ). Procesy sezen´ı sd´ılej´ı jeden ˇr´ıd´ıc´ı termin´ al. Session zahrnuje jednu nebo v´ıce skupin proces˚ u. Max. jedna skupina v r´ amci sezen´ı bˇeˇz´ı na popˇred´ı (foreground process group) a má pˇr´ıstup k ˇr´ıdic´ımu terminálu pro vstup i v´ ystup, ostatn´ı bˇeˇz´ı na pozad´ı (background process groups) a maj´ı k ˇr´ıdic´ımu termin´ alu pˇr´ıstup volitelnˇe jen pro v´ ystup nebo v˚ ubec (nepovolen´ a operace s termin´ alem pozastav´ı proces). Proces, kter´ y jeˇstˇe nen´ı vedouc´ım skupiny proces˚ u, se m˚ uˇze st´ at vedouc´ım sezen´ı a z´ aroveˇ n skupiny proces˚ u volán´ım setsid(). Jestliˇze proces uˇz je vedouc´ım skupiny, setsid() selˇze, pak je tˇreba provést fork() a setsid() zavolat v synovském procesu. Takov´ y proces nem´ a ˇr´ıdic´ı termin´ al, m˚ uˇze ho z´ıskat otevˇren´ım terminálu, kter´ y jeˇstˇe nen´ı ˇr´ıdic´ım termin´ alem sezen´ı, kdyˇz pˇri open() neuvede pˇr´ıznak O NOCTTY, nebo jin´ ym implementaˇcnˇe z´ avisl´ ym zp˚ usobem. rodiˇ covsk´ y proces: Kaˇzd´ y proces (kromˇe swapperu, pid == 0) má rodiˇce, tj. proces, kter´ y ho stvoˇril vol´ an´ım fork(). Jestliˇze rodiˇc skonˇc´ı dˇr´ıve neˇz d´ıtˇe, adoptivn´ım rodiˇcem se st´ av´ a proces init s pid == 1, kter´ y se také postar´ a o uklizen´ı zombie po skonˇcen´ı procesu.

111

Vytvoˇ ren´ı procesu: fork() getpid() == 1234 switch(pid = case -1: case 0: default: } rodiˇc (pokraˇcuje)

fork()) { /* Chyba */ /* D´ ıtˇ e */ /* Rodiˇ c */

d´ıtˇe (nový proces)

getpid()==1234, pid==2345 switch(pid = fork()) { case -1: /* Chyba */ case 0: /* D´ ıtˇ e */ default: /* Rodiˇ c */ }

getpid()==2345, pid==0 switch(pid = case -1: case 0: default: }

fork()) { /* Chyba */ /* D´ ıtˇ e */ /* Rodiˇ c */

• d´ıtˇe je témˇeˇr pˇresnou kopi´ı rodiˇce, liˇs´ı se PID, d´ ale parent PID a nˇekteré dalˇs´ı podrobnosti (´ uˇctovac´ı ˇcasy se nastav´ı na 0, nedˇed´ı se nastaven´ı alarm() a z´ amky soubor˚ u). A pokud mˇel rodiˇc v´ıce vl´ aken, má syn pouze to, které zavolalo fork(); o tom v´ıce pozdˇeji aˇz se dostaneme k vl´ akn˚ um. Tyto informace by mˇely b´ yt v manu´ alové str´ ance textttfork(2). • pro urychlen´ı a menˇs´ı spotˇrebu pamˇeti se adresov´ y prostor nekop´ıruje, ale pouˇz´ıv´ a se mechanismus copy-on-write. • je logické, ˇze otec dostane jako n´ avratovou hodnotu vol´ an´ı fork PID syna a syn 0; syn si m˚ uˇze velmi jednoduˇse sv˚ uj vlastn´ı PID zjistit. Otec by ale jiˇz nemˇel moˇznost jednoduˇse zjistit, jak´ y je PID syna kter´ y byl právˇe vytvoˇren, nav´ıc v situaci, kdy jiˇz vytvoˇril dˇr´ıve syny jiné.

112

Spuˇ stˇ en´ı programu: exec extern char **environ; int execl(const char *path, const char *arg0, ... ); • spust´ı program definovan´ y celou cestou path, dalˇs´ı argumenty se pak pˇredaj´ı programu v parametrech argc a argv funkce main(). Seznam argument˚ u je ukonˇcen pomoc´ı (char *)0, tj. NULL. arg0 by mˇel obsahovat jméno programu (tj. ne celou cestu) • u ´ spˇeˇsné vol´ an´ı execl() se nikdy nevrát´ı, protoˇze spuˇstˇen´ y program zcela nahrad´ı dosavadn´ı adresov´ y prostor procesu. • program dˇed´ı promˇenné prostˇred´ı, tj. obsah environ. • handlery signál˚ u se nahrad´ı implicitn´ı obsluhou. • zavˇrou se deskriptory soubor˚ u, které maj´ı nastaven´ y pˇr´ıznak FD CLOEXEC (implicitnˇe nen´ı nastaven).

• v path mus´ı b´ yt cel´ a (absolutn´ı nebo relativn´ı) cesta ke spustitelnému souboru. Obsah promˇenné prostˇred´ı PATH se pouˇz´ıv´ a jen pˇri volán´ıch execlp() a execvp(), kdyˇz argument path neobsahuje znak ’/’. • nˇekdy se pouˇz´ıv´ a argv[0] r˚ uzné od jména spustitelného souboru. Napˇr. login vloˇz´ı na zaˇca´tek jména spouˇstˇeného shellu znak ’-’. Shell podle toho pozn´ a, ˇze má fungovat jako login-shell, tj. spustit /etc/profile. • exec() nepˇred´ a kontrolu naˇctenému programu v pamˇeti pˇr´ımo, ale pˇres dynamick´ y linker (téˇz naz´ yvan´ y loader ), poté co ho (= toho loader a) namapuje do adresového prostoru procesu. Loader n´ aslednˇe namapuje potˇrebné dynamické objekty a teprve poté pˇred´ a kontrolu aplikaci. Viz také strana 31. Pro jednoduché ovˇeˇren´ı staˇc´ı vytvoˇrit program obsahuj´ıc´ı pouze tˇreba volán´ı open(). Tento program pak spust’te pomoc´ı truss(1) takto: truss ./a.out. Uvid´ıte, kter´ a vol´ an´ı se pouˇzij´ı jeˇstˇe pˇredt´ım, neˇz se zavolá open(). • exec() nezmˇen´ı hodnoty RUID a RGID. A pokud je to program s nastaven´ ym SUID bitem, tak se EUID a uschované UID nastav´ı na UID majitele spustitelného souboru. • dneˇsn´ı unixové systémy um´ı spouˇstˇet i skripty, které zaˇc´ınaj´ı ˇra´dkem #!/interpreter path /interpreter name [args]

113

Varianty sluˇ zby exec int execv(const char *path, char *const argv []); • obdoba execl(), ale argumenty jsou v poli argv, jehoˇz posledn´ı prvek je (char *)0. int execle(const char *path, const char *arg0, ... , char *const envp []); • obdoba execl(), ale m´ısto environ se pouˇzije envp. int execve(const char *path, char *const argv [], char *const envp []); • obdoba execv(), ale m´ısto environ se pouˇzije envp. int execlp(const char *file, const char *arg0, ...); int execvp(const char *file, char *const argv []); • obdoby execl() a execv(), ale pro hled´ an´ı spustitelného souboru se pouˇzije promˇenná PATH.

• l = list, v = vector, e = environment, p = PATH. • kromˇe execlp() a execvp() je nutné vˇzdy zadávat celou cestu. • vˇsechny varianty kromˇe execle() a execve() pˇred´ avaj´ı spouˇstˇenému programu své aktuáln´ı prostˇred´ı, tj. obsah pole environ. • z nˇejak´ ych historick´ ych d˚ uvod˚ u neexistuje volán´ı s p a e dohromady.

114

Form´ at spustiteln´ eho souboru • Common Object File Format (COFF) – starˇs´ı System V • Extensible Linking Format (ELF) – nov´ y v SVR4 • ˇcasto se mluv´ı o a.out formátu, protoˇze tak se jmenuje (pokud nen´ı pouˇzit pˇrep´ınaˇc -o) v´ ystup linkeru. • Formát ELF:

hlaviˇcka souboru tabulka programov´ ych hlaviˇcek sekce 1 .. . sekce N tabulka hlaviˇcek sekc´ı

• hlaviˇcka souboru (ELF header ) obsahuje z´ akladn´ı informace o souboru. • tabulka programov´ ych hlaviˇcek (program header table) je pˇr´ıtomna pouze u soubor˚ u obsahuj´ıc´ıch spustitelné programy. Obsahuje informaci o rozvrˇzen´ı virtu´ aln´ı pamˇeti procesu. • sekce obsahuj´ı instrukce, data, tabulku symbol˚ u, relokaˇcn´ı data, apod. • tabulka hlaviˇcek sekc´ı (section header table) obsahuje sluˇzebn´ı informace pro linker.

115

Ukonˇ cen´ı procesu void exit(int status ); • ukonˇc´ı proces s n´ avratov´ ym kódem status. • nikdy se nevr´ at´ı na instrukci n´ asleduj´ıc´ı za volán´ım. pid t wait(int *stat loc ); • poˇck´ a, aˇz skonˇc´ı nˇekter´ y synovsk´ y proces, vr´ at´ı jeho PID a do stat_loc uloˇz´ı n´ avratov´ y kód, kter´ y lze d´ ale testovat: – WIFEXITED(stat val) . . . proces volal exit() – WEXITSTATUS(stat val) . . . argument exit() – WIFSIGNALED(stat val) . . . proces dostal signál – WTERMSIG(stat val) . . . ˇc´ıslo signálu – WIFSTOPPED(stat val) . . . proces pozastaven – WSTOPSIG(stat val) . . . ˇc´ıslo signálu pid t waitpid(pid t pid, int *stat loc, int opts ); • ˇcek´ an´ı na jeden proces.

• _exit() . . . jako exit(), ale neprovád´ı se flush stdio stream˚ u a nevolaj´ı se funkce nastavené pomoc´ı atexit() • ve standardu je jeˇstˇe WIFCONTINUED(stat val) . . . pokraˇcován´ı po zastaven´ı • opts ve waitpid() – OR-kombinace: – WCONTINUED . . . vr´ at´ı status procesu, kter´ y nebyl testován od pokraˇcován´ı procesu po zastaven´ı – WNOHANG . . . neˇcek´ a, pokud nen´ı status okamˇzitˇe k dispozici – WUNTRACED . . . vr´ at´ı status zastaveného procesu, kter´ y nebyl testován po jeho zastaven´ı • pid ve waitpid(): – == -1 . . . libovolné d´ıtˇe – > 0 . . . jedno d´ıtˇe – == 0 . . . d´ıtˇe ve stejné skupinˇe proces˚ u jako volaj´ıc´ı proces – < -1 . . . d´ıtˇe ve skupinˇe abs(pid) • rodiˇc by mˇel vˇzdy na své dˇeti zavolat wait() nebo waitpid(), protoˇze jinak se v systému hromad´ı zombie (ukonˇcené procesy, které pouze ˇcekaj´ı, aˇz si rodiˇc pˇreˇcte jejich n´ avratovou hodnotu).

116

Pˇ r´ıklad: spuˇ stˇ en´ı programu a ˇ cek´ an´ı int status; pid = fork() rodiˇc if(pid > 0)

wait(&status);

d´ıtˇe else execl("/bin/ls", "/bin/ls", "/", NULL); /bin/ls int main(int argc, char *argv[]) { ... exit(result); }

• toto je klasick´ y zp˚ usob jak spustit nˇejak´ y program a po jeho skonˇcen´ı pokraˇcovat. Rodiˇc nemus´ı jen ˇcekat na ukonˇcen´ı potomka, ale m˚ uˇze vykon´ avat d´ al sv˚ uj kód. • pozor na to, ˇze aˇckoli to na obr´ azku tak vypad´ a, n´ avratová hodnota je pouze souˇca´st toho, co dostanete z volán´ı wait(). Na jej´ı z´ıskán´ı je potˇreba pouˇz´ıt makra z pˇredchoz´ıho slajdu.

117

Roura: pipe() int pipe(int fildes [2]); • vytvoˇr´ı rouru a dva deskriptory – fildes[0] . . . ˇcten´ı z roury – fildes[1] . . . z´ apis do roury • roura zajiˇst’uje synchronizaci ˇcten´ı a z´ apisu: – zapisuj´ıc´ı proces se zablokuje, kdyˇz je roura plná, – ˇctouc´ı proces se zablokuje, kdyˇz je roura prázdn´ a. • ˇctouc´ı proces pˇreˇcte konec souboru (tj. read() vr´ at´ı 0), pokud jsou uzavˇreny vˇsechny kopie fildes[1]. • pojmenovan´ a roura (vytvoˇren´ a volán´ım mkfifo()) funguje stejnˇe, ale má pˇridˇelené jméno v systému soubor˚ u a mohou ji tedy pouˇz´ıvat libovolné procesy.

• nepojmenovanou rouru vytváˇr´ı jeden proces a m˚ uˇze ji pˇredat pouze sv´ ym potomk˚ um (pomoc´ı deskriptor˚ u zdˇedˇen´ ych pˇri fork()). Toto omezen´ı se d´ a obej´ıt pomoc´ı pˇred´ an´ı otevˇreného deskriptoru pˇres unix-domain socket. • jestliˇze funkce write() zap´ıˇse do roury nejv´ yˇse PIPE BUF (systémová konstanta) bajt˚ u, je zaruˇceno, ˇze z´ apis bude atomick´ y, tj. tato data nebudou proloˇzena daty zapisovan´ ymi souˇcasnˇe jin´ ymi procesy. • v normˇe UNIX03 nen´ı specifikováno, zda fildes[0] je také otevˇren´ y pro z´ apis a zda fildes[1] je téˇz otevˇren´ y pro ˇcten´ı. Pozor na to, ˇze napˇr´ıklad FreeBSD a Solaris maj´ı roury obousmˇerné, ale Linux (kdyˇz jsem se naposledy d´ıval) ne. Je proto velmi vhodné poˇc´ıtat pouze s jednosmˇern´ ymi rourami. • d˚ uleˇ zit´ e: pro ˇcten´ı/z´ apis z/do roury plat´ı stejné podm´ınky jako pro pojmenovanou rouru, viz strana 85. To také znamen´ a, ˇze jedin´ y zp˚ usob, jak ˇcten´ aˇrovi “poslat” end-of-file je, ˇze vˇsichni zapisovatelé zavˇrou pˇr´ısluˇsn´ y deskriptor pro z´ apis.

118

Pˇ r´ıklad: roura mezi dvˇ ema procesy shell: ls / | more

int pd[2]; pipe(pd); switch(fork()) {

producent (d´ıtˇe)

konzument (rodiˇc) default:

case 0: close(1);

close(0);

dup(pd[1]);

dup(pd[0]);

close(pd[0]);

close(pd[0]);

close(pd[1]);

close(pd[1]);

execl("/bin/ls", "/bin/ls",

execl("/bin/more", "/bin/more", NULL);

"/", NULL);

pd[1]

pd[0]

/bin/ls

/bin/more

• zavˇren´ı z´ apisového deskriptoru pd[1] (ozn. ⊲) v procesu konzumenta je nutné, protoˇze jinak se na rouˇre nikdy nedetekuje konec souboru. • ˇctec´ı deskriptor v procesu producenta pd[0] je také vhodné zav´ırat (ozn. ⊲), protoˇze kdyˇz konzument pˇredˇcasnˇe skonˇc´ı, dostane producent signál SIGPIPE. Kbyby deskriptor v producentovi nebyl zavˇren, producent se nedozv´ı, ˇze konzument skonˇcil, a po naplnˇen´ı bufferu roury v jádru se zablokuje. • pokud nem´ ame jistotu, ˇze pˇred volán´ım pipe() byl otevˇren deskriptor 0, mus´ıme v producentovi pouˇz´ıt dup2(pd[1], 1), protoˇze dup(pd[1]) by mohl vr´ atit deskriptor 0 m´ısto poˇzadovaného 1. Také je tˇreba testovat, zda neplat´ı pd[1] == 1, abychom si nechtˇenˇe nezavˇreli rouru. Podobnˇe je tˇreba otestovat pd[0] == 0 v konzumentovi. • je lepˇs´ı vytváˇret rouru od syna k otci, protoˇze typicky nejdˇr´ıv skonˇc´ı proces zapisuj´ıc´ı do roury, ˇctouc´ı proces pˇreˇcte zbyl´ a data, zpracuje je, nˇeco vyp´ıˇse a teprve pak skonˇc´ı. shell ˇcek´ a na otce, takˇze kdyˇz smˇeˇruje roura od otce k synovi, otec skonˇc´ı, shell vyp´ıˇse prompt, ale pak jeˇstˇe syn vyp´ıˇse v´ ystup. Moˇzn´ ym ˇreˇsen´ım je ˇcek´ an´ı otce na skonˇcen´ı syna, jenˇze to se nedá zajistit, pokud otec provede exec. • p˚ uvodn´ı Bourne shell stav´ı rouru tak, ˇze posledn´ı proces v rouˇre vytvoˇr´ı pˇredposledn´ı jako svého syna, ten vytvoˇr´ı pˇredchoz´ı proces a tak se postupuje aˇz k zaˇca´tku roury. • v shellu bash jsou vˇsechny procesy v rouˇre pˇr´ımo potomky shellu (shell volá fork() tolikr´ at, jak dlouh´ a je roura). Shell pˇred vyps´ an´ım promptu ˇcek´ a, aˇz vˇsechny procesy roury skonˇc´ı. 119

Sd´ılen´ a pamˇ et’ – u ´ vod • pajpy a soubory jako metody meziprocesové komunikace vyˇzaduj´ı systémová vol´ an´ı • v´ yhoda: procesy nemohou poˇskodit adresov´ y prostor jiného procesu • nev´ yhoda: velká reˇzie pro systémová volán´ı, typicky read, write • sd´ılená pamˇet’ je namapován´ı ˇca´sti pamˇeti do adresového prostoru v´ıce proces˚ u • odstranˇen´ı nev´ yhody, ztr´ ata dosavadn´ı v´ yhody • synchronizace pˇr´ıstupu do sd´ılené pamˇeti – System V semafory – POSIX semafory bez nutnosti systémového volán´ı v bˇeˇzném pˇr´ıpadˇe

• mapován´ı soubor˚ u do pamˇeti je jednou z implementac´ı sd´ılené pamˇeti. Pro popis u ´ seku sd´ılené pamˇeti pouˇz´ıv´ a soubor. • takto implementovan´ a sd´ılená pamˇet’ je tedy pravidelnˇe zapisována na disk • pro sd´ılen´ı bez reˇzie z´ apisu zmˇenˇen´ ych dat na disk je moˇzné pouˇz´ıt memory based filesystém, napˇr´ıklad tmpfs (Solaris, NetBSD – zde byl tmpfs naps´ an v roce 2005 jako souˇca´st Summer of Code sponzorovaného firmou Google, FreeBSD má podobnou vlastnost pod n´ azvem memory disk ). Jako tzv. backing store pro pamˇet’ové str´ anky patˇr´ıc´ı tˇemto filsystém˚ um je obecnˇe moˇzné pouˇz´ıt swap oblast na disku.

120

Mapov´ an´ı soubor˚ u do pamˇ eti (1) void *mmap(void *addr, size t len, int prot, int flags, int fildes, off t off ); • do pamˇet’ového prostoru procesu od adresy addr (0 . . . adresu pˇridˇel´ı j´ adro) namapuje u ´ sek délky len zaˇc´ınaj´ıc´ı na pozici off souboru reprezentovaného deskriptorem fildes. • vrac´ı adresu namapovaného u ´ seku nebo MAP FAILED. • v prot je OR-kombinace PROT READ (lze ˇc´ıst), PROT WRITE (lze zapisovat), PROT EXEC (lze spouˇstˇet), nebo PROT NONE (nelze k dat˚ um pˇristupovat). atn´ı • ve flags je OR-kombinace MAP PRIVATE (zmˇeny jsou priv´ pro proces, neukl´ adaj´ı se do souboru), MAP SHARED (zmˇeny se ukl´ adaj´ı do souboru), MAP FIXED (j´ adro nezmˇen´ı addr).

• mapován´ı soubor˚ u do pamˇeti je alternativou ke zpracov´ an´ı soubor˚ u pomoc´ı read(), write(), lseek(). Po namapován´ı lze se souborem pracovat jako s datovou strukturou v pamˇeti. Soubor se nekop´ıruje cel´ y do pamˇeti, alokuj´ı se pouze str´ anky na které se pˇristupuje. Pokud je potˇreba str´ anku uvolnit, a obsah se ukl´ ad´ a zpˇet do souboru (pˇri MAP SHARED) nebo do swapu – pouˇz´ıv´ se mechanismus copy-on-write (pˇri MAP PRIVATE). • pˇri pouˇzit´ı MAP PRIVATE vid´ım na Solarisu vˇsechny zmˇeny provedené jin´ ymi procesy, které namapovaly sd´ılenˇe, aˇz do té doby, kdy do str´ anky zap´ıˇsu – v tom okamˇziku se vytvoˇr´ı kopie str´ anky a dalˇs´ı takové zmˇeny jiˇz nevid´ım. Na FreeBSD tyto zmˇeny nevid´ım ani pˇred z´ apisem. Viz specifikace: ,,It is unspecified whether modifications to the underlying object done after the MAP PRIVATE mapping is established are visible through the MAP PRIVATE mapping.” • hodnota off+len m˚ uˇze pˇrekraˇcovat aktuáln´ı velikost souboru, za konec souboru ale nelze zapisovat a soubor tak prodlouˇzit - proces by obdrˇzel signál SIGSEGV nebo SIGBUS. Sign´ al dostanu stejnˇe tak v situaci, kdy do readonly namapovaného segmentu zkus´ım zapsat (je to logické, pˇriˇrazen´ı nem´ a n´ avratovou hodnotu kterou byste mohli otestovat). • mapuje se vˇzdy po cel´ ych str´ ank´ ach, hodnoty off (a pˇri MAP FIXED i addr) mus´ı b´ yt spr´ avnˇe zarovnané. Posledn´ı str´ anka je za koncem souboru doplnˇena nulami a tento u ´ sek se nikdy nepˇrepisuje do souboru. • pˇr´ıstup do namapovaného u ´ seku, ale za posledn´ı existuj´ıc´ı str´ anku namapovaného objektu, zp˚ usob´ı signál SIGBUS nebo SIGSEGV. • namapován´ı souboru nahrad´ı pˇr´ıpadné pˇredchoz´ı mapován´ı str´ anek v rozsahu addr aˇz addr+len. 121

• existuj´ıc´ı rozˇs´ıˇren´ı (nejsou souˇca´st´ı UNIX03): – pˇr´ıznak MAP ANON ve FreeBSD a Solarisu – vytvoˇren´ı anonymn´ıho segmentu bez vazby na soubor, deskriptor mus´ı b´ yt -1. Mapuje se tak anonymn´ı objekt, kter´ y jak v´ıme má m´ısto fyzického uloˇzen´ı na swapu (tedy nen´ı trvalé). Linux má podobnou funkcionalitu pˇres MAP ANONYMOUS. y ob– v IRIXu lze pomoc´ı MAP AUTOGROW automaticky zvˇetˇsit namapovan´ jekt pˇri pˇr´ıstupu za jeho stávaj´ıc´ı konec.

Mapov´ an´ı soubor˚ u do pamˇ eti (2) int msync(void *addr, size t len, int flags ); • zap´ıˇse zmˇenˇené str´ anky v u ´ seku len bajt˚ u od adresy addr do souboru. Hodnota flags je OR-kombinace – MS ASYNC . . . asynchronn´ı z´ apis – MS SYNC . . . synchronn´ı z´ apis a data, kter´ a se liˇs´ı od – MS INVALIDATE . . . zruˇsit namapovan´ obsahu souboru int munmap(void *addr, size t len ); • zap´ıˇse zmˇeny, zruˇs´ı mapován´ı v délce len od adresy addr. int mprotect(void *addr, size t len, int prot ); • zmˇen´ı pˇr´ıstupová práva k namapovanému u ´ seku souboru. Hodnoty prot jsou stejné jako u mmap().

• uloˇzen´ı zmˇen do souboru na disk je zaruˇcené aˇz po proveden´ı msync() nebo munmap(), ale ostatn´ı procesy, které maj´ı soubor namapován, vid´ı zmˇeny hned. • mapován´ı pamˇeti a nastavován´ı pˇr´ıstupov´ ych práv pouˇz´ıv´ a napˇr. knihovna Electric Fence, kter´ a slouˇz´ı pro ladˇen´ı chyb pˇri práci s dynamickou pamˇet´ı.

122

Pˇ r´ıklad: mapov´ an´ı soubor˚ u do pamˇ eti int main(int argc, char *argv[]) { int fd, fsz; char *addr, *p1, *p2, c; fd = open(argv[1], O RDWR); fsz = lseek(fd, 0, SEEK END); p1 = addr = mmap(0, fsz, PROT READ|PROT WRITE, MAP SHARED, fd, 0); p2 = p1 + fsz - 1; while(p1
Tento program otoˇc´ı poˇrad´ı znak˚ u v souboru (zap´ıˇse soubor od konce k zaˇca´tku).

123

Dynamick´ y pˇ r´ıstup ke knihovn´ am void *dlopen(const char *file, int mode ); • zpˇr´ıstupn´ı knihovnu v souboru file, vr´ at´ı handle nebo NULL. • v mode je OR-kombinace RTLD NOW (okamˇzité relokace), RTLD LAZY (odloˇzené relokace), RTLD GLOBAL (symboly budou glob´ alnˇe dostupné), RTLD LOCAL (nebudou glob´ alnˇe dostupné). void *dlsym(void *handle, const char *name ); • vr´ at´ı adresu symbolu zadaného jména z knihovny. int dlclose(void *handle ); • ukonˇc´ı pˇr´ıstup ke knihovnˇe. char *dlerror(void); • vr´ at´ı textov´ y popis chyby pˇri práci s knihovnami.

• pomoc´ı tˇechto funkc´ı lze implementovat dynamicky nahr´ avané plug-in moduly naˇc´ıtané aplikac´ı podle potˇreby (napˇr. podle obsahu jej´ıho konfiguraˇcn´ıho souboru). • dynamick´ ym naˇc´ıt´ an´ım knihoven se také d´ a vyˇreˇsit situace, kdy potˇrebujeme vyuˇz´ıt nˇekolik knihoven, které definuj´ı symbol se stejn´ ym jménem. Jedna knihovna se pˇr´ımo pˇrilinkuje k programu, k ostatn´ım se pˇristupuje pomoc´ı dlopen(). • soubor mus´ı b´ yt ve spr´ avném formátu (sd´ılená knihovna .so ve formátu ELF ), napˇr´ıklad u gcc to znamen´ a pouˇz´ıt pˇrep´ınaˇc -shared. • konstanty pro mode: u) jsou provedeny – RTLD NOW . . . vˇsechny relokace (vyˇreˇsen´ı vˇsech odkaz˚ okamˇzitˇe po nataˇzen´ı knihovny, aplikace má jistotu, ˇze jsou vˇsechny symboly pˇr´ıstupné – RTLD LAZY . . . relokace mohou b´ yt odloˇzeny aˇz do chv´ıle pouˇzit´ı symbolu yt pouˇzity pˇri zpracován´ı – RTLD GLOBAL . . . symboly z knihovny mohou b´ relokac´ı v ostatn´ıch knihovnách a jsou dostupné pomoc´ı dlopen(0, RTLD GLOBAL) • speci´ aln´ı handle RTLD NEXT hled´ a symbol pouze v knihovnách nahran´ ych po knihovnˇe, ve které je vol´ an´ı dlsym(). Hod´ı se pro pˇredefinován´ı existuj´ıc´ıch funkc´ı, pokud v redefinované funkci potˇrebujeme volat p˚ uvodn´ı. Knihovna s novou funkc´ı se nahr´ av´ a jako prvn´ı (napˇr. pomoc´ı promˇenné LD PRELOAD), adresu p˚ uvodn´ı funkce z´ısk´ a volán´ım dlsym(RTLD NEXT, fn name ).

124

• vˇsechny tyto funkce jsou souˇca´st´ı dynamického linkeru, kter´ y má kaˇzd´ a dynamicky slinkovan´ a aplikace namapovan´ y ve svém adresovém prostoru. Viz také strany 31 a 113.

Pˇ r´ıklad: zpˇ r´ıstupnˇ en´ı knihovny void *handle; double y, x = 1.3; double (*fun)(double); char *libname = "libm.so", *fn name = "sin"; if ((handle = dlopen(libname, RTLD NOW)) != NULL) { fprintf(stderr, "%s\n", dlerror()); exit(1); } fun = dlsym(handle, fn name); if (err = dlerror()) { fprintf(stderr, "%s\n", err); exit(1); } y = fun(x); dlclose(handle);

• zde se vol´ a funkce sin() z matematické knihovny libm.so. • funkce dlsym() vr´ at´ı adresu symbolu daného jména, ale vˇzdy jako ukazatel na void, neprob´ıhá ˇza´dná typová kontrola ani nen´ı k dispozici ˇza´dná informace o typu symbolu. Ten, kdo tuto adresu pouˇz´ıv´ a, mus´ı zajistit jej´ı spr´ avné pˇretypován´ı. • pˇri pouˇzit´ı knihoven v C++ je tˇreba si uvˇedomit, ˇze C++ pouˇz´ıv´ a name mangling, tj. do jména funkce (metody) je zak´ odováno pˇr´ıpadné jméno tˇr´ıdy nebo namespace a typy parametr˚ u.

125

Obsah • u ´ vod, v´ yvoj UNIXu a C, program´ atorské n´ astroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupová práva, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • sign´ aly • synchronizace a komunikace proces˚ u • s´ıt’ová komunikace • vl´ akna, synchronizace vl´ aken • ??? - bude definováno pozdˇeji, podle toho kolik zbyde ˇcasu

Sign´ aly • informuj´ı proces o v´ yskytu urˇcité ud´ alosti. • na uˇzivatelské u ´ rovni zpˇr´ıstupˇ nuj´ı mechanismy pˇreruˇsen´ı. • kategorie signál˚ u: – chybov´ e ud´ alosti generované bˇeˇz´ıc´ım procesem, napˇr. pokus o pˇr´ıstup mimo pˇridˇelenou oblast pamˇeti (SIGSEGV) – asynchronn´ı ud´ alosti vznikaj´ıc´ı mimo proces, napˇr. signál od jiného procesu, vyprˇsen´ı nastaveného ˇcasu (SIGALRM), odpojen´ı termin´ alu (SIGHUP), stisk Ctrl-C (SIGINT) • nejjednoduˇsˇs´ı mechanismus pro komunikaci mezi procesy – nesou pouze informaci o tom, ˇze nastala nˇejak´ a ud´ alost. • zpracovávaj´ı se asynchronnˇe – pˇr´ıchod signálu pˇreruˇs´ı bˇeh procesu a vyvol´ a handler.

126

• se signálem nen´ı sv´ azána ˇza´dná jiná informace neˇz ˇc´ıslo signálu. • po n´ avratu z handleru (pokud k nˇemu dojde) proces pokraˇcuje od m´ısta pˇreruˇsen´ı. • historicky signály vznikly jako mechanismus pro ,,n´ asilné” ukonˇcen´ı procesu. Z toho vyplynul i n´ azev funkce kill() pro posl´ an´ı signálu.

Posl´ an´ı sign´ alu int kill(pid t pid, int sig ); • poˇsle signál s ˇc´ıslem sig procesu (nebo skupinˇe proces˚ u) podle hodnoty pid: – > 0 . . . procesu s ˇc´ıslem pid – == 0 . . . vˇsem proces˚ um ve stejné skupinˇe – == -1 . . . vˇsem proces˚ um, kromˇe systémov´ ych – < -1 . . . proces˚ um ve skupinˇe abs(pid) • sig == 0 znamen´ a, ˇze se pouze zkontroluje opr´ avnˇen´ı poslat signál, ale ˇza´dn´ y signál se nepoˇsle. • právo procesu poslat signál jinému procesu z´ avis´ı na UID obou proces˚ u.

• proces s EUID == 0 m˚ uˇze poslat signál libovolnému procesu. • ostatn´ı procesy: – Linux, Solaris: RUID nebo EUID procesu, kter´ y poslal sign´ al, se mus´ı shodovat s re´ aln´ ym UID nebo saved set-user-ID c´ılového procesu. – FreeBSD: mus´ı se shodovat EUID obou proces˚ u. – IRIX: RUID nebo EUID procesu, kter´ y poslal signál, se mus´ı shodovat s re´ aln´ ym nebo efektivn´ım UID nebo saved set-user-ID c´ılového procesu.

127

Oˇ setˇ ren´ı sign´ al˚ u • pokud proces neˇrekne jinak, provede se v z´ avislosti na konkrétn´ım signálu implicitn´ı akce, tj. bud’: – ukonˇcen´ı procesu (exit) – ukonˇcen´ı procesu plus coredump (core) – ignorován´ı signálu (ignore) – pozastaven´ı procesu (stop) – pokraˇcován´ı pozastaveného procesu (continue) • proces také m˚ uˇze nastavit ignorován´ı signálu • nebo signál oˇsetˇren´ı uˇzivatelsky definovanou funkc´ı (handler), po n´ avratu z handleru proces pokraˇcuje od m´ısta pˇreruˇsen´ı signály SIGKILL a SIGSTOP vˇzdy vyvolaj´ı implicitn´ı akci (zruˇsen´ı, resp. pozastaven´ı).

• vytvoˇren´ı core dumpu znamen´ a uloˇzen´ı kompletn´ıho obsahu pamˇeti procesu do souboru, typicky se jménem core • vˇetˇsina signál˚ u implicitnˇe ukonˇc´ı proces, nˇekteré nav´ıc vytvoˇr´ı jiˇz zmiˇ novan´ y core dump, kter´ y je moˇzné n´ aslednˇe pouˇz´ıt pro ladic´ı u ´ˇcely.

128

Pˇ rehled sign´ al˚ u (1) signály je moˇzné logicky rozdˇelit do nˇekolika skupin. . . detekovan´ e chyby: SIGBUS

pˇr´ıstup k nedef. ˇca´sti pamˇet’ového objektu (core)

SIGFPE

chyba aritmetiky v pohyblivé ˇca´rce (core)

SIGILL

nepovolen´ a instrukce (core)

SIGPIPE

z´ apis do roury, kterou nikdo neˇcte (exit)

SIGSEGV

pouˇzit´ı nepovolené adresy v pamˇeti (core)

SIGSYS

chybné systémové volán´ı (core)

SIGXCPU

pˇrekroˇcen´ı ˇcasového limitu CPU (core)

SIGXFSZ

pˇrekroˇcen´ı limitu velikosti souboru (core)

• generován´ı tˇechto signál˚ u vych´ az´ı z chyb programu • pro signály BUS, FPE, ILL a SEGV nen´ı normou pˇresnˇe definována pˇr´ıˇcina, ale obvykle jsou to chyby detekované hardwarem • pro tyto ˇctyˇri signály také plat´ı tato speci´ aln´ı pravidla (podrobnosti viz kapitola 2.4 Signal Concepts v normˇe UNIX03): – pokud byly nastavené jako ignorované volán´ım sigaction, je chován´ı programu po té, co je mu takov´ y signál posl´ an, normou nedefinováno – n´ avratová hodnova handleru je nedefinována – n´ asledek situace, kdy jeden z tˇechto signálu je maskován v okamˇziku jeho vygenerovan´ı je nedefinovan´ y • jin´ ymi slovy – pokud je hardwarem detekovan´ a chyba reáln´ a (sign´ al nen´ı posl´ an pˇres kill), váˇs program se pˇres tuto chybu nemus´ı v˚ ubec dostat. Nen´ı bezpeˇcné chybu ignorovat, pokraˇcovat v bˇehu po n´ avratu z handleru nebo odd´ alit ˇreˇsen´ı pomoc´ı zamaskován´ı. Pokud máte pro tyto signály handler, je potˇ reba poˇ reˇ sit danou situaci jak uzn´ ate za vhodn´ e a pak ukonˇ cit program. • pozn´ amka: pokud je nˇeco normou nedefinováno (undefined ), obecnˇe to znamen´ a, ˇze se neoˇcek´ av´ a, ˇze by program´ ator potˇreboval zn´ at pˇresné chován´ı v takové situaci. Pokud je to potˇreba, pravdˇepodobnˇe je ve vaˇsem programu nˇeco ˇspatnˇe. Jako vˇzdy, urˇcite by se naˇsly vyj´ımky potvrzuj´ıc´ı pravidlo.

129

Pˇ rehled sign´ al˚ u (2) generovan´ e uˇ zivatelem nebo aplikac´ı: SIGABRT

ukonˇcen´ı procesu (core)

SIGHUP

odpojen´ı termin´ alu (exit)

SIGINT

stisk speci´ aln´ı kl´ avesy Ctrl-C (exit)

SIGKILL

zruˇsen´ı procesu (exit, nelze oˇ setˇ rit ani ignorovat)

SIGQUIT

stisk speci´ aln´ı kl´ avesy Ctrl-\ (core)

SIGTERM

zruˇsen´ı procesu (exit)

SIGUSR1

uˇzivatelsky definovan´ y signál 1 (exit)

SIGUSR2

uˇzivatelsky definovan´ y signál 2 (exit)

• SIGINT a SIGQUIT jsou obvykle generovány z terminálu (Ctrl-C a Ctrl-\) a lze je pˇredefinovat pˇr´ıkazem stty nebo pomoc´ı funkce tcsetattr(). • SIGTERM je defaultn´ı signál pro pˇr´ıkaz kill • SIGUSR1 a SIGUSR2 nejsou pouˇzity ˇza´dn´ ym systémov´ ym volán´ım a jsou plnˇe k dispozici uˇzivateli • SIGALRM a souvisej´ıc´ı funkce alarm() se pouˇz´ıvaj´ı pro odmˇeˇrován´ı ˇcasov´ ych interval˚ u v uˇzivatelském procesu (napˇr. pˇri implementaci timeout˚ u). • signál SIGHUP se ˇcasto pouˇz´ıv´ a jako zp˚ usob, jak oznámit bˇeˇz´ıc´ımu démonu, ˇze se zmˇenil jeho konfiguraˇcn´ı soubor a má si ho proto znovu naˇc´ıst. • zaj´ımavost: FreeBSD 5.3 obsahuje chybu, kter´ a dovol´ı za jist´ ych okolnost´ı zachytit signál SIGKILL.

130

Pˇ rehled sign´ al˚ u (3) job control: SIGCHLD

zmˇena stavu synovského procesu (ignore)

SIGCONT

pokraˇcován´ı pozastaveného procesu (continue)

SIGSTOP

pozastaven´ı (stop, nelze oˇ setˇ rit ani ignorovat)

SIGTSTP

pozastaven´ı z terminálu Ctrl-Z (stop)

SIGTTIN

ˇcten´ı z termin´ alu procesem na pozad´ı (stop)

SIGTTOU

z´ apis na termin´ al procesem na pozad´ı (stop)

• plat´ı, ˇze nikdy nen´ı povoleno v´ıce proces˚ um najednou ˇc´ıst z kontroln´ıho termin´ alu, ale v´ıce proces˚ u najednou m˚ uˇze na termin´ al zapisovat.

Pˇ rehled sign´ al˚ u (4) ˇ casovaˇ ce: SIGALRM

plánované ˇcasové pˇreruˇsen´ı (exit)

SIGPROF

vyprˇsen´ı profiluj´ıc´ıho ˇcasovaˇce (exit)

SIGVTALRM

vyprˇsen´ı virtu´ aln´ıho ˇcasovaˇce (exit)

r˚ uzn´ e: SIGPOLL

testovateln´ a ud´ alost (exit)

SIGTRAP

ladic´ı pˇreruˇsen´ı (core)

SIGURG

urgentn´ı ud´ alost na soketu (ignore)

131

Nastaven´ı obsluhy sign´ al˚ u int sigaction(int sig, const struct sigaction *act, struct sigaction *oact ); • nastav´ı obsluhu signálu sig podle act a vr´ at´ı pˇredchoz´ı nastaven´ı v oact. • obsah struktury sigaction: – void (*sa handler )(int) . . . SIG DFL, SIG IGN, nebo adresa handleru – sigset t sa mask . . . signály blokované v handleru, nav´ıc je blokován signál sig – int sa flags . . . SA RESETHAND (pˇri vstupu do handleru nastavit SIG DFL), SA RESTART (restartovat pˇreruˇsen´ a systémová vol´ an´ı), SA NODEFER (neblokovat signál sig bˇehem obsluhy)

• kdyˇz je act == NULL, pouze se zjist´ı nastaven´ı obsluhy, nemˇen´ı se. Jestliˇze n´ as pˇredchoz´ı nastaven´ı nezaj´ım´ a, lze pouˇz´ıt oact == NULL. • pokud nen´ı nastaveno SA RESTART, systémová volán´ı aktivn´ı v bodˇe pˇr´ıchodu signálu skonˇc´ı s chybou EINTR. Restartován´ı nemus´ı fungovat pro vˇsechna systémová vol´ an´ı, napˇr. na FreeBSD je select() pˇreruˇsen signálem vˇzdy, i kdyˇz je nastaveno SA RESTART (pozn: nemus´ı b´ yt pravda u souˇcasn´ ych verz´ı, nezkouˇsel jsem to na nich). • pozor na problém vz´ ajemného vylouˇcen´ı mezi procesem a handlerem, popˇr. mezi handlery pro r˚ uzné signály. Jestliˇze je nastaveno SA NODEFER, mˇel by b´ yt handler reentrantn´ı. • v signálovém handleru by se mˇely pouˇz´ıvat pouze funkce, které jsou pro takové pouˇzit´ı bezpeˇcné. Mus´ı bud’ b´ yt reentrantn´ı, nebo je nutné zajistit, aby nepˇriˇsel signál v nevhodnou dobu (napˇr. uvnitˇr funkce pˇrijde signál, v jehoˇz handleru se vol´ a stejn´ a funkce). Bezpeˇcné funkce ze systémové knihovny jsou vyjmenovány v manu´ alové str´ ance k funkci sigaction() (v SUSv3 jsou v kapitole System Interfaces: General Information, Signal Concepts). • funkce sigaction() je obecnˇejˇs´ı neˇz starˇs´ı funkce signal() a sigset(). • pro v´ yskok z handleru signálu jinam neˇz na m´ısto vzniku signálu se daj´ı pouˇz´ıt funkce sigsetjmp() a siglongjmp(). Pozor na to, ˇze v tomto pˇr´ıpadˇe si mus´ıme b´ yt jisti, ˇze v okamˇziku pˇr´ıchodu signálu nen´ı program uvnitˇr nereentrantn´ı funkce. V´ yskokem z handleru do hlavn´ıho programu nen´ı vykon´ av´ an´ı takové funkce ukonˇceno a mohou nastat stejné problémy jako pˇri vol´ an´ı nereentrantn´ı funkce pˇr´ımo z handleru.

132

Pˇ r´ıklad: ˇ casovˇ e omezen´ y vstup #define BUFSZ 4096 void handler(int sig) { fprintf(stderr," !!! TIMEOUT !!! \n"); } int main() { char buf[BUFSZ]; struct sigaction act; int sz; act.sa handler = handler; sigemptyset(&act.sa mask); act.sa flags = 0; sigaction(SIGALRM, &act, NULL); alarm(5); sz = read(0, buf, BUFSZ); if(sz > 0) write(1, buf, sz); exit(0); }

• lze pouˇz´ıvat i ˇcasovaˇce s jemnˇejˇs´ım rozliˇsen´ım neˇz 1 s. Nastavuj´ı a testuj´ı se funkcemi setitimer() a getitimer(). Pˇri vyprˇsen´ı pos´ılaj´ı signály procesu, kter´ y ˇcasovaˇce nastavil: aln´ y ˇcas, pos´ıl´ a SIGALRM – ITIMER REAL . . . mˇeˇr´ı re´ – ITIMER VIRTUAL . . . mˇeˇr´ı virtu´ aln´ı ˇcas (pouze ˇcas, kdy proces bˇeˇz´ı), pos´ıl´ a SIGVTALRM aln´ı ˇcas a ˇcas, kdy systém bˇeˇz´ı na konto – ITIMER PROF . . . mˇeˇr´ı virtu´ procesu, pos´ıl´ a SIGPROF • pozn: v pˇr´ıkladu je drobn´ y problém: funkce fprintf() nen´ı bezpeˇcn´ a pro pouˇzit´ı v handleru signálu.

133

Blokov´ an´ı sign´ al˚ u • blokované signály budou procesu doruˇceny a zpracovány aˇz po odblokován´ı. int sigprocmask(int how, const sigset t *set, sigset t *oset ); • nastav´ı masku blokovan´ ych signál˚ u a vr´ at´ı starou masku. an´ı signál˚ u co se maj´ı blokovat, pro • how – SIG BLOCK pro pˇrid´ odebr´ an´ı SIG UNBLOCK, pro kompletn´ı zmˇenu masky SIG SETMASK • pro manipulaci s maskou signál˚ u slouˇz´ı funkce: sigaddset(), sigdelset(), sigemptyset(), sigfillset(), sigismember() int sigpending(sigset t *set ); • vr´ at´ı ˇcekaj´ıc´ı zablokované signály.

• je rozd´ıl mezi ignorován´ım a blokován´ım signálu. Ignorovan´ y signál jádro zahod´ı a proces ho nedostane, blokovan´ y signál proces dostane po jeho odblokován´ı. • z´ avis´ı na implementaci, zda pˇri v´ıcen´ asobném doruˇcen´ı stejného signálu procesu, kter´ y má tento signál zablokovan´ y, bude signál po odblokován´ı oˇsetˇren jednou nebo v´ıcekrát.

134

Pˇ r´ıklad: blokov´ an´ı sign´ al˚ u sigset t sigs, osigs; structure sigaction sa; sigfillset(&sigs); sigprocmask(SIG BLOCK, &sigs, &osigs); switch(cpid = fork()) { case -1: /* Chyba */ sigprocmask(SIG SETMASK, &osigs, NULL); ... case 0: /* Synovsk´ y proces */ sa.sa handler = h cld; sigemptyset(&sa.sa mask); sa.sa flags = 0; sigaction(SIGINT, &sa, NULL); sigprocmask(SIG SETMASK, &osigs, NULL); ... default: /* Rodiˇ covsk´ y proces */ sigprocmask(SIG SETMASK, &osigs, NULL); ... }

• blokován´ı je vhodné pouˇz´ıt tam, kde oˇsetˇren´ı pˇreruˇsen´ı uprostˇred posloupnosti operac´ı by bylo pˇr´ıliˇs sloˇzité, nebo kde korektn´ı oˇsetˇren´ı nen´ı jinak moˇzné. • pˇr.: proces vytváˇr´ı potomky pomoc´ı fork() a je potˇreba, aby potomci mˇeli jin´ y handler signál˚ u neˇz rodiˇcovsk´ y proces. • v uvedeném pˇr´ıkladˇe by bez blokován´ı signál˚ u mohl synovsk´ y proces dostat signál dˇr´ıv, neˇz stihne zmˇenit handler. • dalˇs´ı pˇr´ıklad je proces, kter´ y pˇri vyprˇsen´ı timeoutu pˇreruˇs´ı provádˇenou posloupnost operac´ı vol´ an´ım siglongjmp() zevnitˇr handleru signálu. Je potˇreba zablokovat signál SIGALRM bˇehem provádˇen´ı atomick´ ych podposloupnost´ı (tj. takov´ ych, které se mus´ı provést bud’ celé, nebo v˚ ubec ne).

135

ˇ an´ı na sign´ Cek´ al int pause(void); • pozastav´ı volaj´ıc´ı proces do pˇr´ıchodu signálu. Vol´ an´ı se vr´ at´ı po n´ avratu z handleru. int sigsuspend(const sigset t *sigmask ); • jako pause(), ale nav´ıc po dobu ˇcek´ an´ı masku blokovan´ ych signál˚ u zmˇen´ı na sigmask. int sigwait(const sigset t *set, int *sig ); • ˇcek´ a na pˇr´ıchod signálu z mnoˇziny set (tyto signály mus´ı b´ yt pˇredt´ım zablokované), ˇc´ıslo signálu vr´ at´ı v sig. • nevol´ a se handler signálu (to ale nen´ı v normˇe jednoznaˇcnˇe definováno).

• pomoc´ı tˇechto funkc´ı a blokován´ı signál˚ u se implementuje synchronn´ı obsluha signál˚ u. Proces nejprve zablokuje signály, které ho zaj´ımaj´ı, a pak na nˇe ve vhodn´ ych chv´ıl´ıch bud’ ˇcek´ a, nebo jen testuje (pomoc´ı sigpending()), zda signál pˇriˇsel, a pokud ne, pokraˇcuje d´ al.

136


Probl´ em: konflikt pˇ ri sd´ılen´ı dat • máme strukturu struct { int a, b; } shared ; • for( ; ; ) { /* neatomick´ a operace */ a = shared.a; b = shared.b; if (a != b) printf("NEKONZISTENTN´ I STAV"); /* neatomick´ a operace */ shared.a = val; shared.b = val; } • jestliˇze tento cyklus spust´ıme ve dvou r˚ uzn´ ych procesech (nebo vl´ aknech), které obˇe sd´ılej´ı stejnou strukturu shared a maj´ı r˚ uzné hodnoty val, bude doch´ azet ke konflikt˚ um. • pˇr´ıˇcina: operace na zv´ yraznˇen´ ych ˇra´dc´ıch nejsou atomické.

137

• ani operace, kterou lze v C zapsat jedn´ım pˇr´ıkazem, nemus´ı b´ yt atomická. Pˇr.: na RISCov´ ych procesorech se pˇr´ıkaz a++ typicky pˇreloˇz´ı jako sekvence: load reg,[a] inc reg store [a],reg a to z toho d˚ uvodu, ˇze na této architektuˇre nelze inkrementovat ˇc´ıslo pˇr´ımo v pamˇeti. Pro tyto pˇr´ıpady má napˇr´ıklad Solaris sadu funkc´ı atomic add(3c), jejichˇz pouˇzit´ı je mnohem rychlejˇs´ı neˇz klasické zamykac´ı mechanismy. V´ıce viz strana 201. • obecnˇe obdobn´ y problém nast´ av´ a, kdyˇz v´ıce proces˚ u sd´ıl´ı nˇejak´ y systémov´ y zdroj.

Sc´ en´ aˇ r konfliktu Procesy A(val==1) a B(val==2)

a

b

1.

poˇca´teˇcn´ı stav struktury

?

?

2.

proces A zap´ıˇse do poloˇzky a

1

?

3.

proces B zap´ıˇse do poloˇzky a

2

?

4.

proces B zap´ıˇse do poloˇzky b

2

2

5.

proces A zap´ıˇse do poloˇzky b

2

1

6.

struktura je v nekonzistentn´ım stavu a jeden z proces˚ u to zjist´ı.

• dalˇs´ı moˇznost: 1. struktura je v konzistentn´ım stavu, napˇr. (1, 1) 2. proces B zap´ıˇse 2 do poloˇzky a 3. proces A pˇreˇcte hodnotu struktury (2, 1) dˇr´ıve, neˇz proces B stihne zapsat poloˇzku b

138

ˇ sen´ı: vz´ Reˇ ajemn´ e vylouˇ cen´ı proces˚ u • je potˇreba zajistit atomicitu operac´ı nad strukturou, tzn. jeden proces provád´ı modifikaci a dokud neuvede strukturu do konzistentn´ıho stavu, druh´ y proces s n´ı nem˚ uˇze manipulovat. Procesy A(val==1) a B(val==2)

a

b

poˇca´teˇcn´ı stav struktury

?

?

proces A zap´ıˇse do poloˇzky a

1

?

proces B mus´ı ˇcekat

1

?

proces A zap´ıˇse do poloˇzky b

1

1

proces B zap´ıˇse do poloˇzky a

2

1

6.

proces B zap´ıˇse do poloˇzky b

2

2

7.

Struktura je v konzistentn´ım stavu.

1.   2.   3.    4.   5. 

• je tˇreba zajistit vz´ ajemné vylouˇcen´ı i pˇri ˇcten´ı, aby ˇctouc´ı proces nepˇreˇcetl nekonzistentn´ı obsah struktury uprostˇred zmˇen. Pˇri z´ apisu je nutné vylouˇcit vˇsechny ostatn´ı procesy, ale pˇri ˇcten´ı staˇc´ı vylouˇcit jen z´ apis, souˇcasné ˇcten´ı v´ıce procesy nevad´ı. • kritick´ a sekce – kus kódu, kter´ y by mˇel provádˇet pouze jeden proces (vlákno), jinak m˚ uˇze doj´ıt k nekonzistenc´ım (ˇspatnˇe pospojovan´ y vázan´ y seznam, neodpov´ıdaj´ıc´ı si indexy v datab´ azi, . . . ). Kritická sekce by mˇela b´ yt co nejkratˇs´ı, aby ostatn´ı procesy (vlákna) ˇza´daj´ıc´ı o vstup do této sekce ˇcekaly co nejkratˇs´ı moˇznou dobu.

139

Probl´ em: konflikt zapisovatel˚ uaˇ cten´ aˇ r˚ u • nˇekolik bˇeˇz´ıc´ıch proces˚ u zapisuje protokol o své ˇcinnosti do spoleˇcného log-souboru. Nov´ y z´ aznam je pˇripojen vˇzdy na konec souboru. • pokud z´ apis z´ aznamu nen´ı proveden atomickou operac´ı, m˚ uˇze doj´ıt k prom´ıch´ an´ı v´ıce souˇcasnˇe zapisovan´ ych z´ aznam˚ u. • zapisovat sm´ı vˇzdy pouze jeden proces. • dalˇs´ı procesy ˇctou data z log-souboru. • pˇri pˇreˇcten´ı právˇe zapisovaného z´ aznamu obdrˇz´ıme nesprávn´ a (ne´ upln´ a) data. • bˇehem operace z´ apisu ze souboru nelze ˇc´ıst. Kdyˇz nikdo nezapisuje, m˚ uˇze v´ıce proces˚ u ˇc´ıst souˇcasnˇe.

na lokáln´ım disku lze pro synchronizaci zapisovatel˚ u pouˇz´ıt ˇreˇsen´ı pomoc´ı pˇr´ıznaku O APPEND, které ale nemus´ı fungovat napˇr. na vzd´ aleném disku pˇr´ıstupném pˇres NFS nebo v pˇr´ıpadˇe, ˇze z´ apis jedné logovac´ı zpr´ avy je proveden v´ıce neˇz jedn´ım volán´ım write(). Nav´ıc to neˇreˇs´ı synchronizaci ˇcten´ aˇr˚ u – lze ˇc´ıst i v pr˚ ubˇehu z´ apisu.

140

ˇ sen´ı: zamyk´ Reˇ an´ı soubor˚ u • zapisuj´ıc´ı proces zamkne soubor pro z´ apis. Ostatn´ı procesy (zapisovatelé i ˇcten´ aˇri) se souborem nemohou pracovat a mus´ı ˇcekat na odemˇcen´ı z´ amku. • ˇctouc´ı proces zamkne soubor pro ˇcten´ı. Zapisovatelé mus´ı ˇcekat na odemˇcen´ı z´ amku, ale ostatn´ı ˇcten´ aˇri mohou také zamknout soubor pro ˇcten´ı a ˇc´ıst data. • v jednom okamˇziku m˚ uˇze b´ yt na souboru aktivn´ı nejv´ yˇse jeden z´ amek pro z´ apis nebo libovolnˇe mnoho z´ amk˚ u pro ˇcten´ı, ale ne oba typy z´ amk˚ u souˇcasnˇe. • z d˚ uvodu efektivity by kaˇzd´ y proces mˇel drˇzet z´ amek co nejkratˇs´ı dobu a pokud moˇzno nezamykat cel´ y soubor, ale jen u ´ sek, se kter´ ym pracuje. Preferované je pasivn´ı ˇcek´ an´ı, aktivn´ı ˇcek´ an´ı je vhodné jen na velmi kr´ atkou dobu.

dva zp˚ usoby ˇcek´ an´ı: aktivn´ı (busy waiting) – proces v cyklu testuje podm´ınku, na kterou ˇcek´ a, dokud nen´ı splnˇena pasivn´ı – proces se zaregistruje v j´ adru jako ˇcekaj´ıc´ı na podm´ınku a pak se usp´ı, jádro ho probud´ı, kdyˇz dojde ke splnˇen´ı podm´ınky

141

Synchronizaˇ cn´ı mechanismy • teoretické ˇreˇsen´ı – algoritmy vz´ ajemného vylouˇcen´ı (Dekker 1965, Peterson 1981) • z´ akaz pˇreruˇsen´ı (na 1 CPU stroji), speci´ aln´ı instrukce (test-and-set ) • lock-soubory • n´ astroje poskytované operaˇcn´ım systémem – semafory (souˇca´st System V IPC) – z´ amky pro soubory (fcntl(), flock()) – synchronizace vl´ aken: mutexy (ohraniˇcuj´ı kritické sekce, pouze jedno vl´ akno m˚ uˇze drˇzet mutex), podm´ınkov´ e promˇ enn´ e (zablokuj´ı vl´ akno, dokud jiné vl´ akno nesignalizuje splnˇen´ı podm´ınky), read-write z´ amky (sd´ılené a exkluzivn´ı z´ amky, podobnˇe jako pro soubory)

• obˇe ˇreˇsen´ı potˇrebovala k dosaˇzen´ı poˇzadavaného v´ ysledku pouze sd´ılenou pamˇ et’, tj. nˇekolik promˇenn´ ych sd´ılen´ ych obˇema procesy • Dekkerovo ˇreˇsen´ı se ud´ av´ a jako prvn´ı ˇreˇsen´ı problému vz´ ajemného vylouˇcen´ı dvou proces˚ u, aniˇz by bylo nutné aplikovat naivn´ı algoritmus striktn´ıho stˇr´ıd´ an´ı, tj. pokud druh´ y proces nevykazoval z´ ajem o vstup do kritické sekce, mohl tam prvn´ı (a naopak) proces vstoupit tolikr´ at za sebou, kolikrát chtˇel. Dekkerovo ˇreˇsen´ı nen´ı v˚ ubec triviáln´ı, porovnejte s o 16 let mladˇs´ım ˇreˇsen´ım Petersonov´ ym, napˇr´ıklad na en.wikipedia.org (hledejte “Dekker’s algorithm”, “Peterson’s algorithm”) • my se nebudeme zab´ yvat teoretick´ ymi algoritmy vz´ ajemného vylouˇcen´ı ani nebudeme popisovat hardwarové mechanismy pouˇz´ıvané jádrem. Zamˇeˇr´ıme se pouze na pouˇzit´ı lock soubor˚ u (které vyuˇz´ıvaj´ı atomiˇcnosti nˇekter´ ych souborov´ ych operac´ı) a speci´ aln´ıch synchronizaˇcn´ıch n´ astroj˚ u poskytovan´ ych jádrem. • podm´ınkové promˇenné = conditional variables

142

Lock-soubory • pro kaˇzd´ y sd´ılen´ y zdroj existuje dohodnuté jméno souboru. Zamˇcen´ı zdroje se provede vytvoˇren´ım souboru, odemˇcen´ı smaz´ an´ım souboru. Kaˇzd´ y proces mus´ı otestovat, zda soubor existuje, a pokud ano, tak poˇckat. void lock(char *lockfile) { while( (fd = open(lockfile, O RDWR|O CREAT|O EXCL, 0600)) == -1) ˇ ame ve smyˇcce na odemˇcen´ı */ ; /* Cek´ close(fd); } void unlock(char *lockfile) { unlink(lockfile); }

• kl´ıˇcem k u ´ spˇechu je samozˇrejmˇe pouˇzit´ı flagu O EXCL • pˇri havárii procesu nedojde ke zruˇsen´ı pˇr´ıpadn´ ych z´ amk˚ u a ostatn´ı procesy by ˇcekaly vˇeˇcnˇe. Proto je vhodné si do lock-souboru poznamenat PID procesu, kter´ y z´ amek vytvoˇril. Proces, kter´ y ˇcek´ a na odemˇcen´ı, m˚ uˇze testovat, zda proces, kterému z´ amek patˇr´ı, stále bˇeˇz´ı. Kdyˇz ne, lze z´ amek zruˇsit a znovu zkusit vytvoˇrit. User level pˇr´ıkaz kter´ y toto um´ı a dovoluje pouˇz´ıvat lock soubory z shellov´ ych skript˚ u je napˇr´ıklad shlock(1) (na FreeBSD v /usr/ports/sysutils/shlock), teoreticky by vˇsak mohl zp˚ usobit situaci z n´ asleduj´ıc´ıho odstavce. • POZOR: jestliˇze v´ıce proces˚ u najednou zjist´ı, ˇze proces drˇz´ıc´ı z´ amek uˇz neexistuje, m˚ uˇze doj´ıt k n´ asleduj´ıc´ı chybˇe: Jeden proces smaˇze z´ amek a znovu ho vytvoˇr´ı se sv´ ym PID. Dalˇs´ı proces udˇelá totéˇz, protoˇze operace pˇreˇcten´ı obsahu souboru a jeho n´ asledného smaz´ an´ı nen´ı atomická. Ted’ si ale oba procesy mysl´ı, ˇze z´ıskaly z´ amek! • problém: funkce lock() obsahuje aktivn´ı ˇcek´ an´ı na uvolnˇen´ı z´ amku. Lze ˇreˇsit napˇr. tak, ˇze proces, kter´ y z´ısk´ a z´ amek, otevˇre pro z´ apis pojmenovanou rouru. ˇ Cekaj´ ıc´ı procesy se usp´ı t´ım, ˇze zkus´ı ˇc´ıst z roury. Souˇca´st´ı unlock() bude i zavˇren´ı roury a t´ım uvolnˇen´ı ˇcekaj´ıc´ıch proces˚ u.

143

Zamyk´ an´ı soubor˚ u: fcntl() int fcntl(int fildes, int cmd, ...); • k nastaven´ı z´ amk˚ u pro soubor fildes se pouˇz´ıv´ a cmd: amku z tˇret´ıho argumentu a – F GETLK . . . vezme popis z´ nahrad´ı ho popisem existuj´ıc´ıho z´ amku, kter´ y s n´ım koliduje – F SETLK . . . nastav´ı nebo zruˇs´ı z´ amek popsan´ y tˇret´ım argumentem, pokud nelze z´ amek nastavit, ihned vrac´ı −1 – F SETLKW . . . jako F SETLK, ale usp´ı proces, dokud nen´ı moˇzné nastavit z´ amek • tˇret´ı argument obsahuje popis z´ amku a je typu struct flock *

• zamyk´ an´ı soubor˚ u sd´ılen´ ych pˇres NFS zajiˇst’uje démon lockd. • z´ amky jsou obecnˇe dvou typ˚ u: advisory locks – pro spr´ avnou funkci mus´ı vˇsechny procesy pracuj´ıc´ı se z´ amˇcen´ ymi soubory kontrolovat z´ amky pˇred ˇcten´ım nebo z´ apisem souboru; jsou v´ıce pouˇz´ıvané mandatory locks – jestliˇze je na souboru z´ amek, budou ˇctec´ı a z´ apisové operace se souborem automaticky zablokovány, tj. z´ amek se uplatn´ı i v procesech, které ho explicitnˇe nekontroluj´ı – nedoporuˇcuj´ı se, ne vˇzdy funguj´ı (napˇr. lockd implementuje pouze advisory locking) – pro urˇcit´ y soubor se zapne nastaven´ım bitu SGID a zruˇsen´ım práva spuˇstˇen´ı pro skupinu (tj. nastaven´ı, které jinak nem´ a smysl - m´ıt set UID executable bit na souboru, kter´ y nen´ı spustiteln´ y). Systém, kter´ y mandatory locking implementuje, je napˇr´ıklad Solaris nebo Linux, FreeBSD tuto vlastnost naopak nepodporuje.

144

Zamyk´ an´ı soubor˚ u: struct flock • l type . . . typ z´ amku y z´ amek (pro ˇcten´ı), v´ıce proces˚ u – F RDLCK . . . sd´ılen´ – F WRLCK . . . exkluzivn´ı z´ amek (pro z´ apis), jeden proces – F UNLCK . . . odemˇcen´ı • l whence . . . jako u lseek(), tj. SEEK SET, SEEK CUR, SEEK END ´ seku vzhledem k l whence • l start . . . zaˇca´tek zamykaného u • l len . . . délka u ´ seku, 0 znamen´ a do konce souboru amek, pouˇz´ıv´ a se jen pro • l pid . . . PID procesu drˇz´ıc´ıho z´ avratu F GETLK pˇri n´

• soubory se daj´ı zamykat po ˇca´stech a d´ a se zjistit, kter´ y proces drˇz´ı z´ amek. Pˇri ukonˇcen´ı procesu se automaticky uvoln´ı vˇsechny jeho z´ amky. • pokud pˇri pouˇzit´ı F GETLK nen´ı pˇr´ısluˇsná ˇca´st souboru zamˇcená, je struktura flock vr´ acena bez zmˇeny kromˇe prvn´ı poloˇzky, kter´ a je nastavena na F UNLCK. • zamyk´ an´ı pˇres fcntl i lockf má jednu d˚ uleˇzitou vlastnost, kterou v´ ystiˇznˇe popisuje napˇr´ıklad manu´ alová str´ anka pro fcntl v systému FreeBSD: This interface follows the completely stupid semantics of System V and IEEE Std 1003.1-1988 (“POSIX.1”) that require that all locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process. This semantic means that applications must be aware of any files that a subroutine library may access. For example if an application for updating the password file locks the password file database while making the update, and then calls getpwnam(3) to retrieve a record, the lock will be lost because getpwnam(3) opens, reads, and closes the password database.

145

Deadlock • máme dva sd´ılené zdroje res1 a res2 chránˇené z´ amky lck1 a lck2. Procesy p1 a p2 chtˇej´ı kaˇzd´ y v´ yluˇcn´ y pˇr´ıstup k obˇema zdroj˚ um. p2

p1 lock(lck1); /* OK */ ˇ a na p2 */ lock(lck2); /* Cek´ use(res1, res2); unlock(lck2); unlock(lck1);

lock(lck2); /* OK */

ˇ a na p1 */ lock(lck1); /* Cek´ Deadlock use(res1, res2); unlock(lck2); unlock(lck1);

• pozor na poˇ rad´ı zamyk´ an´ı!

• obecnˇe deadlock vznikne, jestliˇze proces ˇcek´ a na ud´ alost, kter´ a nem˚ uˇze nastat. Zde napˇr. na sebe dva procesy ˇcekaj´ı navz´ ajem, aˇz ten druh´ y uvoln´ı z´ amek, ale k tomu nikdy nedojde. Dalˇs´ı moˇznost´ı je deadlock jednoho procesu, kter´ y ˇcte z roury a pˇredt´ım zapomnˇel uzavˇr´ıt z´ apisov´ y konec roury. Jestliˇze rouru nem´ a uˇz nikdo dalˇs´ı otevˇrenou, pokus o ˇcten´ı ze zablokuje, protoˇze nejsou zavˇreny vˇsechny kopie z´ apisového deskriptoru a tedy nenastane konec souboru na rouˇre, ale ˇctouc´ı proces sv˚ uj z´ apisov´ y deskriptor nem˚ uˇze zavˇr´ıt, protoˇze ˇcek´ a. • fcntl() provád´ı kontrolu a pˇri v´ yskytu deadlocku vr´ at´ı chybu EDEADLK. • je vhodné se deadlocku snaˇzit vyvarovat spr´ avn´ ym naprogramován´ım a nespoléhat se na kontrolu systému.

146

System V IPC • IPC je zkratka pro Inter-Process Communication • komunikace mezi procesy v r´ amci jednoho systému, tj. ’ nezahrnuje s´ıt ovou komunikaci • semafory . . . pouˇzit´ı pro synchronizaci proces˚ u • sd´ılen´ a pamˇ et’ . . . pˇred´ av´ an´ı dat mezi procesy, pˇrin´ aˇs´ı podobné problémy jako sd´ılen´ı soubor˚ u, k ˇreˇsen´ı lze pouˇz´ıt semafory • fronty zpr´ av . . . spojuj´ı komunikaci (zpr´ ava nese data) se synchronizac´ı (ˇcek´ an´ı procesu na pˇr´ıchod zpr´ avy) • prostˇredky IPC maj´ı podobnˇe jako soubory definovan´ a pˇr´ıstupová práva (pro ˇcten´ı a z´ apis) pro vlastn´ıka, skupinu a ostatn´ı.

• prostˇredky IPC existuj´ı i poté, kdy skonˇc´ı proces, kter´ y je vytvoˇril. O jejich zruˇsen´ı je nutno explicitnˇe poˇza´dat (ze shellu lze zjistit seznam IPC prostˇredk˚ u pˇr´ıkazem ipcs a smazat je pˇr´ıkazem ipcrm). Stav a obsah existuj´ıc´ıch prostˇredk˚ u IPC z˚ ust´ av´ a v platnosti, i kdyˇz s nimi právˇe nepracuje ˇza´dn´ y proces (napˇr. data ve sd´ılené pamˇeti z˚ ust´ avaj´ı, i kdyˇz ji nem´ a ˇza´dn´ y proces pˇripojenou). • dalˇ s´ı dva prostˇ redky System V IPC, kter´ e se bˇ eˇ znˇ e v unixov´ ych syst´ emech vyskytuj´ı a jsou souˇ c´ ast´ı normy, tj. sd´ılen´ a pamˇ et’ a zas´ıl´ an´ı zpr´ av, nebudeme prob´ırat. Pro sd´ılenou pamˇ et’ je moˇ zn´ e pouˇ z´ıt jiˇ z probran´ e vol´ an´ı mmap, m´ısto zas´ıl´ an´ı zpr´ av je moˇ zn´ e pouˇ z´ıt sockety (budou v nˇ ekter´ e z pˇ r´ıˇ st´ıch pˇ redn´ aˇ sek).

147

Semafory • zavedl je E. Dijkstra • semafor s je datová struktura obsahuj´ıc´ı – celé nez´ aporné ˇc´ıslo i (voln´ a kapacita) – frontu proces˚ u q, které ˇcekaj´ı na uvolnˇen´ı • operace nad semaforem: init(s, n) vypr´ azdnit s.q; s.i = n P(s) if(s.i > 0) s.i-- else uspat volaj´ ıc´ ı proces a zaˇ radit do s.q V(s) if(s.q pr´ azdn´ a) s.i++ else odstranit jeden proces z s.q a probudit ho

• P je z holandského ,,proberen te verlagen” – zkus dekrementovat, V pak ze slova ,,verhogen” – inkrementovat. • operace P(s) a V(s) lze zobecnit: hodnotu semaforu je moˇzné mˇenit o libovolnou hodnotu n . . . P(s, n), V(s, n). • Allen B. Downey: The Little Book of Semaphores, Second Edition, on-line na http://greenteapress.com/semaphores/ • bin´ arn´ı semafor má pouze hodnotu 0 nebo 1

148

Vz´ ajemn´ e vylouˇ cen´ı pomoc´ı semafor˚ u • jeden proces inicializuje semafor sem s; init(s, 1); • kritická sekce se dopln´ı o operace nad semaforem ... P(s); kritick´ a sekce; V(s); ...

inicializace semaforu na hodnotu n dovol´ı vstoupit do kritické sekce n proces˚ um. Zde semafor funguje jako z´ amek, vˇzdy ho odemyk´ a (zvyˇsuje hodnotu) stejn´ y proces, kter´ y ho zamknul (sn´ıˇzil hodnotu).

149

API pro semafory int semget(key t key, int nsems, int semflg ); • vr´ at´ı identifik´ ator pole obsahuj´ıc´ıho nsems semafor˚ u asociovan´ y s kl´ıˇcem key (kl´ıˇc IPC PRIVATE . . . priv´ atn´ı semafory, pˇri kaˇzdém pouˇzit´ı vr´ at´ı jin´ y identifikátor). semflg je OR-kombinace pˇr´ıstupov´ ych práv a konstant IPC CREAT (vytvoˇrit, pokud neexistuje), IPC EXCL (chyba, pokud existuje). int semctl(int semid, int semnum, int cmd, ...); • ˇr´ıdic´ı funkce, voliteln´ y ˇctvrt´ y parametr arg je typu union semun. int semop(int semid, struct sembuf *sops, size t nsops ); • zobecnˇené operace P a V.

• nejvˇetˇs´ı zaj´ımavost na System V implementaci semafor˚ u je skuteˇcnost, ˇze dan´ y syscall neoperuje nad jedn´ım semaforem, ale nad polem semafor˚ u, atomicky. Vˇetˇsinou vˇsak budete potˇrebovat pouze jeden semafor, tj. pole o jednom prvku. • dalˇs´ı d˚ uleˇzit´ a informace je, ˇze System V semafory jsou bohuˇzel znaˇcnˇe sloˇzité • pˇr´ıstupová práva jsou jen pro ˇcten´ı a z´ apis. • podobné schéma API funkc´ı (funkce na vytvoˇren´ı, ˇr´ızen´ı a operace) dodrˇzuj´ı i ostatn´ı System V IPC mechanismy. • jakmile je jednou pole semafor˚ u jedn´ım procesem vytvoˇreno, mohou i ostatn´ı procesy pouˇz´ıt semctl() a semop(), aniˇz by pˇredt´ım volaly semget(). To plat´ı i pro semafory vytvoˇrené s kl´ıˇcem IPC PRIVATE, pro které nelze volat semget(), protoˇze by se t´ım vytvoˇrilo nové pole semafor˚ u.

150

API pro semafory: semctl() • semnum . . . ˇc´ıslo semaforu v poli • moˇzné hodnoty cmd: – GETVAL . . . vr´ at´ı hodnotu semaforu – SETVAL . . . nastav´ı semafor na hodnotu arg.val – GETPID . . . PID procesu, kter´ y provedl posledn´ı operaci – GETNCNT . . . poˇcet proces˚ u ˇcekaj´ıc´ıch na vˇetˇs´ı hodnotu – GETZCNT . . . poˇcet proces˚ u ˇcekaj´ıc´ıch na nulu – GETALL . . . uloˇz´ı hodnoty vˇsech semafor˚ u do pole arg.array – SETALL . . . nastav´ı vˇsechny semafory podle arg.array a poˇcet semafor˚ u, pˇr´ıstupová – IPC STAT . . . do arg.buf d´ práva a ˇcasy posledn´ıch semctl() a semop() – IPC SET . . . nastav´ı pˇr´ıstupová práva u – IPC RMID . . . zruˇs´ı pole semafor˚

volán´ı semctl(semid, semnum, SETVAL, arg) odpov´ıdá obecné semaforové inicializaˇcn´ı operaci init(s, n).

151

API pro semafory: semop() • operace se provád´ı atomicky (tj. bud’ se povede pro vˇsechny semafory, nebo pro ˇza´dn´ y) na nsops semaforech podle pole sops struktur struct sembuf, kter´ a obsahuje: – sem num . . . ˇc´ıslo semaforu – sem op . . . operace ∗ P(sem num, abs(sem op)) pro sem op < 0 ∗ V(sem num, sem op) pro sem op > 0 ∗ ˇcek´ an´ı na nulovou hodnotu semaforu pro sem op == 0 – sem flg . . . OR-kombinace ∗ IPC NOWAIT . . . kdyˇz nelze operaci hned provést, neˇcek´ aa vr´ at´ı chybu atit operace se ∗ SEM UNDO . . . pˇri ukonˇcen´ı procesu vr´ semaforem

• atomiˇcnost zajist´ı, ˇze nedojde k deadlocku v n´ asleduj´ıc´ı situaci: dva procesy A a B budou pouˇz´ıvat dva semafory k ˇr´ızen´ı pˇr´ıstupu (zamyk´ an´ı) ke dvˇema systémov´ ym zdroj˚ um. Proces A je bude zamykat v poˇrad´ı (0, 1) a proces B v poˇrad´ı (1, 0). Ve chv´ıli, kdy proces A zamkne semafor 0 a B zamkne 1, dojde k deadlocku, protoˇze ani jeden proces nem˚ uˇze pokraˇcovat (potˇreboval by zamknout druh´ y semafor). Pˇri pouˇzit´ı atomické operace zamˇcen´ı obou semafor˚ u najednou bude u ´ spˇeˇsn´ y vˇzdy právˇe jeden proces, kter´ y z´ıská oba semafory, druh´ y bude ˇcekat. u (pou• SEM UNDO zajist´ı, ˇze pˇri ukonˇcen´ı procesu dojde k odemˇcen´ı semafor˚ ˇzit´ ych jako z´ amky), které tento proces mˇel zamˇcené.

152

Vytv´ aˇ ren´ı prostˇ redk˚ u IPC • jeden proces prostˇredek vytvoˇr´ı, ostatn´ı se k nˇemu pˇripoj´ı. • po skonˇcen´ı pouˇz´ıv´ an´ı je tˇreba prostˇredek IPC zruˇsit. • funkce semget(), shmget() a msgget() maj´ı jako prvn´ı parametr kl´ıˇc identifikuj´ıc´ı prostˇredek IPC. Skupina proces˚ u, kter´ a chce komunikovat, se mus´ı domluvit na spoleˇcném kl´ıˇci. R˚ uzné skupiny komunikuj´ıc´ıch proces˚ u by mˇely m´ıt r˚ uzné kl´ıˇce. key t ftok(const char *path, int id ); • vr´ at´ı kl´ıˇc odvozen´ y ze zadaného jména souboru path a ˇc´ısla id. Pro stejné id a libovolnou cestu odkazuj´ıc´ı na stejn´ y soubor vr´ at´ı stejn´ y kl´ıˇc. Pro r˚ uzná id nebo r˚ uzné soubory na stejném svazku vr´ at´ı r˚ uzné kl´ıˇce.

Pozn´ amky k ftok(): • Z id se pouˇzije jen nejniˇzˇs´ıch 8 bit˚ u. • Nen´ı specifikováno, zda bude stejn´ y kl´ıˇc vr´ acen i po smaz´ an´ı a znovuvytvoˇren´ı souboru. • R˚ uzné kl´ıˇce pro r˚ uzné soubory nejsou vˇzdy zaruˇcené. Napˇr. na Linuxu se kl´ıˇc z´ısk´ a kombinac´ı 16 bit˚ u ˇc´ısla i-uzlu, 8 bit˚ u id a 8 bit˚ u vedlejˇs´ıho ˇc´ısla zaˇr´ızen´ı. Stejn´ y kl´ıˇc pro r˚ uzné soubory je vr´ acen, pokud se ˇc´ısla i-uzl˚ u shoduj´ı na spodn´ıch 16 bitech.

153

Dalˇ s´ı prostˇ redky IPC • POSIX a UNIX98 definuj´ı jeˇstˇe dalˇs´ı prostˇredky komunikace mezi procesy: – sign´ aly . . . pro uˇzivatelské u ´ˇcely lze vyuˇz´ıt signály SIGUSR1 a SIGUSR2 – POSIXov´ a sd´ılen´ a pamˇ et’ pˇr´ıstupn´ a pomoc´ı shm open() a mmap() – POSIXov´ e semafory . . . sem open(), sem post(), sem wait(), . . . – POSIXov´ e fronty zpr´ av . . . mq open(), mq send(), mq receive(), . . . • Z BSD poch´ az´ı sokety (sockets) umoˇzn ˇ uj´ıc´ı komunikaci v domén´ ach AF UNIX (komunikace v r´ amci jednoho poˇc´ıtaˇce) a AF INET (komunikace na jednom poˇc´ıtaˇci nebo po s´ıti).

• POSIXové IPC pouˇz´ıv´ a pro pojmenován´ı jednotliv´ ych IPC objekt˚ u ˇretˇezce m´ısto numerick´ ych identifik´ ator˚ u, proto do znaˇcné m´ıry odpadaj´ı problémy s identifikac´ı zn´ amé ze System V IPC (kde se ˇreˇs´ı napˇr. funkc´ı ftok()). • sokety se z BSD rozˇs´ıˇrily i do ostatn´ıch UNIXov´ ych systém˚ u a dostaly se i do normy UNIX 98.

154

Obsah • u ´ vod, v´ yvoj UNIXu a C, program´ atorské n´ astroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupová práva, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • signály • synchronizace a komunikace proces˚ u • s´ıt’ov´ a komunikace • vl´ akna, synchronizace vl´ aken • ??? - bude definováno pozdˇeji, podle toho kolik zbyde ˇcasu

S´ıt’ov´ a komunikace UUCP (UNIX-to-UNIX Copy Program) – prvn´ı aplikace pro komunikaci UNIXov´ ych systém˚ u propojen´ ych pˇr´ımo nebo pˇres modemy, souˇca´st Version 7 UNIX (1978) sokety (sockets) – zavedeny ve 4.1aBSD (1982); soket je jeden konec obousmˇerného komunikaˇcn´ıho kan´ alu vytvoˇreného mezi dvˇema procesy bud’ lokálnˇe na jednom poˇc´ıtaˇci, nebo s vyuˇzit´ım s´ıt’ového spojen´ı TLI (Transport Layer Interface) – SVR3 (1987); knihovna zajiˇst’uj´ıc´ı s´ıt’ovou komunikaci na u ´ rovni 4. vrstvy referenˇcn´ıho modelu ISO OSI RPC (Remote Procedure Call) – SunOS (1984); protokol pro pˇr´ıstup ke sluˇzb´ am na vzd´ aleném stroji, data pˇren´ aˇsena ve tvaru XDR (External Data Representation)

155

• ISO (International Standards Organization) OSI (Open Systems Interconnect) – vrstvy (layers): 1. 2. 3. 4. 5. 6. 7.

fyzická (physical) linková (data link) s´ıt’ová (network) transportn´ı (transport) relaˇcn´ı (session) prezentaˇcn´ı (presentation) aplikaˇcn´ı (application)

• UUCP je tvoˇreno aplikaˇcn´ımi programy, nevyˇzaduje ˇza´dnou podporu v jádru. Implementace soket˚ u a TLI jsou souˇca´st´ı jádra. TLI je ve verzi SVR4 implementováno s vyuˇzit´ım mechanismu STREAMS. RPC existuje jako knihovna linkovan´ a k aplikac´ım, kter´ a vyuˇz´ıv´ a sokety (funguje nad protokoly TCP a UDP). RPC bylo vyvinuto jako komunikaˇcn´ı protokol pro NFS (Networked File System). • existuje v´ıce (vz´ ajemnˇe nekompatibiln´ıch) implementac´ı RPC • komunikaˇcn´ı kan´ al je specifikován adresami dvou soket˚ u. • sokety pro komunikaci pouze v r´ amci jednoho poˇc´ıtaˇce jsou v doménˇe AF UNIX a jejich jména jsou jména speci´ aln´ıch soubor˚ u, které reprezentuj´ı sokety v systému soubor˚ u. • sokety AF UNIX jsou nˇeco jiného neˇz lokáln´ı TCP/IP komunikace pˇres loopback rozhran´ı localhost (127.0.0.1).

TCP/IP • protokoly – IP (Internet Protocol) – pˇr´ıstupn´ y jen pro uˇzivatele root – TCP (Transmission Control Protocol) – streamov´ y, spojovan´ y, spolehliv´ y – UDP (User Datagram Protocol) – datagramov´ y, nespojovan´ y, nespolehliv´ y • IP adresa – 4 bajty, definuje s´ıt’ové rozhran´ı, nikoliv poˇc´ıtaˇc • port – 2 bajty, rozliˇsen´ı v r´ amci 1 IP adresy, porty s ˇc´ıslem menˇs´ım neˇz 1024 jsou rezervované (jejich pouˇzit´ı vyˇzaduje práva uˇzivatele root) • DNS (Domain Name System) – pˇrevod mezi symbolick´ ymi jmény a numerick´ ymi IP adresami

156

• UNIX pouˇz´ıv´ a pro s´ıt’ovou komunikaci nejˇcastˇeji rodinu protokol˚ u TCP/IP. Pro u ´ˇcely programován´ı aplikac´ı n´ as budou zaj´ımat pˇredevˇs´ım protokoly TCP (spojovan´ a spolehliv´ a komunikace) a UDP (nespojovan´ a nespolehliv´ a komunikace). V obou protokolech je jeden konec komunikaˇcn´ıho kan´ alu (odpov´ıdá soketu v doménˇe AF INET) identifikován IP adresou s´ıt’ového rozhran´ı a ˇc´ıslem portu (pomoc´ı port˚ u se rozliˇsuj´ı s´ıt’ové sluˇzby bˇeˇz´ıc´ı na jednom poˇc´ıtaˇci). • IP – protokol 3. vrstvy, zajiˇst’uje pˇrenos paket˚ u (datagram˚ u) mezi rozhran´ımi identifikovan´ ymi IP adresou; je nespolehliv´ y (nezaruˇcuje doruˇcen´ı dat). RFC 791. Ned´ılnou souˇca´st´ı IP je Internet Control Message Protocol (ICMP), RFC 792. • UDP – jednoduch´ a nadstavba nad IP, pˇrid´ av´ a ˇc´ısla port˚ u, z˚ ust´ av´ a nespolehliv´ y a datagramovˇe orientovan´ y • TCP – vytváˇr´ı obousmˇerné spojen´ı mezi dvˇema body (IP+port), poskytuje tok dat (stream) bez rozdˇelen´ı na zpr´ avy, zajiˇst’uje ˇr´ızen´ı toku dat a spolehlivé doruˇcován´ı • DNS – hierarchicky organizovan´ a datab´ aze, jej´ı struktura nemus´ı m´ıt nic spoleˇcného se strukturou IP adres

Spojovan´ e sluˇ zby (TCP), sekvenˇ cn´ı obsluha server

s´ıt’

klient

fd = socket()

fd = socket() bind(fd) listen(fd) fd2 = accept(fd)

connect(fd)

read(fd2); write(fd2)

write(fd);read(fd)

close(fd2)

close(fd)

• server vytvoˇr´ı jedno spojen´ı, teprve po jeho ukonˇcen´ı akceptuje dalˇs´ıho klienta. • systémová vol´ an´ı: – socket() – vytvoˇr´ı soket, vr´ at´ı jeho desktiptor

157

– bind() – definuje adresu soketu (IP adresu a ˇc´ıslo portu), mus´ı to b´ yt bud’ adresa jednoho ze s´ıt’ov´ ych rozhran´ı poˇc´ıtaˇce, na kterém je vytvoˇren soket (pak bude soket pˇrij´ımat ˇza´dosti klient˚ u pouze pˇres toto rozhran´ı), nebo je to speci´ aln´ı hodnota ,,libovoln´ a adresa” (pak soket pˇrij´ım´ a poˇzadavky prostˇrednictv´ım vˇsech s´ıt’ov´ ych rozhran´ı) – listen() – ozn´ am´ı j´ adru, ˇze soket bude pˇrij´ımat poˇzadavky klient˚ u – accept() – usp´ı proces, dokud nebude k dispozici nˇejak´ a ˇza´dost klienta o spojen´ı, vytvoˇr´ı spojen´ı a vr´ at´ı nov´ y deskriptor, pˇres kter´ y bude prob´ıhat dalˇs´ı komunikace s klientem, p˚ uvodn´ı deskriptor lze pouˇz´ıt k novému vol´ an´ı accept() pro obslouˇzen´ı dalˇs´ıho klienta – close() – ukonˇc´ı komunikaci – connect() – ˇza´dost klienta o navázán´ı spojen´ı, IP adresa a ˇc´ıslo portu serveru se zad´ avaj´ı jako parametry, komunikace prob´ıh´ a pˇres deskriptor fd (na rozd´ıl od accept() nevytv´ aˇr´ı nov´ y deskriptor) • klient nemus´ı volat bind(), v takovém pˇr´ıpadˇe mu jádro pˇridˇel´ı nˇekter´ y voln´ y port. Existuj´ı sluˇzby (napˇr. rsh), které vyˇzaduj´ı, aby se klient spojoval z privilegovaného portu. Takov´ y klient pak mus´ı provést bind() (a nav´ıc bˇeˇzet s rootovsk´ ymi právy alespoˇ n do okamˇziku proveden´ı bind()).

Spojovan´ e sluˇ zby (TCP), paraleln´ı obsluha server

s´ıt’

klient

fd = socket()

fd = socket() bind(fd) listen(fd) fd2 = accept(fd) fork()

connect(fd)

syn close(fd2) while(waitpid( read(fd2) -1, stat, write(fd2) WNOHANG)>0) ; exit(0)

write(fd);read(fd) close(fd)

• server akceptuje spojen´ı od klienta a na vlastn´ı komunikaci vytvoˇr´ı nov´ y proces, kter´ y po uzavˇren´ı spojen´ı s klientem skonˇc´ı. Rodiˇcovsk´ y proces m˚ uˇze mezit´ım akceptovat dalˇs´ı klienty a spouˇstˇet pro nˇe obsluˇzné procesy. Souˇcasnˇe je tedy obsluhováno v´ıce klient˚ u. • po proveden´ı fork(), ale pˇred zahájen´ım obsluhy spojen´ı, m˚ uˇze synovsk´ y proces provést exec – takto funguje napˇr. inetd. 158

• vol´ an´ı waitpid() v cyklu odstraˇ nuje ze systému zombie. Jinou moˇznost´ı je vyuˇzit´ı signálu SIGCHLD, jehoˇz explicitn´ı ignorován´ı zabr´ an´ı vzniku ˇziv´ ych mrtv´ ych, popˇr. lze instalovat handler, v nˇemˇz se volá wait().

Spojovan´ e sluˇ zby, paraleln´ı accept() server

s´ıt’

fd = socket() bind(fd) listen(fd) fork()

...

klient

fd = socket()

fd2=accept(fd) read(fd2) write(fd2) close(fd2)

connect(fd) write(fd);read(fd) close(fd)

• po bind() a listen() se vytvoˇr´ı nˇekolik synovsk´ ych proces˚ u a kaˇzd´ y v cyklu vol´ a accept() a obsluhuje klienty. J´ adro vybere (nedeterministicky) pro kaˇzd´ y poˇzadavek jeden proces, v nˇemˇz accept() naváˇze spojen´ı. • jednotlivé procesy serveru mezi sebou mohou komunikovat, aby v pˇr´ıpadˇe, ˇze souˇcasn´ ych poˇzadavk˚ u je v´ıce neˇz serverov´ ych proces˚ u, se tato skuteˇcnost zjistila a hlavn´ı server mohl dynamicky vytvoˇrit dalˇs´ı serverov´ y proces. • takto funguje napˇr. webov´ y server Apache. • vˇsechny tˇri uvedené zp˚ usoby ˇcinnosti serveru funguj´ı se stejn´ ym klientem – ˇcinnost klienta nez´ avis´ı na variantˇe serveru.

159

Datagramov´ e sluˇ zby (UDP) server

s´ıt’

klient

fd = socket()

fd = socket()

bind(fd) recvfrom(fd) sendto(fd)

sendto(fd) recvfrom(fd) close(fd)

• z pohledu volan´ ych s´ıt’ov´ ych funkc´ı je funkce serveru a klienta shodn´ a. Klient je zde ten, kdo poˇsle prvn´ı datagram. • stejnˇe jako v pˇr´ıpadˇe TCP, klient nemus´ı dˇelat bind(), jestliˇze mu nezáleˇz´ı na tom, jaké ˇc´ıslo portu bude pouˇz´ıvat. Server zjist´ı jeho port z obsahu adresn´ı ˇca´sti prvn´ıho datagramu. • v´ yhodou nespojované sluˇzby je menˇs´ı reˇzie a to, ˇze pˇres jeden soket lze komunikovat s v´ıce procesy (pˇri spojované komunikaci je spojen´ı vˇzdy navázáno s jedn´ım procesem). • pro UDP je moˇzné volat connect(). T´ım se nenaváˇze spojen´ı, ale soket se nastav´ı tak, ˇze m˚ uˇze nadále komunikovat pouze s adresou a portem specifikovan´ ymi ve vol´ an´ı connect(). M´ısto sendto() a recvfrom() se pak pouˇz´ıvaj´ı funkce send() a recv().

160

Vytvoˇ ren´ı soketu: socket() int socket(int domain, int type, int protocol ); • vytvoˇr´ı soket a vr´ at´ı jeho deskriptor. • domain: – AF UNIX . . . lokáln´ı komunikace, adresa je jméno souboru – AF INET . . . s´ıt’ová komunikace, adresa je dvojice (IP adresa, port) • type: – SOCK STREAM . . . spojovan´ a spolehliv´ a sluˇzba, poskytuje obousmˇern´ y sekvenˇcn´ı proud dat – SOCK DGRAM . . . nespojovan´ a nespolehliv´ a sluˇzba, pˇrenos datagram˚ u • protocol: 0 (default pro dan´ y type) nebo platné ˇc´ıslo protokolu (napˇr. 6 = TCP, 17 = UDP)

• sokety jsou pˇr´ıstupné pˇres deskriptory soubor˚ u. Po navázán´ı spojen´ı je (spojovan´ a) komunikace pˇres soket podobná komunikaci pomoc´ı roury. • v nˇekter´ ych implementac´ıch se rozliˇsuj´ı konstanty zaˇc´ınaj´ıc´ı PF_ (protocol family, napˇr. PF_INET, PF_UNIX) pouˇz´ıvané v socket() a konstanty AF_ (address family, napˇr. AF_INET, AF_UNIX) pouˇz´ıvané pˇri zadáv´ an´ı adres soket˚ u. Hodnoty odpov´ıdaj´ıc´ıch konstant AF_ a PF_ jsou typicky stejné. • existuj´ı dalˇs´ı typy soket˚ u pro pˇr´ıstup k IP, ICMP, nebo k informac´ım z routovac´ı tabulky.

161

Pojmenov´ an´ı soketu: bind() int bind(int socket, const struct sockaddr *address, socklen t address len ); • pˇriˇrad´ı soketu zadanému deskriptorem socket adresu address o velikosti address len bajt˚ u. • struct sockaddr: – sa family t sa family . . . doména – char sa data [] . . . adresa • Pro AF INET se pouˇz´ıv´ a struct sockaddr in: – sa family t sin family . . . doména (AF INET) – in port t sin port . . . ˇc´ıslo portu (16 bit˚ u) u) – struct in addr sin addr . . . IP adresa (32 bit˚ – unsigned char sin zero [8] . . . v´ yplˇ n

• vol´ an´ı bind() pˇriˇrazuje soketu lok´ aln´ı adresu, tj. zdrojovou adresu odes´ılan´ ych dat a c´ılovou adresu pˇrij´ıman´ ych dat. Vzdálen´ a adresa (adresa druhého konce komunikaˇcn´ıho kan´ alu) se nastavuje pomoc´ı connect(). • jeden soket lze spojit se vˇsemi lokáln´ımi adresami nastaven´ım sin_addr na INADDR_ANY. • nelze spojit v´ıce soket˚ u s jednou dvojic´ı (adresa, port). • vol´ an´ı bind() lze vynechat, j´ adro pak soketu (v pˇr´ıpadˇe TCP, UDP) pˇriˇrad´ı adresu INADDR_ANY a nˇekter´ y voln´ y port. Obvykle bind() volá pouze server, protoˇze klienti oˇcek´ avaj´ı, ˇze bude poslouchat na pevném portu. Naopak klient pevn´ y port nepotˇrebuje, server se port klienta dozv´ı pˇri navázán´ı spojen´ı nebo z prvn´ıho pˇrijatého datagramu. • adresa i port mus´ı b´ yt do struktury uloˇ zeny v s´ıt’ov´ em poˇ rad´ı bajt˚ u. Poˇrad´ı bajt˚ u bylo vysvˇetleno na stranˇe 15, dalˇs´ı informace pak budou na stranˇe 171. • v doménˇe AF_UNIX se pouˇz´ıv´ a adresová struktura struct sockaddr_un: – sa family t sun family . . . doména – char sun path [] . . . jméno soketu – délka jména nen´ı ve standardu definována, z´ avis´ı na implementaci. Obvyklé hodnoty jsou mezi 92 a 108.

162

ˇ an´ı na spojen´ı: listen() Cek´ int listen(int socket, int backlog ); • oznaˇc´ı soket zadan´ y desktriptorem socket jako akceptuj´ıc´ı spojen´ı. • maxim´ alnˇe backlog ˇza´dost´ı o spojen´ı m˚ uˇze najednou ˇcekat ve frontˇe na obslouˇzen´ı (implementace m˚ uˇze hodnotu backlog ˇ adosti, které se zmˇenit, pokud nen´ı v podporovaném rozsahu). Z´ nevejdou do fronty, jsou odm´ıtnuty (tj. volán´ı connect() skonˇc´ı s chybou). • soket ˇcek´ a na spojen´ı na adrese, kter´ a mu byla dˇr´ıve pˇriˇrazena vol´ an´ım bind(). Pro doménu AF INET staˇc´ı zadat ˇc´ıslo portu a IP adresu INADDR ANY, kter´ a znamen´ a libovolnou adresu.

• hodnota INADDR ANY se pouˇz´ıv´ a nejˇcastˇeji. Konkrétn´ı IP adresa serveru se zad´ av´ a tehdy, jestliˇze je potˇreba rozliˇsit, pˇres které s´ıt’ové rozhran´ı pˇriˇsel poˇzadavek na spojen´ı (pro kaˇzdé rozhran´ı máme jeden soket). Tuto moˇznost vyuˇz´ıvaj´ı web servery, které podle IP adresy rozliˇsuj´ı virtu´ aln´ı servery . Obvykle se na takovém serveru jednomu fyzickému rozhran´ı pˇriˇrazuje nˇekolik IP adres (IP aliasing). Novˇejˇs´ı rozliˇsen´ı virtu´ aln´ıch server˚ u podle HTTP hlaviˇcky ,,Host:” uˇz nepotˇrebuje IP aliasy.

163

Akceptov´ an´ı spojen´ı: accept() int accept(int socket, struct sockaddr *address, socklen t *address len ); • vytvoˇr´ı spojen´ı mezi lokáln´ım soketem socket (kter´ y dˇr´ıve zavolal listen()) a vzd´ alen´ ym soketem, kter´ y ˇza´dal o spojen´ı pomoc´ı connect(). Vr´ at´ı deskriptor (nov´ y soket), kter´ y lze pouˇz´ıvat pro komunikaci se vzd´ alen´ ym procesem. P˚ uvodn´ı deskriptor socket umoˇzn ˇ uje pˇrij´ımat dalˇs´ı spojen´ı pomoc´ı accept(). • v address vr´ at´ı adresu vzd´ aleného soketu. avratu • address len je velikost struktury pro uloˇzen´ı adresy, po n´ obsahuje skuteˇcnou délku adresy. • podobnˇe jako bind() i accept() pouˇz´ıv´ a pro adresy v doménˇe AF INET strukturu sockaddr in.

• vytvoˇren´ı druhého deskriptoru pro komunikaci umoˇzn ˇ uje na tom p˚ uvodn´ım ihned znovu volat accept(). • jestliˇze se v´ıce klient˚ u ze stejného poˇc´ıtaˇce najednou pˇripoj´ı k jednomu serveru (tj. na jednu serverovou IP adresu a jeden port), jsou jednotliv´ a spojen´ı rozliˇsena jen ˇc´ıslem portu na klientské stranˇe. • address m˚ uˇze b´ yt zad´ ana jako NULL, ˇc´ımˇz oznamujeme, ˇze n´ as konkrétn´ı adresa naˇseho nového soketu nezaj´ım´ a. V tomto pˇr´ıpadˇe by i address len mˇelo b´ yt 0. • socket vr´ acen´ y z vol´ an´ı accept() si m˚ uˇzeme pˇredstavit tak, ˇze reprezentuje ten konec spojen´ı, na kterém poslouch´ a a z kterého ˇcte druh´ a strana.

164

Nav´ az´ an´ı spojen´ı: connect() int connect(int sock, struct sockaddr *address, socklen t address len); • naváˇze spojen´ı lokáln´ıho soketu sock se vzd´ alen´ ym procesem, kter´ y pomoc´ı listen() a accept() ˇcek´ a na spojen´ı na adrese address (o délce address len). • jestliˇze pro soket sock nebyla definována adresa volán´ım bind(), je mu pˇriˇrazena nˇejak´ a nepouˇzit´ a adresa dle zvolené rodiny protokol˚ u. • pokud se spojen´ı nepovede, je soket v nedefinovaném stavu. Pˇred nov´ ym pokusem o spojen´ı by aplikace mˇela zavˇr´ıt deskriptor sock a vytvoˇrit nov´ y soket.

• po u ´ spˇeˇsném navázán´ı spojen´ı mohou server i klient pro komunikaci pouˇz´ıvat bˇeˇzn´ a souborová vol´ an´ı write() a read(), nebo funkce send(), recv(), sendmsg(), recvmsg(). Chován´ı funkc´ı pro z´ apis a ˇcten´ı dat je podobné jako write() a read() pro roury. • i pro nespojované sluˇzby (UDP) se d´ a volat connect(), t´ım se nenaváˇze spojen´ı, ale pouze se omez´ı adresa protistrany, se kterou m˚ uˇze soket komunikovat. V tomto pˇr´ıpadˇe mohou connect() volat obˇe strany komunikace. • pokud je socket nastaven jako neblokuj´ıc´ı, viz strana 170, connect() se nezablokuje ˇcek´ an´ım na spojen´ı. M´ısto toho vr´ at´ı -1 s errno nastavené na EINPROGRESS (= “nelze vytvoˇrit spojen´ı okamˇzitˇe”), a ˇza´dost o spojen´ı se uloˇz´ı do systémové fronty pro n´ asledné vyˇr´ızen´ı. Do té doby, neˇz je spojen´ı pˇripraveno, vol´ an´ı connect() vrac´ı -1, nyn´ı ale s chybou EALREADY. Nen´ı ale takto vhodné testovat pˇripravenost spojen´ı, protoˇze pokud connect() skonˇc´ı s chybou, dalˇs´ı vol´ an´ı connect() provede nov´ y pokus o spojen´ı a jsme opˇet tam, kde jsme byli. . . Je moˇzné ale pouˇz´ıt select() nebo poll() pro ˇcek´ an´ı na z´ apis (ne ˇcten´ı) do socketu, viz strany 176, 178. Zda spojen´ı probˇehlo u ´ spˇeˇsnˇe se pak dozv´ıte z funkce getsockopt() s opt name nastavené na SO ERROR, viz strana 170.

165

Posl´ an´ı zpr´ avy: sendto() ssize t sendto(int socket, void *msg, size t len, int flags, struct sockaddr *addr, socklen t addr len ); • prostˇrednictv´ım soketu socket poˇsle zpr´ avu msg o délce len na adresu addr (o délce addr len). • parametr flags m˚ uˇze obsahovat pˇr´ıznaky: – MSG EOB . . . ukonˇcen´ı z´ aznamu (pokud je podporováno protokolem) an´ı urgentn´ıch (out-of-band) dat, jejichˇz – MSG OOB . . . posl´ v´ yznam je z´ avisl´ y na protokolu

• pouˇz´ıv´ a se hlavnˇe pro sokety typu SOCK DGRAM, protoˇze v této situaci máme pouze socket reprezentuj´ıc´ı naˇsi stranu spojen´ı; viz poznámka u slajdu k accept(). Mus´ıme proto specifikovat adresu protistrany. Pro datagramovou sluˇzbu se nav´ıc data berou jako nedˇeliteln´ a, tj. bud’ se akceptuj´ı cel´ a, nebo se vol´ an´ı zablokuje – neexistuje ˇca´steˇcn´ y z´ apis. Stejnˇe jako je tomu u souborov´ ych deskriptor˚ u, je i zde moˇzné socket nastavit jako neblokuj´ıc´ı, viz strana 170. • m´ısto sendto() se d´ a pouˇz´ıt obecnˇejˇs´ı funkce sendmsg(). • pro sokety, na které bylo vol´ ano connect(), se m´ısto sendto() m˚ uˇze pouˇz´ıt send(). • u ´ spˇeˇsn´ y n´ avrat z libovolné funkce zapisuj´ıc´ı data do soketu neznamen´ a u ´ spˇ eˇ sn´ e doruˇ cen´ı zpr´ avy protistranˇ e, ale pouze uloˇzen´ı dat do lokáln´ıho bufferu odes´ılan´ ych dat. • pokud pouˇzijete sendto() na streamovanou sluˇzbu, je to moˇzné, ale adresa se ignoruje. Jedin´ y d˚ uvod proˇc nepouˇz´ıt pˇr´ımo write() by tak byla moˇznost pouˇz´ıt flagy. V tom pˇr´ıpadˇe je ale jednoduˇsˇs´ı pouˇz´ıt send().

166

Pˇ rijet´ı zpr´ avy: recvfrom() ssize t recvfrom(int sock, void *buf, size t len, int flg, struct sockaddr *address, socklen t *address len ); • pˇrijme zpr´ avu ze soketu sock, uloˇz´ı ji do bufferu buf o velikosti len, do address d´ a adresu odes´ılatele zpr´ avy, do address len délku adresy. Vr´ at´ı délku zpr´ avy. Kdyˇz je zpr´ ava delˇs´ı neˇz len, nadbyteˇcn´ a data se zahod´ı (SOCK STREAM nedˇel´ı data na zpr´ avy, data se nezahazuj´ı). • ve flg mohou b´ yt pˇr´ıznaky: ava se bere jako nepˇreˇcten´ a, dalˇs´ı – MSG PEEK . . . zpr´ recvfrom() ji vr´ at´ı znovu – MSG OOB . . . pˇreˇcte urgentn´ı (out-of-band) data a, dokud nen´ı naˇcten pln´ y objem dat, tj. – MSG WAITALL . . . ˇcek´ len bajt˚ u

• pouˇz´ıv´ a se hlavnˇe pro sokety typu SOCK DGRAM. V takové situaci opˇet ˇcek´ a na celou zpr´ avu (tj. nevr´ at´ı vám p˚ ulku datagramu); opˇet je moˇzné nastavit socket jako neblokuj´ıc´ı. • m´ısto recvfrom() se d´ a pouˇz´ıt obecnˇejˇs´ı funkce recvmsg(). • pro sokety, na které bylo vol´ ano connect(), se m´ısto funkce recvfrom() volá recv(). yt inicializovan´ a velikost´ı bufferu. • address len mus´ı b´ • po u ´ speˇsném n´ avratu z recvfrom() je moˇzné address a address len beze zmˇeny pouˇz´ıt pro n´ asledné volán´ı sendto(). • stejnˇe jako sendto(), je i recvfrom() moˇzné pouˇz´ıt pro spojovanou sluˇzbu. Z´ıskat adresu protistrany je ale asi jednoduˇsˇs´ı pˇres volán´ı getsockbyname(), viz strana 170.

167

Uzavˇ ren´ı soketu: close() int close(int fildes); • zruˇs´ı deskriptor, pˇri zruˇsen´ı posledn´ıho deskriptoru soketu zavˇre soket. • pro SOCK STREAM soket z´ aleˇz´ı na nastaven´ı pˇr´ıznaku SO LINGER (default je l onoff == 0, mˇen´ı se funkc´ı setsockopt()). – l onoff == 0 . . . vol´ an´ı close() se vr´ at´ı, ale jádro se snaˇz´ı d´ al pˇrenést zbyl´ a data – l onoff == 1 && l linger != 0 . . . jádro se snaˇz´ı pˇrenést zbyl´ a data do vyprˇsen´ı timeoutu l linger, kdyˇz se to nepovede, close() vr´ at´ı chybu, jinak vr´ at´ı OK po pˇrenesen´ı dat. – l onoff == 1 && l linger == 0 . . . provede se reset spojen´ı

• po uzavˇren´ı m˚ uˇze TCP soket z˚ ustat po nˇejakou dobu v pˇrechodném stavu (kter´ y je definován protokolem TCP pˇri ukonˇcován´ı spojen´ı). Neˇz je soket zcela zruˇsen, nelze pouˇz´ıt jin´ y soket na stejném portu (pokud toto nebylo povoleno nastaven´ım pˇr´ıznaku SO REUSEADDR pomoc´ı funkce setsockopt(), viz strana 170). • pˇri pouˇzit´ı SO_REUSEADDR se d´ a po uzavˇren´ı poslouchaj´ıc´ıho serverového soketu znovu spustit server – volat socket(), bind(), listen() a accept() na stejné adrese a portu – i kdyˇz jeˇstˇe dob´ıhaj´ı spojen´ı vytvoˇren´ a pˇredchoz´ı instanc´ı serveru: int opt = 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); • reset spojen´ı je abnorm´ aln´ı ukonˇcen´ı spojen´ı. V TCP se pouˇzije paket s nastaven´ ym pˇr´ıznakem RST. Na druhé stranˇe se normáln´ı ukonˇcen´ı spojen´ı projev´ı jako konec souboru (pˇri ˇcten´ı), reset zp˚ usob´ı chybu ECONNRESET.

168

Uzavˇ ren´ı soketu: shutdown() int shutdown(int socket, int how ); • Uzavˇre soket (ale neruˇs´ı deskriptor) podle hodnoty how: – SHUT RD . . . pro ˇcten´ı – SHUT WR . . . pro z´ apis – SHUT RDWR . . . pro ˇcten´ı i z´ apis

• Pˇri norm´ aln´ım ukonˇcen´ı spojen´ı na u ´ rovni protokolu TCP kaˇzd´ a strana signalizuje, ˇze uˇz nebude nic zapisovat. To plat´ı i v pˇr´ıpadˇe pouˇzit´ı close() nebo shutdown(fd, SHUT RDWR). Pˇri pouˇzit´ı shutdown(fd, SHUT WR) lze ze soketu d´ al ˇc´ıst. Druh´ a strana dostane EOF pˇri ˇcten´ı, ale m˚ uˇze d´ al zapisovat.

169

Dalˇ s´ı funkce pro sokety int setsockopt(int socket, int level, int opt name, const void *opt value, socklen t option len ); • nastaven´ı parametr˚ u soketu int getsockopt(int socket, int level, int opt name, void *opt value, socklen t *option len ); • pˇreˇcten´ı parametr˚ u soketu int getsockname(int socket, struct sockaddr *address, socklen t *address len ); • zjiˇstˇen´ı (lok´ aln´ı) adresy soketu int getpeername(int socket, struct sockaddr *address, socklen t *address len ); • zjiˇstˇen´ı adresy vzd´ aleného soketu (druhého konce spojen´ı)

• hodnota level v getsockopt() a setsockopt() je obvykle SOL_SOCKET. U getsockopt(), option len mus´ı b´ yt inicializována na velikost opt value. • funkce getsockname() se pouˇz´ıv´ a, kdyˇz nevoláme bind() a potˇrebujeme zjistit, jak´ a (lok´ aln´ı!) adresa byla jádrem soketu pˇridˇelena. • vol´ an´ı getsockopt(sock, SOL_SOCKET, SO_ERROR, &val, &len) vr´ at´ı (a vymaˇze) pˇr´ıznak chyby na soketu. Asi nejuˇziteˇcnˇejˇs´ı je pˇri zjiˇst’ován´ı, jak dopadl neblokuj´ıc´ı connect(), viz strana 165. • pˇr´ıklad na setsockopt() je na stranˇe 168.

170

Poˇ rad´ı bajt˚ u • S´ıt’ové sluˇzby pouˇz´ıvaj´ı poˇrad´ı bajt˚ u, které se m˚ uˇze liˇsit od poˇrad´ı pouˇz´ıvaného na lokáln´ım systému. Pro pˇrevod lze pouˇz´ıt funkce (makra): – uint32 t htonl(uint32 t hostlong ); host → s´ıt’, 32 bit˚ u – uint16 t htons(uint16 t hostshort ); host → s´ıt’, 16 bit˚ u – uint32 t ntohl(uint32 t netlong ); s´ıt’ → host, 32 bit˚ u – uint16 t ntohs(uint16 t netshort ); s´ıt’ → host, 16 bit˚ u • S´ıt’ové poˇrad´ı bajt˚ u je big-endian, tj. nejprve vyˇsˇs´ı bajt. Pouˇz´ıv´ a se hlavnˇe ve funkc´ıch pracuj´ıc´ıch s adresami a ˇc´ısly port˚ u.

• Pokud lokáln´ı systém pouˇz´ıv´ a stejné poˇrad´ı bajt˚ u jako s´ıt’, nedˇelaj´ı pˇrevodn´ı funkce nic.

171

ˇ ısla protokol˚ C´ u a port˚ u struct protoent *getprotobyname(const char *name ); at´ı ˇc´ıslo protokolu se jménem name (napˇr. • v poloˇzce p proto vr´ pro "tcp" vr´ at´ı 6). • ˇc´ısla protokol˚ u jsou uloˇzena v souboru /etc/protocols. struct servent *getservbyname(const char *name, const char *proto ); • pro zadané jméno sluˇzby name a jméno protokolu proto vr´ at´ı v poloˇzce s port ˇc´ıslo portu. • ˇc´ısla port˚ u jsou uloˇzena v souboru /etc/services. funkce vrac´ı NULL, kdyˇz v datab´ azi nen´ı odpov´ıdaj´ıc´ı poloˇzka.

• v uveden´ ych souborech je definováno mapován´ı mezi jmény a ˇc´ısly pro standardn´ı protokoly a sluˇzby. • pozor na to, ˇze protokolem zde nemysl´ıme www, SSH, telnet nebo FTP – to jsou zde sluˇzby, reprezentované ˇc´ısly port˚ u. Protokol je TCP, UDP, OSPF, GRE apod., tedy to, co je pˇren´ aˇseno v IP paketu v poloˇzce Protocol, viz RFC 791.

172

Jm´ ena a IP adresy struct hostent *gethostbyname(const char *name ); • pro dané jméno vr´ at´ı v poli char **h addr list seznam pˇr´ısluˇsn´ ych s´ıt’ov´ ych adres. Za posledn´ı adresou je ukazatel NULL. Délka jedné adresy je v poloˇzce h length. struct hostent *gethostbyaddr(const char *addr, size t len, int type ); • pro danou adresu addr o délce len v doménˇe type vr´ at´ı jméno v poloˇzce h name a pˇr´ıpadné aliasy v nulou ukonˇceném poli h aliases. − pˇri vyhodnocován´ı dotaz˚ u na adresy a jména se pouˇz´ıv´ a DNS a lokáln´ı datab´ aze uloˇzen´ a v souboru /etc/hosts. − vrac´ı NULL, kdyˇz v datab´ azi nen´ı hledan´ y z´ aznam.

• lze stanovit, zda má prioritu DNS nebo lokáln´ı datab´ aze adres. • jméno domény a adresy name server˚ u jsou v souboru /etc/resolv.conf. • m´ısto zde uveden´ ych funkc´ı se doporuˇcuje pouˇz´ıvat obecnˇejˇs´ı volán´ı getaddrinfo().

173

Pˇ r´ıklad: TCP server int nclients = 10, fd, newsock, sz; struct servent *sp; struct protoent *pp; struct sockaddr in sa,ca; sp = getservbyname(argv[1], "tcp"); pp = getprotobyname("tcp"); fd = socket(AF INET, SOCK STREAM, pp->p proto); sa.sin family = AF INET; sa.sin port=sp->s port; sa.sin addr.s addr = INADDR ANY; bind(fd,(struct sockaddr *)&sa,sizeof(sa)); listen(fd, nclients); for(;;) { sz = sizeof(ca); newsock = accept(fd, &ca, &sz); /* Komunikace s klientem */ close(newsock); }

• Toto je obecn´ a kostra serveru. Jméno sluˇzby se zadáv´ a jako parametr programu, odpov´ıdaj´ıc´ı ˇc´ıslo portu hled´ a funkce getservbyname().

174

Pˇ r´ıklad: TCP klient char *host; struct servent *se; struct hostent *ha; struct protoent *pp; int sockfd; struct sockaddr in sa; host = argv[1]; se = getservbyname(argv[2], "tcp"); ha = gethostbyname(host); pp = getprotobyname("tcp"); sockfd = socket(AF INET, SOCK STREAM, pp->p proto); sa.sin family = AF INET; sa.sin port = se->s port; memcpy(&sa.sin addr.s addr, ha->h addr list[0], ha->h length); connect(sockfd, &sa, sizeof(sa)); /* Komunikace se serverem */ close(sockfd);

• V pˇr´ıkladu vyuˇz´ıv´ ame automatického pˇridˇelen´ı volného portu systémem pˇri vol´ an´ı connect(), kterému nepˇredch´ azel bind().

175

ˇ an´ı na data: select() Cek´ int select(int nfds, fd set *readfds, fd set *writefds, fd set *errorfds, struct timeval *timeout ); • zjist´ı, které ze zadan´ ych deskriptor˚ u jsou pˇripraveny pro ˇcten´ı, z´ apis, nebo na kter´ ych doˇslo k v´ yjimeˇcnému stavu. Pokud ˇza´dn´ y takov´ y deskriptor nen´ı, ˇcek´ a do vyprˇsen´ı ˇcasu timeout (NULL . . . ˇcek´ a libovolnˇe dlouho). Parametr nfds ud´ av´ a rozsah testovan´ ych deskriptor˚ u (0, ..., nfds-1). • pro nastaven´ı a test masek deskriptor˚ u slouˇz´ı funkce: – void FD ZERO(fd set *fdset ) . . . inicializace – void FD SET(int fd, fd set *fdset ) . . . nastaven´ı – void FD CLR(int fd, fd set *fdset ) . . . zruˇsen´ı – int FD ISSET(int fd, fd set *fdset ) . . . test

• motivace: jestliˇze chceme ˇc´ıst data z v´ıce deskriptor˚ u, jde nastavit pˇr´ıznak O NONBLOCK a neblokuj´ıc´ım read() stˇr´ıdavˇe testovat jednotlivé deskriptory, mezi kaˇzd´ ym kolem test˚ u pak tˇreba pouˇz´ıt sleep(1). Lepˇs´ı ˇreˇsen´ı, tj. bez aktivn´ıho ˇcek´ an´ı a testován´ı, je pouˇz´ıt select() a n´ aslednˇe read() na ty deskriptory, které select() ohl´ as´ı jako pˇripravené. • pˇripravený (ready) znamen´ a, ˇze read nebo write s vynulovan´ ym pˇr´ıznakem a data jsou pˇripraO NONBLOCK by se nezablokovalo, tedy ne nutnˇe ˇze nˇejak´ vena (read napˇr. m˚ uˇze vr´ atit 0 pro end-of-file) • mnoˇzina errorfds je pro vyj´ımky v z´ avislosti na typu deskriptoru; pro socket to je napˇr´ıklad pˇr´ıchod urgentn´ıch dat (flag U u TCP). Neznamen´ a to, ˇze na daném deskriptoru doˇslo k chybˇe! Chyba s nastaven´ ym errno se zjist´ı z ostatn´ıch mnoˇzin po n´ avratovém kódu -1 provedeného volán´ı, tj. napˇr´ıklad read(). • pˇri vol´ an´ı jsou v mnoˇzin´ ach deskriptory, které chceme testovat, po n´ avratu z˚ ustanou nastavené jen ty deskriptory, na kter´ ych nastala testovan´ a ud´ alost. Je nutn´ e je tedy pˇ red dalˇ s´ım vol´ an´ım select() znovu nastavit. Typicky to jsou bitové masky, ale nemus´ı tomu b´ yt tak; z pozice program´ atora je to samoˇzˇrejmˇe jedno. • funkce select() je pouˇziteln´ a i pro ˇcek´ an´ı na moˇznost z´ apisu do roury nebo soketu – ˇcek´ a se, aˇz druh´ a strana nˇeco pˇreˇcte a uvoln´ı se m´ısto v bufferu pro dalˇs´ı data. • m´ısto mnoˇziny pro deskriptory je moˇzné uvést NULL, speci´ aln´ı pˇr´ıpad pˇri nastaven´ı vˇsech mnoˇzin na NULL je volán´ı, které se pouze zablokuje do pˇr´ıchodu signálu nebo do vyprˇsen´ı time-outu.

176

• po n´ avratu je nutné otestovat kaˇzd´ y deskriptor zvláˇst’, nen´ı k dispozici volán´ı, které by vám vytvoˇrilo mnoˇzinu pˇripraven´ ych deskriptor˚ u. • pokud obsluhuje s´ıt’ov´ y server v´ıce port˚ u, m˚ uˇze volat select() na pˇr´ısluˇsné deskriptory soket˚ u a n´ aslednˇe accept() na deskriptory, pro které select() ohl´ asil pˇr´ıchod ˇza´dosti klienta (pˇripravenost ke ˇcten´ı). • vol´ an´ı connect() na neblokuj´ıc´ım soketu se hned vr´ at´ı, navázán´ı spojen´ı ohl´ as´ı n´ asledn´ y select() jako pˇripravenost k z´ apisu. • dalˇs´ı moˇznost pouˇzit´ı select() je s´ıt’ov´ y server, kter´ y v jednom procesu obsluhuje paralelnˇe nˇekolik klient˚ u. Pomoc´ı select() se testuje stav deskriptor˚ u odpov´ıdaj´ıc´ıch spojen´ı s jednotliv´ ymi klienty a pˇres deskriptory pˇripravené pro ˇcten´ı/z´ apis se komunikuje. Aby se mohli pˇripojovat nov´ı klienti, testuje se i deskriptor soketu, kter´ y se pouˇz´ıv´ a pro accept(). Vyuˇz´ıv´ a se toho, ˇze select() ohl´ as´ı deskriptor s ˇcekaj´ıc´ı ˇza´dost´ı klienta o spojen´ı jako pˇripraven´ y pro ˇcten´ı. Na takov´ y deskriptor je moˇzné volat accept(). • jako v´ yjimeˇcnou ud´ alost (mnoˇzina errorfds) select() ohl´ as´ı pˇr´ıchod outof-band dat. • pozor na to, ˇze select m˚ uˇ ze zmˇenit strukturu timeval, existuje nové volán´ı pselect, které (mimo jiné) strukturu pro timeout nezmˇen´ı. • pro nfds je moˇzné pouˇz´ıt FD SETSIZE, coˇz je systémová konstanta pro maxim´ aln´ı poˇcet deskriptor˚ u. Typicky to vˇsak nebude pˇr´ıliˇs efektivn´ı, protoˇze tato konstanta je vˇetˇsinou 1024 na 32-bitov´ ych systémech, na Solarisu to vˇsak pro 64-bitové architektury je uˇz 65536. • pokud se ˇcas nastav´ı na 0 (tj. ted’ nemluv´ıme o nastaven´ı ukazatele na NULL), select se d´ a pouˇz´ıt pro tzv. polling – zjist´ı souˇcasn´ y stav a hned se vr´ at´ı.

ˇ an´ı na data: poll() Cek´ int poll(struct pollfd fds [], nfds t nfds, int timeout ); • ˇcek´ a na ud´ alost na nˇekterém z deskriptor˚ u v poli fds o nfds prvc´ıch po dobu timeout ms (0 . . . vr´ at´ı se hned, -1 . . . ˇcek´ a libovolnˇe dlouho). • prvky fds: – fd . . . ˇc´ıslo deskriptoru – events . . . oˇcek´ avané ud´ alosti, OR-kombinace POLLIN (lze ˇc´ıst), POLLOUT (lze psát), atd. – revents . . . ud´ alosti, které nastaly, pˇr´ıznaky jako v events, nav´ıc napˇr. POLLERR (nastala chyba)

177

• tato funkce je obdoba vol´ an´ı select(). • na Solarisu je to systémové volán´ı, select pak knihovn´ı funkce implementovan´ a pomoc´ı poll, poll je zde prefererováno. Je nutné poll pouˇz´ıt v pˇr´ıpadˇe, ˇze chcete testovat deskriptor vˇetˇs´ı nebo rovno neˇz FD SETSIZE. • ˇcas nastaven´ y na -1 je to samé jako NULL u select.

Pˇ r´ıklad: pouˇ zit´ı select() /* deskriptor fd odkazuje na soket, pˇ repisuje s´ ıt’ovou komunikaci na termin´ al a naopak */ int sz; fd set rfdset, efdset; char buf[BUFSZ]; for(;;) { FD ZERO(&rfdset); FD SET(0, &rfdset); FD SET(fd, &rfdset); efdset = rfdset; select(fd+1, &rfdset, NULL, &efdset, NULL); yjimka na stdin */; if(FD ISSET(0, &efdset)) /* V´ if(FD ISSET(fd, &efdset)) /* V´ yjimka na fd */; if(FD ISSET(0, &rfdset)) { sz = read(0, buf, BUFSZ); write(fd, buf, sz); } if(FD ISSET(fd, &rfdset)) { sz = read(fd, buf, BUFSZ); write(1,buf,sz); } }

• zde je typické pouˇzit´ı select(), kdy je tˇreba ˇc´ıst data souˇcasnˇe ze dvou zdroj˚ u. • pˇred kaˇzd´ ym vol´ an´ım select() se mus´ı znovu nastavit mnoˇziny deskriptor˚ u. • lepˇs´ı ˇreˇsen´ı je nastavit oba deskriptory jako neblokuj´ıc´ı a pouˇz´ıvat select() i na z´ apis. Logika ˇr´ızen´ı je pak taková, ˇze pro kaˇzd´ y smˇer datové komunikace máme samostatn´ y buffer. Pˇr´ısluˇsn´ y ˇctec´ı deskriptor bude v mnoˇzinˇe pro ˇcten´ı v select(), právˇe kdyˇz je buffer prázdn´ y. Naopak z´ apisov´ y deskriptor bude v mnoˇzinˇe pro z´ apis, právˇe kdyˇz je buffer nepr´ azdn´ y.

178

spr´ ava s´ıt’ov´ ych sluˇ zeb: inetd • servery s´ıt’ov´ ych sluˇzeb se spouˇst´ı bud’ pˇri startu systému, nebo je startuje démon inetd pˇri pˇripojen´ı klienta. • démon inetd ˇcek´ a na portech definovan´ ych v /etc/inetd.conf a kdyˇz detekuje pˇripojen´ı klienta, naváˇze spojen´ı, spust´ı pˇr´ısluˇsn´ y server a pˇresmˇeruje mu deskriptory 0, 1 a 2 do soketu, pˇres kter´ y lze komunikovat s klientem. • pˇr´ıklad obsahu /etc/inetd.conf: ftp stream tcp nowait root /usr/etc/ftpd ftpd -l shell stream tcp nowait root /usr/etc/rshd rshd -L login stream tcp nowait root /usr/etc/rlogind rlogind exec stream tcp nowait root /usr/etc/rexecd rexecd finger stream tcp nowait guest /usr/etc/fingerd fingerd ntalk dgram udp wait root /usr/etc/talkd talkd tcpmux stream tcp nowait root internal echo stream tcp nowait root internal

• start pˇres inetd ˇsetˇr´ı prostˇredky, protoˇze pˇr´ısluˇsn´ y server bˇeˇz´ı pouze po ˇcas, kdy jsou jeho sluˇzby opravdu potˇreba. Nehod´ı se tedy pro pro spoustˇen´ı vyt´ıˇzen´ ych sluˇzeb (www) nebo sluˇzeb kde je velky overhead pˇri inicializaci (napˇr. SSH kv˚ uli generován´ı kl´ıˇce). • typicky se pomoc´ı inetd spouˇst´ı servery, které se pouˇz´ıvaj´ı málo nebo jejichˇz inicializace je relativnˇe nenároˇcn´ a (telnetd, ftpd). Silnˇe vyt´ıˇzené a dlouho startuj´ıc´ı servery (httpd) se obvykle startuj´ı ze systémov´ ych inicializaˇcn´ıch skript˚ u a bˇeˇz´ı st´ ale. • ˇcasto má cenu inetd m´ıt vypnut´ yu ´ plnˇe. Pokud na vaˇsem stroji bˇeˇz´ı napˇr. pouze SSH, tak pro to se inetd ve vˇetˇsinˇe pˇr´ıpad˚ u nepouˇz´ıv´ a, inetd by byl jen dalˇs´ım serverem bˇeˇz´ıc´ım na stroji a zdroj potenci´ aln´ıho nebezpeˇc´ı, pokud by se v nˇem objevila bezpeˇcnostn´ı chyba.

179

Form´ at souboru /etc/inetd.conf sluˇ zba soket proto ˇ cek´ an´ ı uˇ ziv server argumenty • sluˇ zba . . . jméno s´ıt’ové sluˇzby podle /etc/services • soket . . . stream nebo dgram • proto . . . komunikaˇcn´ı protokol (tcp, udp) • c ˇek´ an´ ı . . . wait (inetd ˇcek´ a na ukonˇcen´ı serveru pˇred akceptován´ım dalˇs´ıho klienta), nowait (inetd akceptuje dalˇs´ıho klienta hned) • uˇ zivatel . . . server pobˇeˇz´ı s identitou tohoto uˇzivatele • server . . . u ´ pln´ a cesta k programu serveru nebo internal (sluˇzbu zajiˇst’uje inetd) • argumenty . . . pˇr´ıkazov´ y ˇra´dek pro server, vˇcetnˇe argv[0]

• soket typu stream: – wait . . . server dostane soket, na kter´ y mus´ı aspoˇ n jednou zavolat accept(). Teprve t´ım z´ıská nov´ y soket, pˇres kter´ y m˚ uˇze komunikovat s klientem. Po skonˇcen´ı serveru pˇreb´ır´ a ˇr´ızen´ı soketu zpˇet inetd. – nowait . . . inetd zavol´ a accept() a z´ıskan´ y soket pˇred´ a serveru, server tedy m˚ uˇze rovnou komunikovat (m˚ uˇze pouˇz´ıvat standardn´ı vstup a v´ ystup) a nemus´ı vˇedˇet, ˇze komunikuje po s´ıti. Mezit´ım inetd ˇcek´ a na dalˇs´ı klienty a podle potˇreby spouˇst´ı dalˇs´ı instance serveru. • pro soket typu dgram má smysl pouze wait. Server mus´ı pˇreˇc´ıst ze soketu aspoˇ n jeden datagram. • jestliˇze inetd restartuje server (kromˇe stream nowait) pˇr´ıliˇs ˇcasto (cca jednou za sekundu), usoud´ı, ˇze nastala chyba a po urˇcitou dobu (asi 10 minut) sluˇzbu zablokuje (nespouˇst´ı server a odm´ıtá spojen´ı). Ostatn´ı servery spouˇst´ı norm´ alnˇe d´ al.

180


Vl´ akna • vl´ akno (thread ) = linie v´ ypoˇctu (thread of execution) • vl´ akna umoˇzn ˇ uj´ı m´ıt v´ıce lini´ı v´ ypoˇctu v r´ amci jednoho procesu • klasick´ y unixov´ y model: jednovl´ aknové procesy • vl´ akna nejsou vhodn´ a pro vˇsechny aplikace • v´ yhody vl´ aken: – zrychlen´ı aplikace, typicky na v´ıceprocesorech (vlákna jednoho procesu mohou bˇeˇzet souˇcasnˇe na r˚ uzn´ ych procesorech) – modul´ arn´ı programován´ı • nev´ yhody vl´ aken: – nen´ı jednoduché korektnˇe napsat sloˇzitˇejˇs´ı kód pouˇz´ıvaj´ıc´ı vl´ akna – obt´ıˇznˇejˇs´ı debugging

181

• pro aplikace, kde kaˇzd´ y krok z´ avis´ı na kroku pˇredch´ azej´ıc´ım, nemaj´ı vl´ akna pˇr´ıliˇs velk´ y smysl. • debuggery typicky maj´ı podporu vl´ aken, ale debugging zmˇen´ı timing, takˇze to co v re´ alu dˇel´ a problém se pˇri debuggingu v˚ ubec nemus´ı projevit. Toto samozˇrejmˇe nen´ı problémem u klasick´ ych 1-vl´ aknov´ ych proces˚ u. • jak bylo uvedeno na slajdech s doporuˇcenou literaturou, k vl´ akn˚ um to je [Butenhof]. On-line pak je tˇreba dostupn´ a velmi dobr´ a a obs´ ahl´ a kniha Multithreaded Programming Guide na http://docs.sun.com.

Implementace vl´ aken library-thread model • vl´ akna jsou implementována v knihovnách, jádro je nevid´ı. • run-time knihovna plánuje vl´ akna na procesy a jádro plánuje procesy na procesory. ⊕ menˇs´ı reˇzie pˇrep´ınán´ı kontextu ⊖ nem˚ uˇze bˇeˇzet v´ıce vl´ aken stejného procesu najednou. kernel-thread model • vl´ akna jsou implementována pˇr´ımo jádrem. ⊕ v´ıce vl´ aken jednoho procesu m˚ uˇze bˇeˇzet najednou na r˚ uzn´ ych procesorech. ⊖ plánován´ı thread˚ u pouˇz´ıv´ a systémová volán´ı m´ısto knihovn´ıch funkc´ı, t´ım v´ıce zatˇeˇzuje systém. hybridn´ı modely • vl´ akna se multiplexuj´ı na nˇekolik jádrem plánovan´ ych entit.

• p˚ uvodnˇe UNIX s vl´ akny nepracoval a prvn´ı implementace byly ˇcistˇe knihovn´ı, bez u ´ˇcasti j´ adra. Dnes se pouˇz´ıv´ a sp´ıˇse implementace vl´ aken v jádru nebo sm´ıˇsen´ y model. • existuj´ı i jiné typy implementace vl´ aken neˇz jsou zde uvádˇen´ a POSIXová vl´ akna (napˇr. systémové vol´ an´ı sproc() v IRIXu, Cthreads, Solaris threads, . . . ). • zat´ımco pˇ ri pr´ aci s v´ıce procesy je nutn´ e vyvinou jist´ e u ´ sil´ı proto, aby dan´ e procesy mohly data sd´ılet, u vl´ aken je naopak nutn´ eˇ reˇ sit situaci, jak pˇ rirozen´ e sd´ılen´ı dat uhl´ıdat. • vl´ akna implementována pouze v knihovnˇe mohou b´ yt preemptivn´ı i nepreemptivn´ı. Pro preemptivnost je moˇzné pouˇz´ıt ˇcasovaˇce a signály. Pokud multithreading (= pouˇzit´ı vl´ aken v aplikaci) nen´ı pouˇzit pro zv´ yˇsen´ı v´ ykonu aplikace, typicky nen´ı problém s pouˇzit´ım nepreemptivn´ıch vl´ aken. Stˇr´ıdán´ı vl´ aken se automaticky dos´ ahne pouˇz´ıv´ an´ım blokuj´ıc´ıch systémov´ ych volán´ı.

182

• pokud se vol´ an´ı v library-thread modelu zablokuje, zablokuje se cel´ y proces, tj. ˇza´dné vl´ akno nem˚ uˇze bˇeˇzet. To vypl´ yv´ a z toho, ˇze jádro v tomto modelu o pojmu vl´ akno nic nev´ı. Knihovn´ı funkce jsou proto pˇrepsány tak, ˇze m´ısto blokuj´ıc´ıch vol´ an´ı se pouˇzij´ı neblokuj´ıc´ı a kontext se pˇrepne na jiné vl´ akno.

Vytvoˇ ren´ı vl´ akna int pthread create(pthread t *thread, const pthread attr t *attr, void *(*start fun )(void*), void *arg ); • vytvoˇr´ı nové vl´ akno, do thread uloˇz´ı jeho ID. • nastav´ı atributy (velikost z´ asobn´ıku, plánovac´ı politika) podle attr (pouˇzije implicitn´ı atributy pˇri attr == NULL). • ve vytvoˇreném vl´ aknu spust´ı funkci start fun() s argumentem arg. Po n´ avratu z této funkce se zruˇs´ı vl´ akno. • s objekty pthread attr t lze manipulovat funkcemi pthread attr init(), pthread attr destroy(), pthread attr getstackaddr(), pthread attr setstackaddr(), ...

• pozor na konstrukce typu: for(i = 0; i < N; i++) pthread create(&tid, attr, start routine, &i); na prvn´ı pohled takto pˇred´ ame kaˇzdému vl´ aknu jeho -1. Jenˇze plánovaˇc m˚ uˇze zp˚ usobit to, ˇze neˇz si novˇe spuˇstˇené vl´ akno staˇc´ı pˇreˇc´ıst hodnotu i, pˇr´ıkaz for provede dalˇs´ı iteraci a hodnota se zmˇen´ı. Obecnˇe vl´ akno m˚ uˇze dostat m´ısto spr´ avné hodnoty i libovolnou vˇetˇs´ı. • co ale je moˇzné pouˇz´ıt, pokud potˇrebujeme pˇredat pouze jednu hodnotu, je toto: assert(sizeof(void *) >= sizeof(int)); for(i = 0; i < N; i++) pthread create(&tid, attr, start routine, (void *) i); . . . a ve funkci void *start routine(void *arg) pak pˇretypovat ukazatel zp´ atky na integer a máme potˇrebn´ y identifikátor vl´ akna: printf("thread %d started\n", (int) arg);

183

• pokud potˇrebujeme pˇredat v´ıce bajt˚ u neˇz je velikost ukazatele, tak uˇz opravdu mus´ıme pˇredat ukazatel na pamˇet’ s pˇr´ısluˇsn´ ymi pˇred´ avan´ ymi daty nebo pouˇz´ıt glob´ aln´ı promˇenné.

Soukrom´ e atributy vl´ aken • ˇc´ıtaˇc instrukc´ı • z´ asobn´ık (automatické promˇenné) • thread ID, dostupné funkc´ı pthread t pthread self(void); • plánovac´ı priorita a politika • hodnota errno • kl´ıˇcované hodnoty – dvojice (pthread key t key, void *ptr ) – kl´ıˇc vytvoˇren´ y vol´ an´ım pthread key create() je viditeln´ y ve vˇsech vl´ aknech procesu. – v kaˇzdém vl´ aknu m˚ uˇze b´ yt s kl´ıˇcem asociována jiná hodnota vol´ an´ım pthread setspecific().

• kaˇzdé vl´ akno má z´ asobn´ık pevné velikosti, kter´ y se automaticky nezvˇetˇsuje. • bˇeˇzné glob´ aln´ı promˇenné (a také dynamicky alokovan´ a data) jsou spoleˇcné pro vˇsechna vl´ akna. Kl´ıˇcované hodnoty pˇredstavuj´ı zp˚ usob, jak vytvoˇrit glob´ aln´ı promˇennou, kter´ a je ale lokáln´ı v r´ amci vl´ akna. • kaˇzdé vl´ akno má jeˇstˇe vlastn´ı signálovou masku, k tomu se také dostaneme

184

Ukonˇ cen´ı vl´ akna void pthread exit(void *value ptr ); • Ukonˇc´ı volaj´ıc´ı vl´ akno. • Obdoba exit() pro proces int pthread join(pthread t thread, void **value ptr ); • poˇck´ a na ukonˇcen´ı vl´ akna thread a ve value ptr vr´ at´ı hodnotu ukazatele value ptr z volán´ı pthread exit() nebo n´ avratovou hodnotu hlavn´ı funkce vl´ akna. • obdoba ˇcek´ an´ı na synovsk´ y proces pomoc´ı wait() int pthread detach(pthread t thread ); • nastav´ı okamˇzité uvolnˇen´ı pamˇeti po ukonˇcen´ı vl´ akna, na vl´ akno nelze pouˇz´ıt pthread join().

• pokud nem´ ame v u ´ myslu po skonˇcen´ı vl´ akna volat pthread join(), je tˇreba zavolat pthread detach(). Jinak po ukonˇceném vl´ aknu zbydou v pamˇeti data nutná pro zjiˇstˇen´ı jeho v´ ysledku pomoc´ı pthread join(). To je podobn´ a situace, jako kdyˇz rodiˇcovsk´ y proces nepouˇz´ıv´ a wait() a v systému se hromad´ı zombie. Ve funkci pro vl´ akno doporuˇcuji pouˇz´ıt toto: pthread detach(pthread self()); • ˇcekat na ukonˇcen´ı vl´ akna m˚ uˇze libovolné jiné vl´ akno, nejen to, které ho spustilo.

185

Inicializace int pthread once(pthread once t *once control, void (*init routine )(void)); av´ a ukazatel na staticky • v parametru once control se pˇred´ inicializovanou promˇennou pthread once t once control = PTHREAD ONCE INIT; • prvn´ı vl´ akno, které zavol´ a pthread once(), provede inicializaˇcn´ı funkci init routine(). Ostatn´ı vl´ akna uˇz tuto funkci neprovádˇej´ı, nav´ıc, pokud inicializaˇcn´ı funkce jeˇstˇe neskonˇcila, zablokuj´ı se a ˇcekaj´ı na jej´ı dokonˇcen´ı. • lze pouˇz´ıt napˇr. na dynamickou inicializaci glob´ aln´ıch dat v knihovn´ ach, jejichˇz kód m˚ uˇze zavolat v´ıce vl´ aken souˇcasnˇe, ale je tˇreba zajistit, ˇze inicializace probˇehne jen jednou.

• variantou je inicializace glob´ aln´ıch dat jeˇstˇe pˇredt´ım, neˇz se proces rozdˇel´ı na vl´ akna, coˇz je bˇeˇznˇejˇs´ı zp˚ usob inicializace. • nen´ı definováno, co se má st´ at, pokud je once control automatická promˇenn´ a nebo nem´ a poˇzadovanou hodnotu.

186

Zruˇ sen´ı vl´ akna int pthread cancel(pthread t thread ); • poˇza´d´ a o zruˇsen´ı vl´ akna thread. Z´ avis´ı na nastaven´ı int pthread setcancelstate(int state, int *old ); • nastav´ı nov´ y stav a vr´ at´ı star´ y: – PTHREAD CANCEL ENABLE . . . povoleno zruˇsit – PTHREAD CANCEL DISABLE . . . nelze zruˇsit, ˇza´dost bude ˇcekat na povolen´ı int pthread setcanceltype(int type, int *old ); • PTHREAD CANCEL ASYNCHRONOUS . . . okamˇzité zruˇsen´ı • PTHREAD CANCEL DEFERRED . . . ˇza´dost ˇcek´ a na vstup do urˇcit´ ych funkc´ı (napˇr. open(), read(), wait()), nebo na volán´ı void pthread testcancel(void);

• vl´ akna je moˇzné zvenku ,,n´ asilnˇe” ruˇsit (obdoba ukonˇcen´ı procesu pomoc´ı signálu) bud’ okamˇzitˇe, nebo jen v urˇcit´ ych volán´ıch (tzv. cancellation points). To znamen´ a, ˇze v takovém pˇr´ıpadˇe je moˇzné vl´ akno zruˇsit v ˇcase, kdy je vl´ akno vykon´ av´ a danou funkci. Pokud vl´ akno zrovna takovou funkci nevykon´ av´ a, informace o zruˇsen´ı se “doruˇc´ı” bˇehem vykon´ an´ı prvn´ı takové funkce od té doby. • funkce pthread_cancel() se podobá zruˇsen´ı procesu signálem poslan´ ym vol´ an´ım kill(). • funkce pthread_setcancelstate() a pthread_setcanceltype() jsou obdobou zak´ azán´ı a povolen´ı zruˇsen´ı procesu signálem pomoc´ı manipulace s maskou blokovan´ ych signál˚ u (sigprocmask()). • pˇri zruˇsen´ı vl´ akna se zavolaj´ı u ´ klidové handlery; viz d´ ale.

187

Pˇ r´ıklad: vl´ akna pthread_t id_a, id_b; void *res_a, *res_b; pthread_create(&id_a, NULL, do_a, "a"); pthread_create(&id_b, NULL, do_b, "b"); void *do_b(void *arg) { ... return arg; }

void *do_a(void *arg) { ... return arg; }

pthread_join(id_a, &res_a); pthread_join(id_b, &res_b);

• toto je trivi´ aln´ı pˇr´ıklad, kdy proces (hlavn´ı vl´ akno) vytvoˇr´ı dvˇe dalˇs´ı vl´ akna a poˇck´ a na jejich ukonˇcen´ı.

188

Soukrom´ e kl´ıˇ covan´ e hodnoty ve vl´ aknech int pthread key create(pthread key t *key, void (*destructor )(void *)); • vytvoˇr´ı kl´ıˇc, kter´ y lze asociovat s hodnotou typu (void *). Funkce destructor() se volaj´ı opakovanˇe pro vˇsechny kl´ıˇce, jejichˇz hodnota nen´ı NULL, pˇri ukonˇcen´ı vl´ akna. int pthread key delete(pthread key t key ); • Zruˇs´ı kl´ıˇc, nemˇen´ı asociovan´ a data. int pthread setspecific(pthread key t key, const void *value ); • pˇriˇrad´ı ukazatel value ke kl´ıˇci key. void *pthread getspecific(pthread key t key ); • vr´ at´ı hodnotu ukazatele pˇr´ısluˇsného ke kl´ıˇci key.

• pˇri vytvoˇren´ı kl´ıˇce je s n´ım asociována hodnota NULL. • pˇri ukonˇcen´ı nebo zruˇsen´ı vl´ akna se volaj´ı destruktory (v nespecifikovaném poˇrad´ı) pro vˇsechny kl´ıˇce s hodnotou r˚ uznou od NULL. Aktuáln´ı hodnota je destruktoru pˇred´ ana v parametru. Jestliˇze po skonˇcen´ı vˇsech destruktor˚ u zb´ yvaj´ı kl´ıˇce s hodnotou r˚ uznou od NULL, znovu se volaj´ı destruktory. Implementace m˚ uˇze (ale nemus´ı) zastavit volán´ı destruktor˚ u po PTHREAD DESTRUCTOR ITERATIONS iterac´ıch. Destruktor by tedy mˇel nastavit hodnotu na NULL, jinak hroz´ı nekoneˇcn´ y cyklus. • destruktor si mus´ı s´ am zjistit kl´ıˇc poloˇzky, ke které patˇr´ı, a zruˇsit hodnotu vol´ an´ım pthread setspecific(key, NULL). • SUSv3 tento nesmysln´ y poˇzadavek odstraˇ nuje, protoˇze definuje, ˇze pˇred vstupem do destruktoru je hodnota automaticky nastaven´ a na NULL; destruktor se n´ aslednˇe vyvol´ a s pˇredchoz´ı hodnotou kl´ıˇce.

189

´ Uklid pˇ ri ukonˇ cen´ı/zruˇ sen´ı vl´ akna • vl´ akno má z´ asobn´ık u ´ klidov´ ych handler˚ u, které se volaj´ı pˇri ukonˇcen´ı nebo zruˇsen´ı vl´ akna funkcemi pthread exit() a pthread cancel(). Jako prvn´ı se spouˇst´ı naposledy vloˇzen´ y handler. • po proveden´ı handler˚ u se volaj´ı destruktory priv´ atn´ıch kl´ıˇcovan´ ych dat vl´ akna. void pthread cleanup push(void (*routine )(void *), void *arg ); • vloˇz´ı handler do z´ asobn´ıku. void pthread cleanup pop(int execute ); • vyjme naposledy vloˇzen´ y handler ze z´ asobn´ıku. Provede ho, pokud je execute nenulové.

• handlery se volaj´ı jako routine(arg). • tyto handlery se daj´ı pouˇz´ıvat napˇr. na u ´ klid lokáln´ıch dat funkc´ı (obdoba vol´ an´ı destruktor˚ u pro automatické promˇenné v C++).

190

fork() a vl´ akna (POSIX) • je nutné definovat sémantiku volán´ı fork v aplikac´ıch pouˇz´ıvaj´ıc´ıch vl´ akna. Norma definuje, ˇze: – nov´ y proces obsahuje pˇresnou kopii volaj´ıc´ıho vl´ akna, vˇcetnˇe pˇr´ıpadn´ ych stav˚ u mutex˚ u a jin´ ych zdroj˚ u – ostatn´ı vl´ akna v synovském procesu neexistuj´ı – pokud taková vl´ akna mˇela naalokovanou pamˇet’, z˚ ustane tato pamˇet’ naalokovan´ a (= ztracená) – obdobnˇe to plat´ı pro zamˇcen´ y mutex jiˇz neexistuj´ıc´ıho vl´ akna • vytvoˇren´ı nového procesu z multivl´ aknové aplikace m´ a smysl pro n´ asledné vol´ an´ı exec (tj. vˇcetnˇe volán´ı popen, system apod.)

• pokud mˇelo jiˇz neexistuj´ıc´ı vl´ akno zamˇcen´ y mutex, tak je pˇr´ıstup k pˇr´ısluˇsn´ ym sd´ılen´ ym dat˚ um ztracen, protoˇze zamˇcen´ y mutex m˚ uˇze odemknout pouze to vl´ akno, které ho zamknulo. • ostatn´ı vl´ akna pˇrestanou existovat, nevolaj´ı se ˇza´dné rutiny jako pˇri volán´ı pthread exit, pthread cancel nebo destruktory kl´ıˇcovan´ ych dat • je moˇzné pouˇz´ıt handlery pro fork pomoc´ı funkce pthread atfork. To my potˇrebovat nebudeme, z´ ajemce odkazuji napˇr´ıklad na [Butenhof]. • pozor na to, ˇze chován´ı fork() také z´ avis´ı na pouˇzité knihovnˇe a verzi systému, napˇr´ıklad na Solarisu pˇred verz´ı 10 znamenalo fork() v knihovnˇe libthread (jin´ a knihovna neˇz libpthread) to samé co forkall()

191

Sign´ aly a vl´ akna • signály mohou b´ yt generovány pro proces (volán´ım kill()), nebo pro vl´ akno (chybové ud´ alosti, volán´ı pthread kill()). • nastaven´ı obsluhy signál˚ u je stejné pro vˇsechna vl´ akna procesu, ale masku blokovan´ ych signál˚ u má kaˇzdé vl´ akno vlastn´ı, nastavuje se funkc´ı int pthread sigmask(int how, const sigset t *set, sigset t *oset ); • signál urˇcen´ y pro proces oˇsetˇr´ı vˇzdy právˇe jedno vl´ akno, které nem´ a tento signál zablokovan´ y. • lze vyhradit jedno vl´ akno pro synchronn´ı pˇr´ıjem signál˚ u pomoc´ı vol´ an´ı sigwait(). V ostatn´ıch vl´ aknech se signály zablokuj´ı.

• jestliˇze je pro signál nastaveno ukonˇcen´ı procesu, skonˇc´ı cel´ y proces, nejen jedno vl´ akno. • vytvoˇrené vl´ akno dˇed´ı nastaven´ı signálové masky od vl´ akna, které ho vytvoˇrilo • pˇri pouˇzit´ı sigwait tak vlastnˇe zablokujete pˇr´ısluˇsné signály ve vˇsech vl´ aknech, vˇcetnˇe vl´ akna, ve kterém chcete zpracováv´ avat signály. Viz pˇredn´ aˇska o signálech. Tento zp˚ usob zpracován´ı signál˚ u b´ yv´ a ˇcasto jedin´ y opravdu doporuˇcovan´ y pro vl´ akna, nav´ıc je i nejsn´ aze implementovateln´ y. • v re´ alné aplikaci nen´ı rozumné blokovat vˇsechny sign´ aly, tj. vˇcetnˇe signál˚ u pos´ılan´ ych jako ozn´ amen´ı chyb – SEGV, FPE atd. Viz pˇredn´ aˇska o signálech.

192

Synchronizace vl´ aken: mutexes (1) • nejjednoduˇsˇs´ı zp˚ usob zajiˇstˇen´ı synchronizovaného pˇr´ıstupu ke sd´ılen´ ym dat˚ um mezi vl´ akny je pouˇzit´ım mutexu • statické vers. dynamické mutexy • statická inicializace mutexu: pthread mutex t mutex = PTHREAD MUTEX INITIALIZER • inicializace mutexu mx s atributy attr (nastavuj´ı se pomoc´ı pthread mutexattr ...(), NULL = default) int pthread mutex init(pthread mutex t *mx, const pthread mutexattr t *attr ); • po skonˇcen´ı pouˇz´ıv´ an´ı mutexu je nutné ho zruˇsit: int pthread mutex destroy(pthread mutex t *mx );

• mutex = mutual exclusion (vz´ ajemné vylouˇcen´ı) • je to speci´ aln´ı forma Dijkstrov´ ych semafor˚ u – rozd´ıl mezi mutexy a binárn´ımi semafory je ten, ˇze zamˇcen´ y mutex m˚ uˇze odemknout pouze to vl´ akno, které ho zamklo. To u semafor˚ u neplat´ı. • mutexy jsou urˇcené pouze ke kr´ atkodobému drˇzen´ı a mˇely by fungovat rychle. Slouˇz´ı pro implementaci kritick´ ych sekc´ı, podobnˇe jako lock-soubory nebo semafory (pouˇzité jako z´ amky). • inicializace statického mutexu pomoc´ı zm´ınˇeného makra nastav´ı pro mutex jeho defaultn´ı atributy. • dynamické mutexy m˚ uˇzeme potˇrebovat napˇr´ıklad v situaci, kdy dynamicky alokujeme datovou strukturu, jej´ıˇz souˇca´st´ı je i mutex, kter´ y sd´ılená data struktury chrán´ı. I zde, pˇred zavolán´ım funkce free na datovou strukturu, by se mˇelo pouˇz´ıt vol´ an´ı pro zruˇsen´ı mutexu. • je moˇzné dynamicky inicializovat i statické mutexy, ale je tˇreba zajistit, ˇze se vˇzdy inicializuj´ı pˇred pouˇzit´ım (to samozˇrejmˇe plat´ı i pro dynamické mutexy) a ˇze se inicializuj´ı pouze jednou • kop´ırovat mutexy nen´ı korektn´ı – v´ ysledek takové operace nen´ı definován. Je moˇzné samozˇrejmˇe zkop´ırovat ukazatel na mutex a s t´ımto ukazatelem pak d´ ale pracovat.

193

Mutexes (2) • pro zamˇcen´ı a odemˇcen´ı mutexu pouˇzijeme volán´ı: int pthread mutex lock(pthread mutex t *mx ); a int pthread mutex unlock(pthread mutex t *mx ); • pokud je mutex jiˇz zamˇcen´ y, pokus o zamknut´ı vy´ ust´ı v zablokován´ı vl´ akna. Je moˇzné pouˇz´ıt i volán´ı: int pthread mutex trylock(pthread mutex t *mx ); . . . které se pokus´ı zamknout mutex, a pokud to nelze provést, skonˇc´ı s chybou

• nelze zamknout mutex, pokud ho dané vl´ akno jiˇz zamˇcené má. Nˇekdy m˚ uˇze doj´ıt i k self dead-locku. • nelze odemknout nezamˇcen´ y mutex • nelze odemknout mutex, kter´ y zamknulo jiné vl´ akno. Pokud je toto potˇreba, pouˇzijte bin´ arn´ı semafor. • pˇri vytváˇren´ı aplikace, kde je efektivita kl´ıˇcov´ ym faktorem, je nutné rozmyslet, jak, kde a kolik mutex˚ u pouˇz´ıvat. Z knihovny, kter´ a nebyla napsaná pro pouˇzit´ı v aplikac´ıch pouˇz´ıvaj´ıc´ı vl´ akna, je moˇzné udˇelat thread-safe knihovnu tak, ˇze pˇred zavol´ an´ım jakékoli funkce knihovny zamknu jeden giant mutex a po skonˇcen´ı funkce ho odemknu. M´ am tedy pouze jeden mutex a ˇsetˇr´ım tak ˇcas, ale vl´ akna pouˇz´ıvaj´ıc´ı tuto knihovnu ˇcasto sp´ı pˇri ˇcek´ an´ı na pˇr´ıstup. Na druhou stranu, pokud zamyk´ am pˇr´ıstup ke konkrétn´ım, mal´ ym sekc´ım, mohu potˇrebovat spoustu mutex˚ u a hodnˇe ˇcasu str´ av´ım ve funkc´ıch které s mutexy pracuj´ı. Je proto ˇcasto nutné podle situace zvolit vhodn´ y kompromis.

194

Podm´ınkov´ e promˇ enn´ e (1) • mutexy slouˇz´ı pro synchronizaci pˇr´ıstupu ke sd´ılen´ ym dat˚ um • podm´ınkové promˇenné pak k pˇred´ an´ı informac´ı o tˇechto sd´ılen´ ych datech • z toho plyne, ˇze kaˇ zd´ a podm´ınkov´ a promˇ enn´ a je vˇ zdy asociov´ ana s jedn´ım mutexem • jeden mutex m˚ uˇze b´ yt asociován s v´ıce podm´ınkov´ ymi promˇenn´ ymi • spoleˇcnˇe pomoc´ı mutex˚ u a podm´ınkov´ ych promˇenn´ ych je moˇzné vytváˇret dalˇs´ı synchronizaˇcn´ı primitiva – semafory – bariéry – ...

• jin´ ymi slovy – podm´ınkové promˇenné se pouˇz´ıvaj´ı v situaci, kdy vl´ akno potˇrebuje otestovat nˇejakou podm´ınku nad sd´ılen´ ymi daty (napˇr. stav ˇc´ıtaˇce poloˇzek ve frontˇe), a uspat se, kdyˇz nen´ı splnˇena. Sp´ıc´ı vl´ akno m˚ uˇze b´ yt probuzeno jin´ ym vl´ aknem, které zmˇen´ı datovou strukturu tak, ˇze podm´ınka bude splnˇena. Dané vl´ akno vˇsak mus´ı explicitnˇe oznámit, ˇze data zmˇenilo. • nen´ı to tak, ˇze pˇri deklaraci podm´ınkové promˇenné, coˇz je pro program´ atora zcela transparentn´ı typ, definujete podm´ınku napˇr. “n je vˇetˇs´ı neˇz 7 ”. Podm´ınkovou promˇennou totiˇz m˚ uˇzete pˇrirovnat k praporu nˇejaké barvy, a pokud ho zvednete, znamen´ a to, ˇze ta vl´ akna, kter´ a ˇcekaj´ı aˇz s t´ımto praporem nˇekdo zam´ av´ a nad hlavou, jsou o této situaci informována a mohou se podle toho zaˇr´ıdit. Nˇekter´ a vl´ akna tak mohou ˇcekat na to, aˇz n bude vˇetˇs´ı neˇz 7, jiná mohou ˇcekat pouze na to, aˇz se n jakkoli zmˇen´ı. Je pouze na program´ atorovi, zda pro kaˇzdou konkrétn´ı situaci pouˇzije jednu podm´ınkovou promˇennou, nebo jednu pro vˇsechny situace dohromady. Pro druhou situaci plat´ı, ˇze vl´ akna ˇcekaj´ıc´ı na nˇejakou ud´ alost mus´ı vˇzdy otestovat, kter´ a ze situac´ı nastala. Pokud ne ta, na kterou vl´ akno ˇcek´ a, znovu se usp´ı. Jak je vˇsak uvedeno d´ ale, z implementaˇcn´ıch d˚ uvod˚ u je nutné podm´ınku otestovat vˇzdy, i kdyˇz pro ni pouˇz´ıv´ ate samostatnou podm´ınkovou promˇennou – m˚ uˇze se st´ at, ˇze systém t´ım praporem zam´ av´ a s´ am, aniˇz by to udˇelalo to vl´ akno, které v naˇs´ı n´ azorné situaci ten ˇc´ıtaˇc n mˇen´ı a n´ aslednˇe to oznamuje.

195

Podm´ınkov´ e promˇ enn´ e (2) int pthread cond init(pthread cond t *cond, const pthread condattr t *attr ); • Inicializuje podm´ınkovou promˇennou cond s atributy attr (nastavuj´ı je funkce pthread condattr ...()), NULL = default. int pthread cond destroy(pthread cond t *cond ); • zruˇs´ı podm´ınkovou promˇennou. int pthread cond wait(pthread cond t *cond, pthread mutex t *mutex ); • ˇcek´ a na podm´ınkové promˇenné dokud jiné vl´ akno nezavolá pthread cond signal() nebo pthread cond broadcast().

• je nutné, aby po té, co vl´ akno zamkne mutex a dˇr´ıve, neˇz vl´ akno zavolá pthread cond wait, otestovat podm´ınku. Pokud tuhle operaci vl´ akno neprovede, mohlo by se uspat na neurˇcitou dobu, protoˇze hláˇska o splnˇen´ı podm´ınky od jiného vl´ akna by proˇsla “bez povˇsimnut´ı”. Jinak ˇreˇceno, nesm´ım se uspat pˇri ˇcek´ an´ı na situaci, kter´ a uˇz mezit´ım nastala. Nefunguje to jako signály, které pro vás systém drˇz´ı, pokud je máte napˇr´ıklad zablokované. Co je d˚ uleˇzité je to, ˇze ten test provád´ıte pod ochranou mutexu, tedy si opravdu m˚ uˇzete b´ yt jist´ı hodnotou naˇseho ˇc´ıtaˇce n.

196

Podm´ınkov´ e promˇ enn´ e (3) int pthread cond timedwait(pthread cond t *cond, pthread mutex t *mutex, const struct timespec *abstime ); • ˇcek´ a na pthread cond signal() nebo pthread cond broadcast(), ale maxim´ alnˇe do vyprˇsen´ı timeoutu abstime. int pthread cond signal(pthread cond t *cond ); • probud´ı jeden proces ˇcekaj´ıc´ı na podm´ınkové promˇenné cond. int pthread cond broadcast(pthread cond t *cond ); • probud´ı vˇsechny procesy ˇcekaj´ıc´ı na podm´ınkové promˇenné cond.

• v parametru abstime funkce pthread cond timedwait() se pˇred´ av´ a absolutn´ı ˇcas, tj. timeout vyprˇs´ı, kdyˇz systémov´ y ˇcas dos´ ahne hodnoty vˇetˇs´ı nebo rovné abstime. Pro absolutn´ı ˇcas bylo rozhodnuto proto, aby program´ ator nemusel pˇri pˇr´ıpadn´ ych probuzen´ıch, kdy n´ aslednˇe zjist´ı, ˇze daná podm´ınka neplat´ı, pˇrepoˇc´ıt´ avat ˇcasov´ y rozd´ıl. • jak jiˇz bylo ˇreˇceno, jedna podm´ınková promˇenná m˚ uˇze b´ yt pouˇzita pro hláˇsen´ı nˇekolika rozd´ıln´ ych situac´ı najednou – napˇr´ıklad pˇri vloˇzen´ı prvku do fronty i pˇri jeho vyjmut´ı. Z toho d˚ uvodu je nutné po probuzen´ı otestovat podm´ınku, na kterou se ˇcek´ a. Dalˇs´ı vˇec, kter´ a z toho vych´ az´ı je ta, ˇze v takovém pˇr´ıpadˇe mus´ıte pouˇz´ıt broadcast. Staˇc´ı si pˇredstavit n´ asleduj´ıc´ı situaci – ˇcek´ ate na podm´ınku “zmˇenil se stav fronty”, na které ˇcekaj´ı ˇcten´ aˇri i zapisovatelé (pˇredpokládejme, ˇze jednu frontu pouˇz´ıv´ a v´ıce ˇcten´ aˇr˚ u i v´ıce zapisovatel˚ u). Pokud po vloˇzen´ı zpr´ avy pouze vypust´ıte jednu signalizaci, tak se m˚ uˇze stát, ˇze tato signalizace probud´ı jiného zapisovatele, kter´ y ale samozˇrejmˇe ˇcek´ a na situaci, kdy ˇcten´ aˇr z fronty zpr´ avu odebere. T´ım se stane, ˇze ve frontˇe z˚ ustane zpr´ ava, kter´ a m˚ uˇze b´ yt vytlaˇcena aˇz dalˇs´ı signalizac´ı. • vl´ akno m˚ uˇze b´ yt probuzeno jin´ ym vl´ aknem i v pˇr´ıpadˇe, ˇze ˇcek´ a na jednu konkrétn´ı ud´ alost, kter´ a vˇsak po probuzen´ı vl´ akna jiˇz neplat´ı a pˇritom pro jiné ud´ alosti pˇr´ısluˇsná podm´ınková promˇenná nen´ı pouˇzita (a pˇritom nebyl pouˇzit broadcast!). Pˇredstavte si, ˇze tˇesnˇe po té, kdy jiné vl´ akno zahl´ as´ı splnˇen´ı podm´ınky, m˚ uˇze dalˇs´ı vl´ akno zamknout mutex a nˇejakou akc´ı, napˇr. vyjmut´ım prvku z fronty, zruˇsit platnost podm´ınky “ve frontˇe je zpr´ ava”. To vl´ akno, které je probuzeno, tak najde frontu prázdnou. Dalˇs´ı d˚ uvod pro to, ˇze podm´ınkové promˇenné je nutné vˇ zdy testovat v cyklu. • v ˇr´ıdk´ ych pˇr´ıpadech je moˇzné, ˇze se vl´ akno probud´ı a podm´ınka nen´ı platná i d´ıky konkrétn´ı implementaci. Z toho opˇet vypl´ yv´ a nutnost pouˇzit´ı cyklu. 197

Pouˇ zit´ı podm´ınkov´ ych promˇ enn´ ych pthread cond t cond; pthread mutex t mutex; ... pthread mutex lock(&mutex); while(!podminka(data)) pthread cond wait(&cond, &mutex); set data(data, ...); pthread mutex unlock(&mutex); ... pthread mutex lock(&mutex); set data(data, ...); pthread cond signal(&cond); pthread mutex unlock(&mutex);

• pro zopakován´ı – ke kaˇzdé podm´ınkové promˇenné je potˇreba m´ıt jeˇstˇe mutex. • funkce pthread cond wait() atomicky odemkne mutex a usp´ı vl´ akno. Kdyˇz je vl´ akno probuzeno, nejprve se znovu zamkne mutex (tj. toto zamknut´ı se provede v r´ amci pˇr´ısluˇsné implementace podm´ınkov´ ych promˇenn´ ych!) a teat´ı. prve pak se vol´ an´ı pthread cond wait() vr´ • kdyˇz signalizujeme, ˇze se nˇeco zmˇenilo, neznamená to jeˇstˇe, ˇze po zmˇenˇe bude platit podm´ınka. Nav´ıc, pthread cond wait() se m˚ uˇze vr´ atit, i kdyˇz nebylo vol´ ano ani pthread cond signal() ani pthread cond broadcast(). uˇze tedy doj´ıt, i K probuzen´ı vl´ akna a n´ avratu z pthread cond wait() m˚ kdyˇz podm´ınka nen´ı splnˇena, proto je potˇreba znovu otestovat podm´ınku a pˇr´ıpadnˇe obnovit ˇcek´ an´ı. • vˇsimnˇete si, ˇze odemknut´ı z´ amku n´ asleduje aˇz po signalizaci podm´ınky

198

Read-write z´ amky (1) int pthread rwlock init(pthread rwlock t *l, const pthread rwlockattr t *attr ); • vytvoˇr´ı z´ amek s atributy podle attr (nastavuj´ı se funkcemi pthread rwlockattr ...(), NULL = default) int pthread rwlock destroy(pthread rwlock t *l ); • zruˇs´ı z´ amek int pthread rwlock rdlock(pthread rwlock t *l ); int pthread rwlock tryrdlock(pthread rwlock t *rwlock ); • zamkne z´ amek pro ˇcten´ı (v´ıce vl´ aken m˚ uˇze drˇzet z´ amek pro ˇcten´ı), pokud má nˇekdo z´ amek pro z´ apis, usp´ı volaj´ıc´ı vl´ akno (rdlock()) resp. vr´ at´ı chybu (tryrdlock()).

• najednou m˚ uˇze m´ıt z´ amek bud’ nˇekolik vl´ aken zamˇceno pro ˇcten´ı, nebo maxim´ alnˇe jedno vl´ akno zamˇceno pro z´ apis (a nikdo pro ˇcten´ı). • read-write z´ amky jsou obdobou zamyk´ an´ı soubor˚ u pomoc´ı fcntl().

199

Read-write z´ amky (2) int pthread rwlock wrlock(pthread rwlock t *rwlock ); • zamkne z´ amek pro z´ apis, pokud má nˇekdo z´ amek pro ˇcten´ı nebo z´ apis, ˇcek´ a. int pthread rwlock trywrlock(pthread rwlock t *rwlock ); uˇze zamknout, • jako pthread rwlock wrlock(), ale kdyˇz nem˚ vr´ at´ı chybu. int pthread rwlock unlock(pthread rwlock t *rwlock ); • odemkne z´ amek

• Zvl´ aˇstnost : pokud vl´ akno ˇcekaj´ıc´ı na z´ amek dostane signál, po n´ avratu z handleru se vˇzdy pokraˇcuje v ˇcek´ an´ı, tj. nenastane chyba EINTR. Takto se chovaj´ı i mutexy a podm´ınkové promˇenné. • SUSv3 k probran´ ym mechanism˚ um synchronizace vl´ aken pˇrid´ av´ a jeˇstˇe bariérovou synchronizaci (funkce pthread barrier wait() a nˇekolik pomocn´ ych funkc´ı).

200

atomic add(3c) • pro architektury, kde operace sˇc´ıtán´ı nen´ı atomická • od Solarisu 10 • v´ yraznˇe rychlejˇs´ı neˇz jiné mechanismy pro z´ıskán´ı exkluzivn´ıho pˇr´ıstupu • nutné pouˇz´ıt hlaviˇckov´ y soubor atomic.h • sada vol´ an´ı pro r˚ uzné celoˇc´ıselné typy, napˇr´ıklad: void atomic add int(volatile uint t *target, int delta); void atomic add 8(volatile uint8 t *target, int8 t delta); . . . a dalˇs´ı

pˇr´ıklad: program spust´ı dvˇe vl´ akna, kaˇzdé vl´ akno pracuje se stejnou glob´ aln´ı promˇennou x, do které v cyklu postupnˇe pˇriˇcte ˇc´ısla od jedné do velikosti parametru, které program dostane na vstupn´ı ˇra´dce. Vlákna bˇeˇz´ı paralelnˇe. for (i = 0; i < arg; ++i) x = x + i; poté se sˇc´ıt´ an´ı pro kontrolu provede v hlavn´ım vl´ aknu, a dvojn´ asobek se porovná s diskutovanou glob´ aln´ı promˇennou. Pokud nejsou v´ ysledky stejné, doˇslo k soubˇehu (pˇreteˇcen´ı promˇenné m˚ uˇzeme v této situaci zcela ignorovat). Zde jsou v´ ysledky a ˇcasy bˇehu pro situace, kdy program pouˇzil obyˇcejné sˇc´ıtán´ı, poté funkci atomic add int() a n´ aslednˇe zamyk´ an´ı pomoc´ı mutex˚ u. Testováno na multiprocesorovém stroji UltraSparc T1000, zdroják je v sekci ukázkov´ ych pˇr´ıklad˚ u v adres´ aˇri race-condition pod jménem atomic-add.c: $ time ./a.out 99999999 RACE DETECTED result is 193053170 should be 1574919426 real user sys

0m2.816s 0m4.807s 0m0.009s

$ time ./a.out -a 99999999 everything OK, no race detected result is 1574919426 should be 1574919426

201

real user sys

0m9.628s 0m18.431s 0m0.010s

$ time ./a.out -m 99999999 everything OK, no race detected result is 1574919426 should be 1574919426 real user sys

1m23.558s 2m45.978s 0m0.088s

Bari´ era, semafory • bariéra (barrier ) je zp˚ usob, jak udrˇzet ˇcleny skupiny pohromadˇe • vˇsechna vl´ akna ˇcekaj´ı na bariéˇre, dokud ji nedosáhne posledn´ı vl´ akno; pak mohou pokraˇcovat • typické pouˇzit´ı je paraleln´ı zpracován´ı dat na multiprocesorech • bariéry nemaj´ı API, je moˇzné je vytvoˇrit pomoc´ı mutex˚ ua podm´ınkov´ ych promˇenn´ ych

• semafory poch´ az´ı pˇr´ımo z POSIXu • jména funkc´ı nezaˇc´ınaj´ı pthread , ale sem (sem init, sem post, sem wait, . . . ) • je moˇzné je pouˇz´ıt s vl´ akny

• bariéru m˚ uˇzete vyuˇz´ıt napˇr. v situaci, kdy mezi jednotliv´ ymi fázemi zpracován´ı je potˇreba provést jistou inicializaci, vl´ akna pˇred n´ı tedy na sebe vˇzdy mus´ı poˇckat, protoˇze inicializace dalˇs´ı fáze m˚ uˇze zaˇc´ıt aˇz tehdy, kdy skonˇc´ı fáze pˇredchoz´ı. • podm´ınka pro bariéru je tˇreba hodnota ˇc´ıtaˇce rovnaj´ıc´ı se nule. Kaˇzdé vl´ akno, které dos´ ahne bariéry, sn´ıˇz´ı ˇc´ıtaˇc, kter´ y je na zaˇca´tku inicializován na poˇcet vl´ aken. Pokud vl´ akno po dekrementován´ı ˇc´ıtaˇce zjist´ı, ˇze jeˇstˇe nen´ı roven nule, usp´ı se na podm´ınkové promˇenné. Pokud dané vl´ akno je t´ım vl´ aknem, které sn´ıˇz´ı ˇc´ıtaˇc na nulu, m´ısto zavolán´ı pthread cond wait poˇsle broadcast, kter´ y n´ aslednˇe probud´ı vˇsechna vl´ akna sp´ıc´ı na bariéˇre (signalling zde nestaˇc´ı, chcete probudit vˇsechna vl´ akna, ne jen jedno!). Pˇred spuˇstˇen´ım dalˇs´ı fáze zpracován´ı se ˇc´ıtaˇc reinicializuje na p˚ uvodn´ı hodnotu. I zde je nutné ˇreˇsit r˚ uzné problémy, napˇr´ıklad nen´ı moˇzné jen tak reinicializovat ˇc´ıtaˇc poté, co bariéry dos´ ahne posledn´ı vl´ akno, protoˇze jak jiˇz v´ıme, vl´ akna po probuzen´ı

202

z pthread cond wait mus´ı vˇzdy otestovat, zda ˇc´ıtaˇc je opravdu nulov´ y a pokud nen´ı, opˇet se usp´ı. Takˇze by se vám mohlo stát, ˇze by se probudila jen nˇekter´ a vl´ akna, nebo taky ˇza´dná. Jak byste to ˇreˇsili? • funkce pro semafory se drˇz´ı klasické UNIXové sémantiky – pˇri chybˇe vracej´ı -1 a nastav´ı errno

Typick´ e pouˇ zit´ı vl´ aken • pipeline – kaˇzdé z vl´ aken provád´ı svoji operaci nad daty, kter´ a se postupnˇe pˇred´ avaj´ı mezi vl´ akny – kaˇzdé vl´ akno typicky provád´ı jinou operaci . . . zpracován´ı obr´ azku, kde kaˇzdé vl´ akno provede jin´ y filtr • work crew – vl´ akna provádˇej´ı stejnou operaci, ale nad jin´ ymi daty . . . zpracován´ı obr´ azku dekompozic´ı – kaˇzdé vl´ akno zpracováv´ a jinou ˇca´st obr´ azku, v´ ysledkem je spojen´ı zpracovan´ ych dat ze vˇsech vl´ aken; zde se hod´ı ˇreˇsen´ı s bariérou • client – server

• dané rozdˇelen´ı je jen orientaˇcn´ı, pouˇzit´ı vl´ aken je samozˇrejmˇe neomezené, toto jsou asi ty tˇri nejˇcastˇejˇs´ı pouˇzit´ı

203

Thread-safe, reentrantn´ı funkce • thead-safe znamen´ a, ˇze kód m˚ uˇze b´ yt volán z v´ıce vl´ aken najednou bez destruktivn´ıch n´ asledk˚ u – do funkce, kter´ a nebyla navrˇzena jako thread-safe, je moˇzné pˇridat jeden z´ amek – na zaˇca´tku funkce se zamkne, na konci odemkne – tento zp˚ usob ale samozˇrejmˇe nen´ı efektivn´ı. . . • slovem reentrantn´ı se ˇcasto mysl´ı, ˇze daná funkce byla navrˇzena s pˇrihlédnut´ım na existenci vl´ aken – . . . tedy ˇze daná funkce pracuje efektivnˇe i ve v´ıcevláknovém prostˇred´ı – taková funkce by se mˇela vyvarovat pouˇzit´ı statick´ ych dat a pokud moˇzno i prostˇredk˚ u pro synchronizaci vl´ aken, které jinak zpomaluj´ı bˇeh aplikace

• v dneˇsn´ı dobˇe thread-safe vˇetˇsinou znamen´ a reentrantn´ı, tj. funkce jsou pˇrepsány tak, aby pracovaly efektivnˇe i s vl´ akny, ale je dobré vˇedˇet, ˇze nˇekdy to m˚ uˇze vyjadˇrovat rozd´ıl.

204

Nepˇ renositeln´ a vol´ an´ı • nepˇrenositeln´ a vol´ an´ı konˇc´ı ˇretˇezcem np (non-portable) • jednotlivé systémy si takto definuj´ı vlastn´ı volán´ı • FreeBSD – pthread set name np(pthread t tid, const char *name) → umoˇzn ˇ uje pojmenovat vl´ akno • Solaris – pthread cond reltimedwait np(...) → jako timedwait, ale ˇcasov´ y timeout je relativn´ı • OpenBSD – int pthread main np(void) → umoˇzn ˇ uje zjistit, zda volaj´ıc´ı vl´ akno je hlavn´ı (= main())

• tyto informace jsou pro zaj´ımavost, abyste vˇedˇeli, ˇze se s podobn´ ymi vˇecmi m˚ uˇzete setkat. Nepˇrenositeln´ a volán´ı by se mˇela pouˇz´ıvat sp´ıˇse pro lad´ıc´ı u ´ˇcely. Nikdy nev´ıte, kdo bude potˇrebovat váˇs kód spustit na jiném systému, coˇz se stane typicky a neˇcekanˇe po té, co zrovna opust´ıte vaˇsi spoleˇcnost a nem´ ate jiˇz ˇcas to opravit. • zjistit, jak´ a nepˇrenositeln´ a vol´ an´ı váˇs systém poskytuje je jednoduché, tˇreba pomoc´ı apropos np

205

Obsah • u ´ vod, v´ yvoj UNIXu a C, program´ atorské n´ astroje • z´ akladn´ı pojmy a konvence UNIXu a jeho API • pˇr´ıstupová práva, perifern´ı zaˇr´ızen´ı, systém soubor˚ u • manipulace s procesy, spouˇstˇen´ı program˚ u • signály • synchronizace a komunikace proces˚ u • s´ıt’ová komunikace • vl´ akna, synchronizace vl´ aken • UNIX z pohledu spr´ avce • ??? - bude definováno pozdˇeji, podle toho kolik zbyde ˇcasu

tato kapitola bude pravdˇ epodobnˇ e nahrazena

206

ChangeLog 2007-12-12 pˇrid´ ano mnoho nov´ ych pozn´ amek ke slajd˚ um o s´ıt’ov´ e komunikaci. aken, p201. 2007-12-09 pˇrid´ an slajd pro atomic add(3c) v sekci synchronizace vl´ 2007-11-21 r˚ uzn´ a mal´ a doplnˇ en´ı k sign´ al˚ um (ve slajdech i pozn´ amk´ ach) 2007-11-18 opraveny dalˇs´ı v´ yskyty znaku ‘0’ m´ısto ˇretˇ ezce ‘len’, tentokr´ at na slajdech k mmap vol´ an´ı. 2007-11-07 doplnˇ eny pozn´ amky o soft updates (pˇrid´ an konkr´ etn´ı pˇr´ıklad) 2007-10-23 nov´ y slajd ,,API vers ABI”, p33, a doplnˇ en´ı pozn´ amek k z´ apisu do pojmenovan´ e roury, p85 2007-10-15 doplnˇ eny pozn´ amky ke slajd˚ um o promˇ enn´ ych prostˇred´ı a ˇ cten´ı/z´ apisu z/do roury (tam byly i faktick´ e chyby). 2007-10-07 ˇ ca ´steˇ cnˇ e pˇreps´ any pozn´ amky ke slajd˚ um o historii unixu, standardech a souˇ casn´ ych syst´ emech; doplnˇ eny pozn´ amky k dynamick´ emu linkeru, debugger˚ um a C. 2007-09-16 vyˇrazena kapitola o administraci, bude nahrazeno nˇ eˇ c´ım jin´ ym, pravdˇ epodobnˇ e aplikac´ı autoconf. 2007-09-16 opravy pˇreklep˚ u, gramatick´ ych chyb a pod. (d´ıky frido at devnull dot cz) 2007-07-18 generov´ an´ı tohoto textu bylo pˇresunuto z FreeBSD na Solaris a tak´ e jsem pˇreˇsel z CsLaTeX na Babel. M˚ uˇ ze to ovlivnit nˇ ekter´ e fonty a t´ım i sazbu textu.

207

Konec

208

Jan Pechanec. verze: 17. prosince SISAL MFF UK, Malostranské nám. 25, Praha 1

Recommend Documents