POSIX a OS RV: pokus o systematizáciu. Základné koncepty a myšlienky štandardu POSIX

Predmet: Operačné systémy.
Otázka: č.8

—————————————————————

Princípy konštrukcie OS:

1.) Princíp modularity- modul sa vo všeobecnosti chápe ako funkčne úplný prvok systému vyrobený v súlade s prijatými intermodulárnymi rozhraniami. Podľa svojej definície modul predpokladá schopnosť ľahko ho nahradiť iným, ak sú k dispozícii špecifikované rozhrania. Rozdelenie systému na moduly je do značnej miery dané použitou metódou návrhu OS (zdola nahor alebo naopak).

Privilegované, re-entrant a re-entrant moduly sú obzvlášť dôležité pri budovaní operačného systému (re-entitlement je doslova opätovné oprávnenie; špeciálny výraz na označenie zdravia programu; vlastnosť programu správne sa spustiť, keď dochádza k rekurzívnemu (vrátenému) volaniu z prerušenia).

Najväčší efekt z využitia tohto princípu je dosiahnuteľný v prípade súčasného rozšírenia tohto princípu na OS, aplikačné programy a hardvér.

2.) Princíp funkčnej selektivity- v OS je alokovaná určitá časť dôležitých modulov, ktoré musia byť neustále v RAM pre efektívnejšiu organizáciu výpočtového procesu. Táto časť sa v OS nazýva jadro, pretože je základom systému. Pri vytváraní zloženia jadra je potrebné vziať do úvahy dve protichodné požiadavky. Na jednej strane by jadro malo obsahovať najčastejšie používané systémové moduly, na druhej strane počet modulov by mal byť taký, aby množstvo pamäte, ktorú jadro zaberá, nebolo príliš veľké. Okrem softvérových modulov, ktoré tvoria jadro a sú trvalo umiestnené v pamäti RAM, môže existovať mnoho ďalších modulov systémového softvéru, ktoré sú tzv. tranzit. Moduly programu Transit sa načítavajú do pamäte RAM iba v prípade potreby av prípade nedostatku voľného miesta ich možno nahradiť inými modulmi typu Transit.

3.) Princíp generovateľnosti OS: podstata princípu spočíva v zorganizovaní (voľbe) takej metódy pre prvotnú prezentáciu centrálneho systému riadiaceho programu OS (jadra a hlavných komponentov trvalo umiestnených v RAM), čo umožnilo prispôsobiť túto systémovú dohľadovú časť. na základe špecifickej konfigurácie konkrétneho výpočtového komplexu a rozsahu úloh, ktoré sa majú riešiť. Tento postup sa zriedka vykonáva pred dostatočne dlhou prevádzkovou dobou OS. Proces generovania sa vykonáva pomocou špeciálneho generátorového programu a vhodného vstupného jazyka pre tento program, ktorý umožňuje popísať softvérové ​​možnosti systému a konfiguráciu stroja. V dôsledku generácie sa získa plná verzia OS. Vygenerovaná verzia OS je súbor systémových sád modulov a údajov.

4.) Princíp funkčnej redundancie: Táto zásada zohľadňuje možnosť vykonávať rovnakú prácu rôznymi prostriedkami. Operačný systém môže obsahovať niekoľko typov monitorov (moduly dohľadu, ktoré riadia jeden alebo iný typ zdroja), rôzne prostriedky na organizovanie komunikácie medzi výpočtovými procesmi. Prítomnosť niekoľkých typov monitorov, niekoľko systémov správy súborov umožňuje užívateľom rýchlo a najefektívnejšie prispôsobiť OS špecifickej konfigurácii výpočtového systému, zabezpečiť čo najefektívnejšie zaťaženie hardvéru pri riešení konkrétnej triedy problémov, získať maximum výkon pri riešení danej triedy problémov.

5.) Princíp virtualizácie: konštrukcia virtuálnych zdrojov, ich distribúcia a používanie sa v súčasnosti používa takmer v každom OS. Tento princíp vám umožňuje reprezentovať štruktúru systému vo forme špecifickej sady procesných plánovačov a alokátorov zdrojov (monitorov) a používať jednotnú centralizovanú schému prideľovania zdrojov.

Najprirodzenejším a najkompletnejším prejavom konceptu virtuality je koncept virtuálny prístroj... Virtuálny stroj poskytnutý používateľovi reprodukuje architektúru skutočného stroja, ale architektonické prvky v tomto znázornení prichádzajú s novými alebo vylepšenými charakteristikami, ktoré spravidla zjednodušujú prácu so systémom. Charakteristiky môžu byť ľubovoľné, ale najčastejšie chcú mať používatelia svoj vlastný „ideálny“ stroj z hľadiska architektonických charakteristík v nasledujúcom zložení:

- virtuálna pamäť prakticky neobmedzeného objemu, jednotná z hľadiska logiky prevádzky.

- ľubovoľný počet virtuálnych procesorov schopných pracovať paralelne a interagovať počas prevádzky.

- ľubovoľný počet externých virtuálnych zariadení schopných pracovať s pamäťou virtuálneho stroja paralelne alebo sekvenčne, asynchrónne alebo synchrónne s ohľadom na činnosť jedného alebo druhého virtuálneho procesora, ktorý spúšťa činnosť týchto zariadení.

Jedným z aspektov virtualizácie je organizácia schopnosti spúšťať v danom OS aplikácie, ktoré boli vyvinuté pre iné OS. Inými slovami, hovoríme o organizovaní niekoľkých operačných prostredí.

6.) Princíp nezávislosti programov od externých zariadení: tento princíp je teraz implementovaný v drvivej väčšine operačných systémov na všeobecné použitie. Prvýkrát bol tento princíp najdôslednejšie implementovaný v OS UNIX. Je implementovaný aj vo väčšine moderných operačných systémov PC. Tento princíp spočíva v tom, že prepojenie programov s konkrétnymi zariadeniami sa neuskutočňuje na úrovni vysielania programu, ale počas plánovacieho obdobia jeho realizácie. V dôsledku toho nie je potrebná rekompilácia, keď je program spustený s novým zariadením, na ktorom sú údaje umiestnené.

7.) Princíp kompatibility: jedným z aspektov kompatibility je schopnosť operačného systému spúšťať programy napísané pre iný operačný systém alebo pre staršie verzie tohto operačného systému, ako aj pre inú hardvérovú platformu. Je potrebné oddeliť otázky binárna kompatibilita a kompatibilita zdroja aplikácie.

Binárna kompatibilita sa dosiahne, keď môžete vziať spustiteľný program a spustiť ho na inom OS. Vyžaduje si to kompatibilitu na úrovni inštrukcií procesora a kompatibilitu na úrovni systémových volaní a dokonca aj na úrovni volaní knižníc, ak sú dynamicky prepojené.

Kompatibilita zdroja vyžaduje vhodný prekladač v systémovom softvéri, ako aj kompatibilitu knižníc a systémových volaní. V tomto prípade je potrebné prekompilovať existujúce zdrojové texty do nového spustiteľného modulu.

Je oveľa ťažšie dosiahnuť binárnu kompatibilitu medzi procesormi založenými na rôznych architektúrach. Aby mohol jeden počítač vykonávať programy iného počítača (napríklad program pre PC, ako je IBM PC, je žiaduce spustiť na PC, ako je Apple Macintosh), tento počítač musí pracovať so strojovými inštrukciami, ktoré pôvodne nespúšťa. rozumieť. V takom prípade musí procesor 680x0 (alebo PowerPC) spustiť binárny súbor určený pre procesor i80x86. Procesor 80x86 má vlastný dekodér inštrukcií, registre a vnútornú architektúru. Procesor 680x0 nerozumie binárnemu formátu 80x86, takže musí vybrať každý príkaz, dekódovať ho, aby zistil, či

čo má robiť, a potom spustiť ekvivalentný podprogram napísaný pre 680 × 0.

Jedným z prostriedkov zabezpečenia kompatibility softvéru a používateľských rozhraní je súlad so štandardmi POSIX, ktorých použitie umožňuje vytvárať programy v štýle UNIX, ktoré sú neskôr ľahko prenosné z jedného systému do druhého.

8.) Princíp otvorenosti a škálovateľnosti: Používateľom aj systémovým špecialistom, ktorí spravujú výpočtový systém, je k dispozícii otvorený operačný systém na analýzu. Rozšíriteľný (modifikovateľný, vyvinutý) OS umožňuje nielen využívať možnosti generovania, ale aj zavádzať nové moduly do jeho štruktúry, zlepšovať existujúce atď. Inými slovami, malo by byť možné jednoducho robiť doplnky a zmeny podľa potreby bez ohrozenia integrity systému. Prístup klient-server k štruktúrovaniu operačného systému pomocou mikrojadrovej technológie poskytuje vynikajúce príležitosti na expanziu. V súlade s týmto prístupom je OS zostavený ako súbor privilegovaných riadiacich programov a súbor neprivilegovaných služieb (serverov). Hlavná časť OS zostáva nezmenená a zároveň je možné pridávať nové servery alebo vylepšovať staré. Tento princíp sa niekedy interpretuje ako rozšíriteľnosť systému.

9.) Princíp mobility: operačný systém musí byť relatívne ľahko prenosný

Pripojte sa z jedného typu procesora k druhému typu procesora a z hardvérovej platformy jedného typu, ktorá zahŕňa spolu s typom procesora a spôsobom usporiadania celého počítačového hardvéru (architektúra výpočtového systému) aj iný typ hardvérovej platformy. Všimnite si, že princíp prenosnosti je veľmi blízky princípu kompatibility, hoci nejde o to isté. Písanie prenosného operačného systému je ako písanie akéhokoľvek prenosného kódu, ale je potrebné dodržiavať niekoľko vecí. pravidlá:

- väčšina OS musí byť spustená v jazyku, ktorý je dostupný na všetkých systémoch, na ktoré sa plánuje neskôr portovať. To v prvom rade znamená, že OS musí byť napísaný v jazyku vysokej úrovne, najlepšie v štandardizovanom jazyku, napríklad v C. Program napísaný v assembleri nie je vo všeobecnosti prenosný.

- je dôležité minimalizovať alebo, ak je to možné, vylúčiť tie časti kódu, ktoré priamo interagujú s hardvérom. Hardvérová závislosť môže mať mnoho podôb. Niektoré zrejmé formy závislosti zahŕňajú priamu manipuláciu s registrami a iným hardvérom. Nakoniec, ak nie je možné úplne vylúčiť hardvérovo závislý kód, mal by byť izolovaný v niekoľkých dobre lokalizovaných moduloch. Hardvérovo závislý kód nemusí byť distribuovaný v celom systéme. Môžete napríklad skryť hardvérovo závislú štruktúru v programovateľnom abstraktnom dátovom type.

Zavedenie štandardov POSIX bolo zamerané na zabezpečenie prenosnosti vytvoreného softvéru.

10.) Princíp počítačovej bezpečnosti: Zabezpečenie výpočtovej bezpečnosti je žiaducou vlastnosťou každého systému s viacerými používateľmi. Bezpečnostné pravidlá definujú vlastnosti, ako je ochrana prostriedkov jedného užívateľa pred ostatnými a nastavenie kvót prostriedkov, aby sa jednému užívateľovi zabránilo prevziať všetky systémové prostriedky, ako napríklad pamäť.

Povinnou funkciou sieťových operačných systémov je zabezpečenie ochrany informácií pred neoprávneným prístupom.

—————————————————————

ČoPOSIX: platformovo nezávislé systémové rozhranie pre počítačové prostredie POSIX (Portable Operating System Interface for Computer Environments) je štandard IEEE (Institute of Electrical and Electronics Engineers), ktorý popisuje systémové rozhrania pre otvorené operačné systémy vrátane shellov, utilít a sád nástrojov. Okrem toho POSIX štandardizuje bezpečnostné úlohy, úlohy v reálnom čase, administratívne procesy, sieťové funkcie a spracovanie transakcií. Štandard je založený na systémoch UNIX, ale môže byť implementovaný aj v iných operačných systémoch. POSIX vznikol ako pokus svetoznámej organizácie IEEE o podporu prenosnosti aplikácií v prostrediach UNIX vyvinutím abstraktného štandardu nezávislého na platforme. Napríklad známy OS QNX v reálnom čase vyhovuje špecifikáciám tohto štandardu.

Tento štandard podrobne popisuje systém virtuálnej pamäte VMS (Virtual Memory System), MPE (Multi-Process Executing) multitasking a CTOS (Operačný systém vyrábaný konvergentnou technológiou ...). POSIX je teda vlastne súbor štandardov s názvom POSIX.I –POSIX.12. Treba tiež poznamenať, že POSIX.1 predpokladá C ako hlavný jazyk.

Jazyk popisu funkcií systému API.

Preto programy napísané v súlade s týmito štandardmi budú fungovať identicky na všetkých systémoch kompatibilných s POSIX. V niektorých prípadoch má však norma len poradenský charakter. Niektoré normy sú popísané veľmi stroho, zatiaľ čo druhá časť len povrchne odhaľuje základné požiadavky.

Implementácie operačného systému POSIX API sú rôzne. Ak veľká väčšina systémov UNIX spočiatku vyhovuje špecifikáciám IEEE Standard 1003.1-1990, potom WinAPI nevyhovuje POSIX. Na podporu tohto štandardu v operačnom systéme MS Windows NT bol však zavedený špeciálny modul podpory POSIX API, ktorý funguje na úrovni privilégií používateľských procesov.

Tento modul zabezpečuje konverziu a prenos hovorov z užívateľského programu do jadra systému a späť, pričom pracuje s jadrom cez Win API. Ostatné aplikácie vytvorené pomocou WinAPI môžu odovzdávať informácie aplikáciám POSIX prostredníctvom štandardných mechanizmov I/O streamu (stdin, stdout).

Žiadne súvisiace príspevky...

O normách všeobecne

Medzi praktizujúcimi programátormi existuje názor, že štandardy v programovaní nie sú vôbec potrebné, pretože:

(1) sú spočiatku bezvýznamné, keďže ich autori nepíšu počítačové programy;

(2) spútavajú iniciatívu programátorov;

(3) programátori budú vždy súhlasiť bez štandardov.

Možno by sa tomuto názoru nemalo venovať pozornosť, ak nie za dvoch okolností:

(1) vyjadrujú ho odborníci z praxe, teda práve tí, ktorí „vydávajú softvér“;

(2) Vyššie uvedenú úvahu objavil autor tohto článku v jednej z publikácií na internete venovanej štandardu pre programovací jazyk C, z ktorej vyplynulo, že takýto názor je rozšírený „v medzinárodnom meradle“, a to nielen medzi arogantnými ruskými „superprogramátormi“.

Slovo „štandard“ sa zvyčajne spája s niečím hmotným (štandardné rozmery, štandardné elektrické napätie atď.), kým počítačový program je nehmotný objekt („Nový nehmotný“) a možno sú normy v nehmotnej sfére naozaj zbytočné?

Existuje však jeden vyvracajúci príklad. Súbor pravidiel pravopisu pre ruský jazyk je v podstate štandardom, aj keď nie je schválený normalizačnými orgánmi. Ďalej, okrem pravidiel (alebo, ak chcete, požiadaviek) pravopisu, existujú aj syntaktické pravidlá a čo je najdôležitejšie, sémantika. To posledné dobre ilustruje „detskú“ otázku: prečo sa mačka volá mačka? Na túto otázku existuje presná odpoveď: pretože naši predkovia tak súhlasili; predkovia Angličanov sa dohodli, že budú rovnaké zviera nazývať mačkou, predkovia Nemcov - mačiatko atď. A vôbec, význam, či sémantika, či pravidlá výkladu akéhokoľvek slova alebo spojenia slov sú vecou dohody.

Účel a „super úloha“ štandardu POSIX

Ako už názov napovedá, POSIX (Portable Operating System Interface) je štandard pre rozhranie (rozhranie) medzi operačným systémom a aplikačným programom. Časy, keď programátori písali programy pre „holý“ stroj (implementovali vlastné balíky vstupno/výstupných programov, goniometrické funkcie atď.), sú preč. Text POSIX opakovane zdôrazňuje, že štandard nekladie žiadne požiadavky na detaily implementácie operačného systému; možno ho považovať za súbor dohôd medzi aplikačnými programátormi a vývojármi operačných systémov. POSIX teda (opäť na rozdiel od dosť rozšíreného názoru) zaujíma nielen vývojárov operačných systémov, ale predovšetkým oveľa väčšiu kategóriu programátorov - aplikovaných.

Potreba štandardu tohto druhu bola uznaná už v 80. rokoch, keď sa operačné systémy UNIX rozšírili. Ukázalo sa, že hoci bol tento systém koncipovaný ako jednotný systém, rozdiely medzi jeho konkrétnymi implementáciami viedli k tomu, že aplikačné programy napísané pre jeden systém nebolo možné vždy spustiť v inom. Práve tento problém, známy ako problém s prenosnosťou softvéru, sa POSIX snaží vyriešiť. Prvé vydanie štandardu bolo vydané v roku 1988 (existuje preklad, pozri), v ktorom bola celá škála problémov súvisiacich s prenosnosťou programu rozdelená do dvoch častí: (1) rozhranie aplikačného programu, (2) tlmočník príkazov a pomocné programy. (používateľské rozhranie); tieto časti sa nazývajú POSIX.1 resp. POSIX.21.

Ujasnime si, že v tomto článku budeme hovoriť iba o štandarde rozhrania aplikačného programu POSIX.1, ktorého druhé (a zatiaľ posledné) vydanie bolo schválené 12. júla 1996.

Informatívna časť normy tiež zdôrazňuje, že POSIX nie je popisom rozhrania nejakého „ideálneho“ operačného systému, ale výsledkom zovšeobecnenia a systematizácie skúseností získaných pri vývoji operačných systémov UNIX. Okrem toho POSIX nemôže slúžiť ako príručka alebo návod na operačné systémy, hoci informatívna časť obsahuje programátorské rady a fragmenty programu.

Norma priamo hovorí, že nie je možné vytvoriť plnohodnotný operačný systém so zameraním výlučne na funkcie rozhrania, ktoré sú v ňom opísané. (Predovšetkým POSIX.1 nerieši problémy, ako je sieťovanie a súvisiace funkcie rozhrania alebo grafické rozhranie.) Finančné náklady na nehybnosť softvéru a z toho vyplývajúca potreba zjednotenia rozhrania sú však také veľké, že väčšina predajcov uprednostňuje mať aspoň nejaké štandardné než nemajú žiadne. Z tohto dôvodu sa veľa vývojárov softvéru zameriava na POSIX. To umožňuje, ak nie úplne odstrániť nehybnosť programov, tak aspoň výrazne znížiť nehybnú časť programu.

O sémantike

Ako už bolo spomenuté vyššie, POSIX možno považovať za súbor dohôd medzi vývojárom operačného systému a programátorom aplikácií. „Dohoda“ znamená v prvom rade rovnaký výklad (sémantiku) slov a výrazov. Nasledujú príklady, ktoré ilustrujú náročnosť dosiahnutia „dohody“.

Ako vyjadriť význam v preklade

V prvom rade treba pripomenúť, že štandard POSIX je napísaný v angličtine, čo svojou povahou vyvoláva nejednoznačnosť (napríklad to isté slovo môže byť podstatné meno, prídavné meno a sloveso) a číhajú na ňom „sémantické pasce“. takmer každú stránku. Dobrým príkladom je príklad z beletrie. Jedno z najznámejších diel Oscara Wilda, ktorý brilantne využil túto črtu anglického jazyka, – The Importance of being Earnest – je v ruštine známe ako „The Importance of Being Earnest“. Anglické meno má však aj druhý význam: Earnest (vážny) je priezvisko jednej z postáv a meno by sa dalo preložiť aj inak: "Aké dôležité je byť Ernstom." Existuje ruské priezvisko Serebryany, a ak by tam bolo priezvisko Serious, preklad by bol úplne presný, s prenosom oboch významov.

Podobne je to aj s názvom samotného štandardu: Portable Operating System Interface. Prídavné meno Portable (mobilný) sa vzťahuje na operačný systém aj aplikačný program, no v ruštine ho nemožno tak krátko vyjadriť, možno ho preložiť ako „Rozhranie mobilného operačného systému“ alebo „Rozhranie operačného systému, ktorý poskytuje mobilita aplikačných programov“. Druhá možnosť lepšie odráža zámery vývojárov normy, no zároveň sa stráca prvý význam (pri preklade sa zachovala známejšia prvá možnosť).

Sémantika slova "štandard"

Hlavnému textu normy predchádza preambula, ktorá vysvetľuje význam slov normy IEEE2. Ako vyplýva z týchto vysvetlení, existujú najmenej tri sémantické rozdiely od ruskojazyčného termínu GOST:

(1) Intuitívne sa predpokladá, že GOST má silu zákona, ktorého porušenie je stíhané; POSIX je súbor požiadaviek, ktorých dodržiavanie je úplne dobrovoľné.

(2) GOST je platný, kým nie je zrušený (mnohí pravdepodobne počuli výraz „GOST nebol zrušený“); preambula POSIX hovorí, že ak štandard nebol revidovaný po dobu 5 rokov, znamená to, že otázky, ktoré sa v ňom zvažujú, pravdepodobne stratili svoj význam a možno ho považovať za automaticky zrušený;

(3) GOST je anonymný; v úvodnej časti POSIX je uvedený zoznam tých, ktorí sa podieľali na vývoji tohto štandardu, a tiež adresa, na ktorú je možné posielať požiadavky na výklad; tiež sa v ňom uvádza, že odpoveď na každú žiadosť podlieha schvaľovaciemu postupu (inými slovami, autori normy sa medzi sebou dohodnú pred poskytnutím odpovede).

Preto preklad aj takého známeho slova ako je štandard slovom „štandard“ si vyžaduje komentáre.

Sémantika slov "mal by", "nešpecifikované", "nedefinované", "implementácia-definovaná"

Časť 2 normy sa nazýva Terminológia a všeobecné požiadavky. Obsahuje nielen definície špeciálnych pojmov (ako „proces“ alebo „semafor“), ale aj také zdanlivo samozrejmé slová ako „mal by“ alebo „môže“. Keďže POSIX.1 je štandard rozhrania, jeho požiadavky platia pre operačný systém aj aplikačný program. Výslovná požiadavka je vyjadrená slovom "musí", napríklad: "Ak je úspešný, odkaz () vráti nulu." V tomto príklade hovoríme o požiadavke operačného systému: funkcia link () musí byť implementovaná tak, aby pri úspechu vrátila nulu.

Pojmy „nešpecifikované“ a „nedefinované“ vyjadrujú tú istú myšlienku, že norma umožňuje slobodu výberu, ale význam týchto pojmov je odlišný. Pojem „nešpecifikované“ znamená, že hovoríme o niektorých správnych (akcie, programové konštrukcie atď.), Pojem „nedefinované“ - o nesprávnych (chybných). Informatívna časť normy poskytuje nasledujúce vysvetlenie.

Pojem „nešpecifikovaný“ znamená, že sa predpokladá, že sú známe rôzne možnosti (výsledky, výsledky volania funkcie atď.) a štandard umožňuje ktorúkoľvek z nich; v konkrétnej implementácii operačného systému je možné zvoliť ktorýkoľvek a takýto systém sa považuje za vyhovujúci štandardu. Aplikačný program (prísne v súlade s normou) musí byť napísaný tak, aby správne fungoval v akomkoľvek variante; ako taký pojem implicitne vyjadruje požiadavku na aplikačný program.

Uveďme príklad: „Funkcia readdir () by mala vrátiť ukazovateľ na štruktúru súvisiacu s ďalším prvkom adresára. Či sa vrátia položky katalógu s názvom „point“ a „point-to-point“, norma nešpecifikuje. V tomto príklade sú štyri možné výsledky a požiadavka na aplikáciu je, že musí byť navrhnutá pre ktorýkoľvek z nich.

Ďalší príklad: „Ak je funkcia sigwait (), ktorá dáva pokyn na čakanie na signál so zadaným číslom, volaná vo viacerých riadiacich vláknach, potom keď signál dorazí nie do viac ako jedného z nich, sigwait () sa musí vrátiť. V akom druhu riadiaceho toku k tomu dôjde, norma nešpecifikuje." V tomto príklade môže byť oveľa viac možných výsledkov, ale všetky sú tiež známe a požiadavka na aplikáciu je, že musí správne fungovať pre akýkoľvek výsledok.

Pojem „nedefinované“ znamená, že ani mnohé výsledky nie sú známe, akýkoľvek výsledok je možný, dokonca aj katastrofálny (napríklad zlyhanie systému, strata údajov atď.). Tento výraz v podstate implicitne vyjadruje požiadavku, aby aplikácia nepoužívala zodpovedajúce dáta alebo konštrukcie. Napríklad: "Ak argument dirp pre readdir () neodkazuje na aktuálne otvorený adresár, výsledok je nedefinovaný."

Tento príklad vyžaduje, aby aplikácia nahradila argument funkcie readdir () iba odkazom na otvorený adresár; porušenie tejto požiadavky môže viesť ku katastrofálnym následkom a zodpovednosť za to nesie aplikačný programátor.

Tu je ďalší príklad: „Ak je úspešná, funkcia read () by mala vrátiť celé číslo predstavujúce počet skutočne prečítaných bajtov. V opačnom prípade musí funkcia priradiť kód chyby errno a vrátiť -1 a obsah vyrovnávacej pamäte, na ktorú ukazuje buf, nie je definovaný."

Norma zakazuje použitie údajov z vyrovnávacej pamäte v aplikačnom programe v prípade chyby funkcie read () a dôsledky porušenia tejto požiadavky sú priradené aplikačnému programátorovi.

Význam pojmu „definované implementáciou“ je odlišný od intuitívneho. Je zrejmé, že v konkrétnom operačnom systéme nemôže existovať žiadny „nešpecifikovaný“ alebo „nedefinovaný“ výsledok, nejaký konkrétny výsledok sa bez problémov získa. Pojem „implementation-defined“ vyjadruje požiadavku normy na dokumentáciu operačného systému: výsledok musí byť nielen špecifikovaný (tak či tak to bude musieť urobiť vývojár operačného systému), ale aj explicitne premietnutý do systémovej dokumentácie.

Predvolená sémantika

Ani jeden regulačný dokument nedokáže pokryť celú škálu prípadov, ktoré sa môžu v praxi vyskytnúť, preto sa o niečom nevyhnutne mlčí3. Napríklad popis funkcie môže povedať, že jej argument môže nadobudnúť hodnoty z určitého rozsahu, ale nič sa nehovorí o tom, aký bude výsledok, ak argument nebude spadať do tohto rozsahu. Samozrejme, aby sa predišlo nedorozumeniam, je potrebné mať jednotnú predvolenú sémantiku. V informatívnej časti normy je zaujímavá fráza: "všeobecne akceptovaná sémantika zlyhania je zakázaná." Toto tvrdenie je v rozpore so známym desať rokov starým sloganom „dovolené je všetko, čo nie je vyslovene zakázané“. V povedomí občanov je to zrejme natoľko zakorenené, že mnohí, dokonca aj programátori, s citovaným výrokom normy nesúhlasia. Medzitým, ak použitie akéhokoľvek konštruktu zjavne nie je povolené a nevyplýva to z popisu, potom si každý cvičný programátor uvedomí, že jeho používanie je riskantné a ak nefunguje, nenapadne ho reklamovať.

Procesy a toky riadenia

Oba tieto výrazy vyjadrujú myšlienku paralelného vykonávania. Operačný systém UNIX bol pôvodne koncipovaný ako viacužívateľský a programy spúšťané rôznymi používateľmi musia byť od seba spoľahlivo izolované, aby náhodou nedeformovali „cudzie“ dáta. Táto izolácia je zabezpečená skutočnosťou, že užívateľský program sa vykonáva v rámci procesu, ktorý sa vyvíja vo svojom vlastnom virtuálnom adresnom priestore. Aj keď program obsahuje globálne dáta, pri spustení v rôznych procesoch sa automaticky „rozdelia“ do rôznych adresných priestorov.

Procesný mechanizmus však nie je úplne vyhovujúci pri programovaní úloh v reálnom čase. Aplikácia v reálnom čase (bežiaca v mene toho istého používateľa) môže byť často prirodzene reprezentovaná ako súbežne sa vykonávajúce časti nazývané vlákna. Ich najvýznamnejším rozdielom od procesov je, že všetky riadiace toky sa vyvíjajú v jedinom adresnom priestore; to poskytuje rýchly prístup ku globálnym dátam, no zároveň hrozí ich neúmyselné skreslenie a aby sa tak nestalo, je potrebné dodržiavať určitú programátorskú disciplínu. Zodpovedajúce odporúčania sú obsiahnuté v informatívnej časti normy.

Je potrebné zdôrazniť, že myšlienka multithreadingu je implementovaná v mnohých operačných systémoch v reálnom čase a implementovaná rôznymi spôsobmi v tom zmysle, že každé riadiace vlákno má inú sadu atribútov a funkcií rozhrania; niekedy sa namiesto slova vlákno používa pojem úloha. Aby sa predišlo nejasnostiam, štandard zdôrazňuje, že sa zaoberá výlučne vláknami POSIX a že názvy zodpovedajúcich funkcií rozhrania majú predponu pthread_ (napríklad pthread_create (), pthread_join () atď.).

Súlad s normou. Sémantika slova "zhoda"

Intuitívne sa verí, že ak sú dve položky vyrobené v súlade s rovnakým štandardom, potom je zaručené, že sa navzájom „pária“ a budú spolupracovať v pároch; to je presne účel zavedenia štandardu rozhrania (rozhrania). Keďže POSIX je štandard pre rozhranie, môžeme hovoriť o súlade so štandardom operačného systému aj aplikačného programu.

Štandard POSIX.1 obsahuje niekoľko stoviek (ak nie tisíce) požiadaviek; považuje sa za samozrejmé, že ak nie je splnená aspoň jedna z nich, potom systém (alebo aplikačný program) nespĺňa štandard. Zároveň bolo doteraz napísaných toľko operačných systémov a aplikačných programov triedy UNIX, že je len ťažko rozumné vyžadovať úplnú zhodu v uvedenom zmysle. Ťažkosti pri vytváraní medzinárodného štandardu tohto druhu sa znásobujú existenciou rôznych národných jazykov. Aj keď zabudneme na aplikačné programy určené na spracovanie textov v národných jazykoch, prakticky každý aplikačný program musí vydávať nejaké diagnostické správy a/alebo vnímať texty zadávané operátorom.

• prísne dodržiavanie štandardu POSIX.1;
• súlad s medzinárodnou verziou POSIX.1;
• súlad s národnou verziou POSIX.1;
• Súlad s POSIX.1 s rozšíreniami.

Po druhé, mnohé funkcie rozhrania sú voliteľné; Norma vyžaduje, aby sa voliteľné funkcie rozhrania buď správali tak, ako to predpisuje norma, alebo aby vždy vracali špeciálny chybový kód ENOSYS (to znamená, že funkcia nie je implementovaná). Možnosti sú rozdelené do niekoľkých skupín, z ktorých každá zodpovedá nejakej konfiguračnej konštante, ktorá je deklarovaná (príkazom #define) v príslušnom hlavičkovom súbore; to umožňuje zistiť, či bola funkcia implementovaná počas fázy kompilácie.

Opísaný spôsob dosiahnutia mobility nebol vynájdený autormi POSIX-u, ale v praxi sa už dlho používa; na mnohých operačných systémoch sa konfiguračné konštanty používajú na identifikáciu samotného systému alebo jeho verzie. A tu norma neponúka nič zásadne nové, ale iba systematizuje doterajšiu prax.

Predmety normalizácie a štruktúra normy

Stručne povedané, štandardizačné objekty POSIX.1 sú mená a sémantika. Konkrétnejšie hovoríme o nasledujúcom.

• Názvy funkcií rozhrania. 357 funkcií je štandardizovaných, pričom 107 funkcií je prevzatých zo štandardných knižníc C (matematické, spracovanie reťazcov, vstup / výstup atď.); tieto funkcie sa považujú za súčasť štandardu POSIX.1, ale sú plne opísané v štandarde C.
• Názvy typov údajov systému. Tieto mená majú príponu _t.
• Názvy hlavičkových súborov, ako aj minimálne zloženie týchto súborov.
• Názvy globálnych premenných pre celý systém (napríklad errno).
• Symbolické názvy chybových kódov, ktoré je možné nastaviť počas vykonávania funkcie. Tieto názvy začínajú písmenom E (EPERM, ENOTEMPTY atď.).
• Názvy konfiguračných konštánt. Tieto názvy majú predponu _POSIX_.
• Symbolické názvy čísiel signálov; tieto mená majú predponu SIG. Okrem 20 "tradičných" signálov (SIGABRT, SIGALRM atď.) sú štandardizované signály v reálnom čase, ktorých čísla musia zaberať určitý súvislý rozsah od SIGRTMIN do SIGRTMAX vrátane, obsahujúci minimálne čísla RTSIG_MAX.
• Symbolické názvy zodpovedajúce hodnotám jednotlivých argumentov niektorých funkcií (napríklad argument cmd funkcie fcntl () môže nadobúdať hodnoty F_DUPFD, F_GETFD, F_GETLK atď.).
• Názvy makier, konštanty, bitové príznaky, premenné prostredia.

Vo všeobecnosti sa štandard skladá z dvoch veľkých častí približne rovnakého objemu. Prvá polovica – normatívna časť – obsahuje požiadavky a odporúčania normy (18 oddielov), druhá – informatívna časť – obsahuje prílohy, ktoré poskytujú zoznam odkazov, komentárov a upresnení k normatívnej časti, zloženie hlavičky súbory, príklad profilu ("projekcie") normy (pre Dánsko), charakteristiky a metodiku merania výkonu najdôležitejších funkcií, ako aj popis doplnkových funkcií rozhrania pre prácu so súbormi v reálnom čase; očakáva sa, že v budúcich vydaniach normy budú tieto funkcie zahrnuté v normatívnej časti.

Bočný panel „Súhrny klauzulí normy“ poskytuje predstavu o tom, na ktoré typy služieb operačného systému sa štandard vzťahuje.

Záver

Hlavným obsahom štandardu POSIX je sémantika funkcií rozhrania. Štandardizácia sémantiky sama o sebe nie je jednoduchá záležitosť (každý vie, aké ťažké je dohodnúť sa aj pre dvoch ľudí) a ťažkosti ešte zhoršuje skutočnosť, že programovaniu sa v súčasnosti venuje veľa ľudí. Paradigma súbežnosti je napríklad vyjadrená pojmami ako „proces“, „úloha“ a „tok riadenia“, ale z praktického programovacieho hľadiska „úloha“ v operačnom systéme IBM OS / 360 a skutočný časový operačný systém VxWorks nie je rovnaký. Ďalším príkladom sú semafory. Semafory sú binárne, celočíselné ("s počítadlom") a so vzájomným vylúčením (ktoré mimochodom programátori medzi sebou nazývajú "mutexy", čím sa spontánne snažia predísť nedorozumeniam). A celočíselné semafory, napríklad v operačnom systéme VxWorks, nie sú vôbec rovnaké ako POSIX semafory.

Autori štandardu POSIX, dobre vedomí toho, aké ťažké je prinútiť ľudí, aby sa vzdali svojich návykov (ktoré nazývajú „zavedená prax“), vyhlasujú, že zostavili koherentný a minimálny systém funkcií rozhrania pokrývajúci väčšinu služieb tradične. poskytovaný operačným systémom podrobne opísal presnú sémantiku týchto funkcií a vyzval všetkých, aby ich používali pri svojom vývoji4.

Pri čítaní normy má človek občas dojem, že niektoré formulácie mali jediný účel: nevyradiť z kategórie vyhovujúcej norme žiadne aplikačné programy či operačné systémy. Takýto cieľ bol skutočne stanovený a výslovne formulovaný v úvode: norma by mala čo najviac zohľadňovať prevládajúcu prax. Hlavným cieľom však stále zostáva zabezpečenie mobility aplikačných programov.

O autorovi

Sergej Romanyuk - vedúci výskumný pracovník vo Výskumnom ústave pre výskum systémov, vedúci skupiny prekladateľov štandardov POSIX. Možno ho kontaktovať e-mailom na adrese: [e-mail chránený] niisi.msk.ru

1 Treba dodať, že na štandarde sa pracuje už dlhé roky; identifikujú sa nové problémy a sú buď zahrnuté do jednej z existujúcich častí, alebo formalizované ako samostatná časť, ktorá môže byť následne zrušená. Stalo sa to napríklad s front-end zariadeniami v reálnom čase, ktoré boli pôvodne deklarované ako POSIX.4 a neskôr zahrnuté do POSIX.1.

2 IEEE je organizácia, ktorá vyvinula štandard POSIX.

3 Tu „predvolené“ znamená tichý, nie predvolený; nehovoríme o nejakých implicitných hodnotách, ktoré sú skutočne deklarované, ale o absencii odkazov vôbec.

4 Ruský preklad normy bude zverejnený začiatkom roku 2000.

Literatúra

Medzinárodná norma ISO / IEC 9945-1 (ANSI / IEEE Std 1003.1) Druhé vydanie. 1996-07-12. Informačné technológie – Portable Operating System Interface (POSIX) – Časť 1: System Application Program Interface (API).

M.I.Belyakov, Yu.I. Rabover, A.L. Fridman. Mobilný operačný systém. Adresár. Moskva, "Rádio a komunikácia", 1991.

ISO / IEC 9899: 1990, Programovacie jazyky - C.

Sekcia 1	- Úvod
Sekcia 2	- Terminológia a definície
Časť 3	- Funkcie na riadenie procesov (vytvorenie, nahradenie obrázka, dokončenie) a signálov (správa masiek, reakcia na signály)
Časť 4	- Identifikácia (procesy, používatelia, systém, terminál), dopytovanie času stráveného vykonávaním procesu, dopytovanie premenných prostredia.
Sekcia 5	- Správa súborov a adresárov
Časť 6	- Vstupné a výstupné funkcie
Sekcia 7	- Funkcie ovládania terminálu
Časť 8	- Funkcie prevzaté zo štandardu jazyka C
Oddiel 9	- Prístup k databázam používateľov a skupín používateľov
Časť 10	- Dátové formáty na archiváciu a výmenu (tar a cpio)
Časť 11	- Synchronizačné prostriedky: semafory, mutexy a stavové premenné
Časť 12	- Funkcie správy pamäte: pripnutie a uvoľnenie adresného priestoru procesu, mapovanie súborov do pamäte, ochrana pamäte, zdieľaná pamäť
Časť 13	- Funkcie súvisiace s procesmi plánovania a riadiacimi tokmi
Časť 14	- Správa hodín a časovača
Sekcia 15	- Správa frontu správ
oddiel 16	- Základné funkcie súvisiace s riadiacimi tokmi
Sekcia 17	- Údaje špecifické pre vlákno
oddiel 18	- Prostriedky deštrukcie kontrolných tokov

POSIX (portable Operating system interface) je štandard, ktorý popisuje rozhranie medzi operačným systémom a aplikačným programom. Účelom tohto štandardu je zabezpečiť kompatibilitu operačných systémov podobných unixu, ako aj prenosnosť programov na úrovni zdrojového kódu. Avšak štandard POSIX môžu používať nielen unixové systémy. Názov POSIX navrhol Richard Stallman. Vyslovuje sa "posix" - rozhranie pre prenosné operačné systémy Unix.

Trochu histórie

Prvá verzia štandardu POSIX bola IEEE Std 1003. Bola vydaná v roku 1988 a definovala rozhranie medzi programovacím jazykom C a shellom jadra systémov podobných unixu.

V roku 1990 bola vydaná nová verzia IEEE Std 1003.2. V porovnaní s prvým návrhom sa v novom dokumente urobili menšie zmeny.

V roku 1992 bol vydaný dvojzväzkový štandard IEEE Std 1003.2. Dokument opísal tlmočník príkazov a viac ako sto nástrojov.

Ďalšia verzia, vydaná v roku 1993, sa stala malým doplnkom k predchádzajúcim verziám: objavili sa informácie o synchronizácii súborov, semaforoch, nastavení času, časovači, fronte správ, asynchrónnom vstupe a výstupe.

V roku 1995 bol vydaný ďalší štandard na streamoch a dokument z roku 1996 bol akýmsi doplnkom k predchádzajúcim verziám.

Štandard POSIX z roku 1999 popisoval ďalšie rozšírenia v reálnom čase.

V roku 2001 bol vydaný štandard, ktorý kombinuje všetky predchádzajúce verzie. Bolo rozhodnuté použiť ho ako základ pre budúce prijatie noriem.

Aktuálna verzia je POSIX.1, ktorá bola schválená v roku 2008.

Základné myšlienky štandardu POSIX

Podľa zdokumentovaných ustanovení musí mať operačný systém pre správnu interakciu s aplikáciami nasledujúce komponenty:

• sieťové zariadenia;
• vývojové nástroje;
• kontrolné toky;
• nástroje v reálnom čase;
• balíkové služby;
• hlavičkové súbory;
• matematické rozhrania;
• zdedené rozhrania.

Funkcie operačného systému kompatibilné s POSIX

• diferenciácia práv užívateľov a skupín, ako aj superužívateľský root s privilegovanými právami;
• prítomnosť stromového súborového systému, ktorý má jeden koreň /;
• systém a softvérové ​​balíky sú poskytované ako textové súbory - to znamená, že konfigurácie súborov možno meniť jednoduchou úpravou;
• jednotné programovacie API v jazyku C;
• jednotný štandard pre konzolové nástroje a príkazy (POSIX 2).

Operačné systémy certifikované podľa štandardu POSIX zahŕňajú: IBM AIX, UnixWare, Solaris, IRIX, QNX, LynxOS, Mac OS X. OS ako Minix, rôzne vetvy BSD, OpenSolaris, VxWorks, OpenWMS sú plne kompatibilné s jednou z verzií štandard POSIX.... Pokiaľ ide o distribúcie Linuxu, väčšina z nich je v súlade so štandardom Linux Standard Base (LSB), ktorý je zase založený na POSIX.

Vydanie štandardu POSIX z roku 2003 je veľmi rozsiahly, mnohostranný dokument, ktorý podrobne popisuje nasledujúce kategórie systémových komponentov:

vývojové nástroje;

sieťové zariadenia;

nástroje v reálnom čase;

kontrolné toky;

matematické rozhrania;

balíkové služby;

hlavičkové súbory;

zdedené rozhrania.

Práve tento (na najvyššej úrovni, zďaleka nie kompletný) repertoár musí operačný systém zabezpečiť, aby aplikácia fungovala.

Najdôležitejší je koncept zhody so štandardom POSIX. Už sme si všimli, že každé rozhranie má dve strany: volajúceho a volaného. Súlad s POSIX má tiež dve stránky: implementáciu (operačný systém) a prispôsobenie aplikácií.

Implementácia (operačný systém) v súlade so štandardom POSIX musí podporovať všetky požadované utility, funkcie, hlavičkové súbory, poskytujúce správanie špecifikované v štandarde. Konštanta _POSIX_VERSION má hodnotu 200112L.

OS môže poskytovať funkcie, ktoré sú v štandarde označené ako voliteľné, ako aj obsahovať neštandardné funkcie. Ak sa požaduje podpora rozšírenia, musí sa to urobiť konzistentným spôsobom pre všetky požadované časti a podľa popisu v norme.

V hlavičkovom súbore musíte definovať konštanty zodpovedajúce podporovaným voliteľným funkciám (napríklad konštanta _POSIX2_C_DEV slúži vývojovým nástrojom jazyka C). Analýzou týchto konštánt v čase kompilácie aplikácia zistí možnosti používaného operačného systému a prispôsobí sa im. Podobné akcie za behu je možné vykonať pomocou funkcie sysconf () a/alebo pomôcky getconf.

Aby sa minimalizovala veľkosť operačného systému a aplikácií, štandard POSIX poskytuje veľmi jemnú granularitu voliteľných funkcií (celkom štyridsať). Na druhej strane boli vzájomne prepojené voliteľné funkcie spojené do skupín, čo v mnohých prípadoch eliminuje potrebu analyzovať veľké množstvo možností. Tieto skupiny sú nasledovné:

šifrovanie;

nástroje v reálnom čase;

pokročilé nástroje v reálnom čase;

toky v reálnom čase;

pokročilé toky v reálnom čase;

sledovanie;

• zdedené schopnosti.

Napríklad skupina „nástroje v reálnom čase“ (_XOPEN_REALTIME) zahŕňa štrnásť druhov schopností vrátane plánovania založeného na prioritách, asynchrónnych I/O, semaforov, časovačov a podobne.

Verzia Linuxu, na ktorej bol pripravený text tohto kurzu, vytvorila pre niektoré konfiguračné konštanty nasledujúce hodnoty (pozri Výpis 1.1).

$ getconf _POSIX_VERSION

$ getconf POSIX2_C_DEV

$ getconf _XOPEN_REALTIME

$ getconf _POSIX_TRACE

Výpis 1.1. Výsledok použitia pomôcky getconf na jednu z verzií OS Linux. ( html, TXT)

To znamená, že je podporovaná zastaraná verzia štandardu POSIX, okrem iného existujú vývojové nástroje a schopnosti v reálnom čase; nie je k dispozícii žiadne zariadenie na sledovanie.

Dokumentácia operačného systému by mala pokrývať problémy s dodržiavaním normy POSIX a popisovať ďalšie podporované a neštandardné funkcie.

Pre aplikácie je koncepcia súladu s POSIX jemnejšia. Je zabezpečený prísny súlad, ktorého hlavným rozlišovacím znakom je obmedzenie rozsahu používaných schopností v rámci normy. Zvažuje sa aj súlad s používaním rozšírení; v tomto prípade by dokumentácia aplikácie mala obsahovať popis požadovaných neštandardných schopností. Je žiaduce, aby používané rozšírenia funkcií POSIX boli opísané medzinárodnými a/alebo národnými štandardmi.

(Všimnite si, že pre implementáciu je koncept prísneho súladu s POSIX bezvýznamný, už len z toho dôvodu, že neexistujú žiadne operačné systémy bez nástrojov na správu a nie sú popísané v tomto štandarde.)

Profil je súbor možností, ktoré popisujú voliteľné funkcie. Súlad profilu znamená súlad s POSIX a podporu pre špecifikované schopnosti. Profily sú vyberané uvážlivo tak, aby vyhovovali potrebám reprezentatívnych tried používateľov a/alebo aplikácií.

"Podprofily" sú povolené a popisujú podmnožiny štandardných schopností. Implementácia podprofilu môže bežať na hardvérových platformách s obmedzenými zdrojmi a/alebo slúžiť potrebám špecifických aplikácií.

Medzi najdôležitejšie patria koncepty, ktoré popisujú správanie implementácie v rôznych situáciách. V mnohých správnych situáciách je správanie nešpecifikované, čo znamená, že mobilná aplikácia by sa nemala spoliehať na zhodu správania rôznych implementácií. Pre nesprávne situácie môže byť správanie nedefinované; Nielenže by sa aplikácia nemala spoliehať na špecifický vzor takéhoto správania – nemala by vykonávať nesprávne akcie, ktoré spôsobujú nedefinované správanie.

Ďalší úzko súvisiaci termín „správanie závislé od implementácie“ navyše znamená, že správanie pri implementácii je potrebné zdokumentovať.

Štandard POSIX je vyvíjajúci sa organizmus, ktorý existuje už mnoho rokov, v ktorom sa s každým novým vydaním niečo objavuje a niečo stráca. Zastarané funkcie sú funkcie, ktoré sú stále podporované rôznymi implementáciami, ale v budúcnosti pravdepodobne zaniknú. Nové aplikácie by ich nemali používať; pre každý z nich norma počíta s modernou náhradou, ktorá je z hľadiska funkčnosti primeraná.

Pojem „zdedený“ má obmedzenejší význam: opisuje zastarané voliteľné funkcie, ktorým by sa v nových aplikáciách samozrejme malo vyhýbať.

Zabezpečenie mobility (prenosnosti, prenosnosti) softvéru (SW) je úloha mimoriadnej dôležitosti a zložitosti; v našej dobe táto okolnosť sotva potrebuje rozsiahle odôvodnenie. Jedným zo všeobecne akceptovaných spôsobov zvýšenia prenosnosti softvéru je štandardizácia aplikačného prostredia: poskytované rozhrania API, pomocné programy atď. Na úrovni systémové služby podobné prostredie popisuje štandard POSIX (Portable Operating System Interface); názov navrhol uznávaný odborník, zakladateľ Free Software Foundation, Richard Stallman. Budeme brať do úvahy najnovšiu dostupnú verziu štandardu POSIX, vydanie z roku 2003, ktoré možno nazvať „trojitý štandard“, konkrétne: štandard IEEE Std 1003.1, technický štandard Open Group a (pozri, čo je pre nás najdôležitejšie , medzinárodná norma ISO / IEC 9945 (s. 1 (JTC1 / SC22 / WG15) International Organization for Standardization - začala konzultácie o zlúčení a vývoji ich dohliadaných štandardov rozhraní pre systémové služby: IEEE Std 1003.1, IEEE Std 1003.2, Základné špecifikácie z Open Group, ISO / IEC 9945-1, ISO / IEC 9945-2.V septembri toho istého roku v Austine, Texas, v kancelárii IBM, organizačné stretnutie skupiny vytvorenej pre dosiahnutie stanoveného cieľa (viď. http://www.opengroup.org/austin). Základným dokumentom revidovanej normy, ktorej prvý návrh bol predložený v júli 1999, boli Základné špecifikácie od Open Group, keďže obsahovali ustanovenia noriem IEEE a ISO/IEC. V roku 2001, po ukončení prípravných prác, štandard obsahoval tieto štyri časti:

základné definície (pojmy, koncepty a rozhrania spoločné pre všetky časti);

popis aplikačného programovacieho C-rozhrania k systémovým službám;

popis rozhrania k systémovým službám na úrovni príkazový jazyk a komunálne služby;

podrobné vysvetlenie ustanovení normy, odôvodnenie prijatých rozhodnutí.

Ďalej, v ISO, IEEE a Open Group s vyššou alebo menšou rýchlosťou (v rokoch 2001-2002) prešlo formálne schválenie nového štandardu POSIX. Medzitým sa nahromadili relatívne menšie opravy, ktoré boli zohľadnené vo vydaní z roku 2003. S vývojom normy sa rozšíril aj výklad pojmu „POSIX“. Pôvodne sa odvolával na popis dokumentu IEEE Std 1003.1-1988 Prgramovacie prostredie aplikácií OS triedy Unix. Po štandardizácii rozhrania na úrovni príkazového jazyka a obslužného programu je správnejšie chápať slovo „POSIX“ ako štandard ako celok, označujúci časti 2 a 3 uvedené vyššie cez POSIX.1 a POSIX.2 v súlade s číslovanie dokumentov IEEE a ISO / IEC.

Základné myšlienky štandardu POSIX

Štandard POSIX popisuje mnohé základné systémové služby potrebné na fungovanie aplikácií. Sú prístupné cez rozhranie špecifikované pre jazyk C, príkazový jazyk a bežné pomocné programy. Každé rozhranie má dve strany: volajúceho a volaného. Štandard POSIX je primárne orientovaný na volajúceho. Jeho účelom je vytvárať aplikácie mobil na úrovni zdrojového jazyka... To znamená najmä to, že pri portovaní programov C na inú operačnú platformu je potrebná rekompilácia. Prenositeľnosť spustiteľných programov a/alebo objektových súborov nie je zahrnutá. Štandard POSIX nie je v žiadnom prípade obmedzený na prostredie Unix. Existujú operačné systémy (OS) „nezávislého pôvodu“ (napr. systémy v reálnom čase), ktoré poskytujú potrebné služby a tým podporujú vykonávanie aplikácií kompatibilných s POSIX. Možno tvrdiť, že dodržiavanie štandardu POSIX uľahčuje portovanie aplikácií na prakticky akúkoľvek bežnú operačnú platformu. Mimoriadne úsilie o mobilitu vynaložené počas vývojovej fázy sa určite oplatí. Pri definovaní rozhrania k systémovým službám POSIX vynecháva ich implementáciu mimo rozsahu. Najmä sa nelíšia systémové volania a knižničné funkcie... Prostriedky nepodliehajú štandardizácii administratívy, vyžadujú sa len hardvérové ​​obmedzenia a funkcie superužívateľ, čo opäť podčiarkuje zameranie štandardu POSIX na aplikácie a nie na operačné systémy. POSIX je architektúra systému a procesorovo neutrálna. Toto je veľmi dôležitý aspekt mobility aplikácií. Orientácia na medzinárodný štandard jazyka C určovala nielen štýl popisu funkcií, ale do istej miery aj smer vývoja špecifikácií POSIX z hľadiska synchronizácie oboch štandardov. Ako viete, vo vydaní špecifikácií jazyka C z roku 1999 (pozri) bol legalizovaný komplexný typ údajov, čo spôsobilo zodpovedajúce doplnenie funkcií POSIX. Štandard POSIX oddeľuje povinné a voliteľné funkcie, vďaka čomu je povinné jadro čo najkompaktnejšie. Osobitná pozornosť je samozrejme venovaná spôsobom implementácie štandardizovaných funkcií ako v „klasickom“ prostredí Unix, tak aj na iných operačných platformách, v sieťových a distribuovaných konfiguráciách. Vývojári novej verzie štandardu POSIX boli veľmi opatrní, pokiaľ ide o jeho prehistóriu, prehistóriu unixových systémov a čo je najdôležitejšie, aplikácie, ktoré spĺňali staršie verzie štandardu. Snažili sme sa zachovať existujúce rozhrania; proces vývoja sledoval princíp spätná kompatibilita; boli pridané nové rozhrania, aby neboli v rozpore so starými. Úpravám aplikácií nebolo možné úplne vyhnúť z celkom pochopiteľných dôvodov: bolo potrebné odstrániť nezrovnalosti medzi rôznymi počiatočnými špecifikáciami, ako aj opustiť podporu „tradičnej“ verzie jazyka C a prejsť na jeho medzinárodný štandard. .

Základné pojmy štandardu POSIX

Vydanie štandardu POSIX z roku 2003 je veľmi rozsiahly, mnohostranný dokument, ktorý podrobne popisuje nasledujúce kategórie systémových komponentov:

vývojové nástroje;

sieťové zariadenia;

nástroje v reálnom čase;

kontrolné toky;

matematické rozhrania;

balíkové služby;

hlavičkové súbory;

zdedené rozhrania.

Práve tento (na najvyššej úrovni, zďaleka nie kompletný) repertoár musí operačný systém zabezpečiť, aby aplikácia fungovala. Najdôležitejší je koncept Súlad s POSIX... Už sme si všimli, že každé rozhranie má dve strany: volajúceho a volaného. Súlad s POSIX má tiež dve stránky: implementáciu (operačný systém) a prispôsobenie aplikácií. Implementácia (operačný systém) v súlade so štandardom POSIX musí podporovať všetky požadované utility, funkcie, hlavičkové súbory, poskytujúce správanie špecifikované v štandarde. Konštanta _POSIX_VERSION má hodnotu 200112L. OS môže poskytovať funkcie, ktoré sú v štandarde označené ako voliteľné, ako aj obsahovať neštandardné funkcie. Ak sa požaduje podpora rozšírenia, musí sa to urobiť konzistentným spôsobom pre všetky požadované časti a podľa popisu v norme. V hlavičkovom súbore musíte definovať konštanty zodpovedajúce podporovaným voliteľným funkciám (napríklad konštanta _POSIX2_C_DEV slúži vývojovým nástrojom jazyka C). Analýzou týchto konštánt v čase kompilácie aplikácia zistí možnosti používaného operačného systému a prispôsobí sa im. Podobné akcie za behu je možné vykonať pomocou funkcie sysconf () a/alebo pomôcky getconf. Aby sa minimalizovala veľkosť operačného systému a aplikácií, štandard POSIX poskytuje veľmi jemnú granularitu voliteľných funkcií (celkom štyridsať). Na druhej strane boli vzájomne prepojené voliteľné funkcie spojené do skupín, čo v mnohých prípadoch eliminuje potrebu analyzovať veľké množstvo možností. Tieto skupiny sú nasledovné:

šifrovanie;

nástroje v reálnom čase;

pokročilé nástroje v reálnom čase;

toky v reálnom čase;

pokročilé toky v reálnom čase;

sledovanie;

PRÚDY;

zdedené schopnosti.

Napríklad skupina nástrojov v reálnom čase (_XOPEN_REALTIME) zahŕňa štrnásť druhov schopností vrátane plánovania založeného na prioritách, asynchrónnych I/O, semaforov, časovačov a podobne. Verzia Linuxu, na ktorej bol pripravený text tohto kurzu, vytvorila pre niektoré konfiguračné konštanty nasledujúce hodnoty (pozri Výpis 1.1).

$ getconf _POSIX_VERSION 199506 $ getconf POSIX2_C_DEV 1 $ getconf _XOPEN_REALTIME 1 $ getconf _POSIX_TRACE nedefinované Výpis 1.1. Výsledok použitia pomôcky getconf na jednu z verzií OS Linux.

To znamená, že je podporovaná zastaraná verzia štandardu POSIX, okrem iného existujú vývojové nástroje a schopnosti v reálnom čase; nie je k dispozícii žiadne zariadenie na sledovanie. Dokumentácia operačného systému by mala pokrývať problémy s dodržiavaním normy POSIX a popisovať ďalšie podporované a neštandardné funkcie. Pre aplikácie je koncepcia súladu s POSIX jemnejšia. Za predpokladu prísne dodržiavanie, ktorej hlavným rozlišovacím znakom je obmedzenie rozsahu možností, ktoré rámec normy využíva. Zvažuje sa aj súlad s používaním rozšírení; v tomto prípade by dokumentácia aplikácie mala obsahovať popis požadovaných neštandardných schopností. Je žiaduce, aby používané rozšírenia funkcií POSIX boli opísané medzinárodnými a/alebo národnými štandardmi. (Všimnite si, že pre implementáciu je koncept prísneho súladu s POSIX bezvýznamný, už len z toho dôvodu, že neexistujú žiadne operačné systémy bez nástrojov na správu a nie sú popísané v tomto štandarde.) Profil je súbor možností, ktoré popisujú voliteľné Vlastnosti. Súlad profilu znamená súlad s POSIX a podporu pre špecifikované schopnosti. Profily sú vyberané uvážlivo tak, aby vyhovovali potrebám reprezentatívnych tried používateľov a/alebo aplikácií. "Podprofily" sú povolené a popisujú podmnožiny štandardných schopností. Implementácia podprofilu môže bežať na hardvérových platformách s obmedzenými zdrojmi a/alebo slúžiť potrebám špecifických aplikácií. Medzi najdôležitejšie patria koncepty, ktoré popisujú správanie implementácie v rôznych situáciách. V mnohých správnych situáciách je správanie nešpecifikované, čo znamená, že mobilná aplikácia by sa nemala spoliehať na zhodu správania rôznych implementácií. Pre nesprávne situácie môže byť správanie nedefinované; Nielenže by sa aplikácia nemala spoliehať na určitú povahu takéhoto správania - nemala by vykonávať nesprávne akcie, ktoré spôsobujú nedefinované správanie... Ďalší úzko súvisiaci výraz, " správanie závislé od implementácie", navyše znamená, že správanie implementácie musí byť zdokumentované. Štandard POSIX je dlhodobý, vyvíjajúci sa organizmus, v ktorom sa s každou novou revíziou niečo objavuje a niečo stráca. Zastarané sú funkcie, ktoré sú stále podporované rôznymi implementáciami, ale je pravdepodobné, že v budúcnosti vymrú. Nové aplikácie by ich nemali používať, každá z nich má modernú náhradu, ktorá je adekvátna ich funkčnosti. Pojem „zdedený“ je obmedzenejší: popisuje zastarané voliteľné funkcie, ktoré by, samozrejme, mali sa vyhnúť v nových aplikáciách.

Základné koncepty operačných systémov kompatibilných s POSIX

Budeme sa zaoberať nasledujúcimi základnými konceptmi operačných systémov kompatibilných s POSIX:

užívateľ;

súbor;

proces ;

terminál;

hostiteľ;

sieťový uzol;

čas ;

jazykové a kultúrne prostredie.

Toto sú primárne pojmy. Nedajú sa striktne definovať, ale dajú sa vysvetliť pomocou iných pojmov a vzťahov. Pre každý zo zvýraznených konceptov budú popísané atribúty, ktoré sú im vlastné, a operácie, ktoré sa na ne vzťahujú. Text POSIX obsahuje nasledujúce vysvetlenia základných pojmov spolu s odkazmi na atribúty a operácie.

Používateľ má meno a číselný identifikátor.

Súbor je objekt, ktorý možno čítať a/alebo zapisovať a má atribúty, ako sú prístupové práva a typ. Tie zahŕňajú bežné súbory, znakové a blokové špeciálne súbory, potrubie, symbolický odkaz, zásuvku a adresár. Implementácia môže podporovať aj iné typy súborov.

Proces je adresný priestor spolu s riadiacimi vláknami, ktoré v ňom bežia, ako aj so systémovými prostriedkami, ktoré tieto vlákna vyžadujú.

Terminál (alebo koncové zariadenie) je znakový špeciálny súbor, ktorý sa riadi špecifikáciami bežného terminálového rozhrania.

Sieť je súbor vzájomne prepojených hostiteľov.

Jazykové a kultúrne prostredie je súčasťou používateľského prostredia, ktoré závisí od jazykových a kultúrnych zvyklostí.

Na prácu s veľkým počtom entít sú vždy poskytnuté mechanizmy na zoskupovanie a vytváranie hierarchií. Existuje hierarchia súborov, skupín používateľov a procesov, podsietí atď. Na písanie programov pracujúcich s entitami systémov kompatibilných s POSIX sa používa interpret príkazov (jazyk shellu) a / alebo kompilovaný jazyk C. V prvom prípade môže aplikácia používať servisné programy (utility), v druhom - funkcie. Je prirodzené považovať funkčné rozhranie operačných systémov za primárne, pretože väčšina servisných programov je v skutočnosti určená na volanie tej či onej funkcie. Z tohto dôvodu sa nižšie zameriame predovšetkým na funkčnú úroveň. Hlavné operácie použiteľné pre objekty OS sú čítanie, zápis a vykonávanie. Mechanizmus prístupových práv vám umožňuje selektívne povoliť a zamietnuť vykonávanie takýchto operácií. Predtým štandard zahŕňal koncept superužívateľa, ktorý nepodlieha kontrole prístupu. V POSIX-2001 je zvolená flexibilnejšia formulácia – „mať zodpovedajúce privilégiá", čo odráža pokrok v implementácii OS s rozdelením schopností superužívateľa. OS kompatibilné s POSIX definujú objekty, ktoré možno nazvať pomocné; pomáhajú organizovať interakciu medzi hlavnými entitami. Najmä široká škála nástrojov medziprocesová komunikácia... Procesy sa uskutočňujú v špecifickom prostredí, ktorého súčasťou je jazykové a kultúrne prostredie (Locale), tvorené takými kategóriami, ako sú symboly a ich vlastnosti, formáty správ, dátum a čas, číselné a peňažné hodnoty. Zvyčajne sú s procesom spojené aspoň tri súbory - štandardný vstup, stdout, štandardný protokol... Typicky je štandardný vstup priradený klávesnici terminálu a štandardný výstup a štandardný protokol sú priradené obrazovke. Príkazy a (niekedy) zdrojové údaje pre ne sa čítajú zo štandardného vstupu. Výsledky vykonania príkazu sa zapisujú na štandardný výstup. Diagnostické správy sú umiestnené v štandardnom protokole. Operačné systémy môžu mať kvalitatívne požiadavky, napríklad požiadavku na podporu v reálnom čase: schopnosť poskytnúť potrebnú službu počas daného časového obdobia.

Kompilačné prostredie pre aplikácie kompatibilné s POSIX

Spravidla (aj keď nie vždy realizované) sa vývoj aplikácií vykonáva v krížovom režime, to znamená na vývojovej platforme (ekvivalentný termín je platforma nástrojov) nezodpovedá runtime platforme (nazývanej aj cieľová platforma). Platforma nástroja vytvára prostredie na kompiláciu aplikácií takže výsledok kompilácie možno preniesť na cieľovú platformu na neskoršie vykonanie. Najdôležitejšou časťou prostredia kompilácie sú hlavičkové (alebo zahrnuté) súbory, ktoré obsahujú funkčné prototypy, definície symbolické konštanty, makrá, dátové typy, štruktúry atď. Pre každú funkciu opísanú v štandarde POSIX je definované, ktoré hlavičkové súbory musí obsahovať aplikácia, ktorá ju používa (zvyčajne je potrebný jeden súbor). Vyššie bolo uvedené, že prostredníctvom symbolických konštánt definovaných v hlavičkovom súbore , operačný systém poskytuje aplikácii informácie o podporovaných funkciách. Štandard POSIX poskytuje symetrický mechanizmus nazývaný makrá na kontrolu schopností umožňuje aplikáciám deklarovať svoju túžbu získať prístup k určitým prototypom a menám. Hlavné makro na kontrolu funkcie je _POSIX_C_SOURCE. Požiadavky na aplikácie striktne kompatibilné s POSIX zahŕňajú definovanie symbolickej konštanty _POSIX_C_SOURCE s hodnotou 200112L pred zahrnutím akýchkoľvek hlavičkových súborov. Aplikácia kompatibilná s POSIX teda deklaruje, že potrebuje názvy POSIX. Podobnú úlohu zohráva makro _XOPEN_SOURCE (s hodnotou 600). Príklad použitia makra _POSIX_C_SOURCE v zahrnúť súbory OS Linux môže slúžiť ako úryvok zobrazený vo výpise 1.2.

#ak je definované (_REENTRANT) || (_POSIX_C_SOURCE - 0> = 199506L) #define LIBXML_THREAD_ENABLED # endif Výpis 1.2. Príklad použitia makra na kontrolu schopností _POSIX_C_SOURCE.

Štandard POSIX poskytuje niektoré opatrenia na vyriešenie dôležitého a zložitého problému (spôsobeného predovšetkým neobjektívnosťou jazyka C), ktorým je chýbajúce prekrývanie názvov medzi aplikáciou a operačným systémom. Predpony posix_, POSIX_ a _POSIX_ sú vyhradené pre potreby štandardu. Iba systémové (nie aplikácie) názvy môžu začínať podčiarkovníkom, za ktorým nasleduje ďalší podčiarkovník alebo veľké latinské písmeno. Pre zahrnuté súbory sú popísané predpony názvov, ktoré sa v nich používajú. Napríklad pre operácie správy súborov, ktoré sa objavujú v , F_, O_, S_ sa používajú ako predpony. Zariadenia medziprocesovej komunikácie opísané v súbore , predpona je ​​IPC_. Bohužiaľ, existuje veľa hlavičkových súborov a z historických dôvodov chýba určitá všeobecná disciplína v oblasti názvov. Takže manipulovať s charakteristikami terminálov v súbore je definovaných veľa rôznych názvov: EXTB, VDSUSP, DEFECHO, FLUSHO atď. Existuje tiež štyristosedemnásť mien ako _Exit, abort, abs, acos atď., ktoré sa môžu podieľať na úprave externých odkazov aplikačného programu. V dôsledku toho môže aplikačný programátor náhodne „prerušiť“ systémové makro, externú premennú alebo funkciu, preto je vhodné využiť všetky diagnostické nástroje kompilačného prostredia a pozorne si preštudovať správy, ktoré produkujú.

Mobilita aplikácií v súlade s POSIX

Prenosnosť aplikácií kompatibilných s POSIX je v zásade dosiahnuteľná vďaka dvom hlavným faktorom. Jednak je to prítomnosť obrovského množstva štandardizovaných systémových služieb a jednak možnosť dynamicky zisťovať vlastnosti cieľovej platformy a dolaďovať pre ne aplikáciu. (Prirodzene máme na mysli prenositeľnosť v rámci štandardu.) POSIX-kompatibilné aplikácie môžu byť jednoprocesové alebo viacprocesové, so schopnosťou dynamicky prispôsobovať konfiguráciu vlastnostiam cieľovej platformy. Prostriedky na generovanie a ukončenie procesu, zmeniť svoje programy, hlasovanie a/alebo zmena rôznych charakteristík. Procesy môžu byť pozastavené a aktivované v určenom čase. Mechanizmus signalizácie vám umožňuje externe inzerovať udalosti a ukončiť procesy. Existujú prostriedky na ich zoskupenie riadenie práce... Aplikácie sú vybavené regulátormi na riadenie plánovania a procesné priority... Široká škála nástrojov medziprocesovej komunikácie ( fronty správ, zdieľaná pamäť, semafory) a správa pamäte... Nakoniec je možné v rámci procesu organizovať viacero tokov kontroly. Potrebný stupeň determinizmu vykonávania je dosiahnutý vďaka podporným nástrojom v reálnom čase (medzi ne patrí správa disciplíny pri prideľovaní procesorov, signály v reálnom čase, uchovávanie stránok v RAM, časovače s vysokým rozlíšením atď.). Funkcie pre prácu so súbormi uspokoja potreby aplikácií čítať a zapisovať dlhodobé dáta a chrániť tieto dáta pred neoprávneným prístupom. Mechanizmus zámky fragmentov súborov umožňuje zabezpečiť atomicitu transakcií. Asynchrónne I/O umožňuje kombinovať výmenné operácie a tým optimalizovať aplikácie. Pomocou rôznych nástrojov možno pomerne jednoducho organizovať zložité spracovanie údajov. Štandard POSIX starostlivo rieši prístup k externých zariadení pripojené cez sériové linky, najmä na terminály. Možno je potrebná väčšia zrnitosť pre bežné médiá, ako je magnetická páska. Štandardizovaný jazyk shellu je adekvátnym nástrojom na písanie malých mobilných procedúr a ich rýchle interaktívne ladenie. Vyberme si mechanizmus potrubí, ktorý vám umožňuje kombinovať príkazy do reťazcov s filtrovaním medzivýsledkov. Pomôcky poskytujú pokročilé runtime prostredie pre shell procedúry. Vďaka režimu na pozadí je možné organizovať súčasné spúšťanie viacerých programov a interakciu s nimi cez bežný terminál bez možností viacerých okien (okenám by však určite nič nebránilo). POSIX štandardizuje rozhranie príkazového riadku... V zásade je to dostatočné, stredne pohodlné a čo je dôležité, vytvára minimum problémov z hľadiska mobility. Pravdepodobne budúce verzie štandardu budú regulovať grafické rozhranie, ale to je, samozrejme, spojené s ďalšími ťažkosťami pre vývojárov mobilných aplikácií. Jazykové a kultúrne prostredie je jedným z najdôležitejších pojmov štandardu POSIX z pohľadu mobility. Aplikácie sú schopné definovať prostredie, ktoré potrebujú a prispôsobiť sa potrebám používateľov. Systémy pre viacerých používateľov vyžadujú organizáciu interakcie veľkého počtu ľudí. POSIX rieši tento problém reguláciou prostriedkov priamej a poštovej výmeny informácií. Štandard POSIX poskytuje základnú podporu vývoja (predovšetkým pre jazyk C), čo samozrejme neznižuje potrebu špecializovaných, vyvinutých systémov, pokiaľ ide o prácu s naozaj veľkými softvérovými projektmi. Aplikácie sú vybavené štandardizovanými prostriedkami na zistenie charakteristík „veľkého bloku“ cieľového systému (napríklad rozsah podporovaných voliteľných funkcií) a jemnejších charakteristík (aktuálne množstvo voľného miesta na disku). Problém prenosnosti aplikácií je mimoriadne zložitý a dalo by sa prehnane povedať, že štandard POSIX-2001 ho úplne rieši. Po prvé, také dôležité otázky, ako je grafika, rozhranie s viacerými oknami a množstvo ďalších, zostávajú mimo jeho pôsobnosti. Po druhé, v regulovaných oblastiach sú slepé miesta nešpecifikované správanie implementácií. Aby sme to však znova zdôraznili, dodržiavanie štandardu POSIX je základným prvkom disciplíny vývoja moderných aplikácií.