Kurz sa zameriava na štandard pre rozhranie mobilného operačného systému (POSIX), ako aj techniky a metódy programovania aplikácií založené na tomto štandarde, ilustrovaný mnohými príkladmi. Dotýkame sa otázok programovania viacprocesových systémov, interakcie aplikácií v rámci distribuovaných konfigurácií. Poskytovanie mobility (prenosnosť, prenosnosť) softvér(PO) - úloha mimoriadneho významu a zložitosti; V dnešnej dobe si táto okolnosť nevyžaduje rozsiahle zdôvodnenie. Jedným zo všeobecne uznávaných spôsobov, ako zvýšiť mobilitu softvéru, je štandardizácia aplikačného prostredia: poskytované softvérové ​​rozhrania, obslužné programy atď. Na úrovni systémových služieb je takéto prostredie popísané štandardom POSIX (Interface Portable Operating System Interface); názov navrhol známy špecialista, zakladateľ Free Software Foundation Richard Stallman.

Kurz sa zameriava na jeho najmodernejšiu verziu z roku 2003, ktorú možno nazvať „trojitým štandardom“, a to: štandard IEEE Std 1003.1, technická norma Open Group a, čo je pre nás najdôležitejšie, medzinárodná norma ISO / IEC 9945 Tento kurz je o porozumení technikám a metódam používania štandardizovaných pomôcok a funkcií. Cieľom nebolo prerozprávať štandard, zvýrazniť všetky jemnosti implementácie OS, všetky možné chybové kódy atď. Hlavnou vecou je podľa nás cítiť ducha štandardu, naučiť sa využívať možnosti, ktoré sú mu vlastné, mobilným spôsobom. Za predpokladu, že čítačka ovláda jazyk C, neberieme do úvahy ani jej funkcie syntaxe, ani učebnice. Pokiaľ ide o štandardný príkazový jazyk a jeho tlmočník, táto téma je podrobne popísaná, aj keď mnohí cviční programátori radšej používajú iné tlmočníky. Významné miesto - z hľadiska objemu aj úlohy - majú príklady programov. Mnohé ustanovenia normy (súvisiace napríklad s riešením chybových situácií) nie sú uvedené v hlavnom texte, ale v zodpovedajúcich príkladoch. Posledne uvedené, kedykoľvek to bolo možné, boli zostavené a vykonávané na niekoľkých hardvérových a softvérových platformách, do jednej. stupňa alebo iného tvrdenia, že je v súlade so štandardom POSIX. Dohľady sú však určite možné. Budeme vďační za všetky pripomienky a návrhy súvisiace s kurzom ako celkom a s jednotlivými príkladmi programov.

História tvorby a súčasný stav štandardu POSIX.

Zabezpečenie mobility (prenosnosť, prenosnosť) softvéru (SW) je úlohou mimoriadneho významu a zložitosti; v našej dobe táto okolnosť sotva potrebuje rozsiahle zdôvodnenie. Jedným zo všeobecne uznávaných spôsobov, ako zvýšiť prenosnosť softvéru, je štandardizácia aplikačného prostredia: poskytované rozhrania API, pomocné programy atď. Na úrovni systémových služieb je takéto prostredie popísané štandardom POSIX (Interface Portable Operating System Interface); názov navrhol známy odborník, zakladateľ Free Software Foundation, Richard Stallman.

Titulná strana.
Výkon.
Prednáška 1. Základné pojmy a myšlienky štandardu POSIX.
Prednáška 2. Jazyk škrupiny.
Prednáška 3. Pomôcky a funkcie slúžiace pojmu „užívateľ“.
Prednáška 4. Organizácia súborového systému.
Prednáška 5. Vstup / výstup súboru.
Prednáška 6. Nástroje na spracovanie štruktúrovaných dát.
Prednáška 7. Procesy.
Prednáška 8. Prostriedky medziprocesovej komunikácie.
Prednáška 9. Rozhranie spoločného terminálu.
Prednáška 10. Analýza vlastností hostiteľa a ich použitie v aplikáciách.
Prednáška 11. Sieťové zariadenia.
Prednáška 12. Čas a práca s ním.
Prednáška 13. Jazykové a kultúrne prostredie.
Prednáška 14. Záver.
Bibliografia.

Bezplatné stiahnutie e-kniha v pohodlnom formáte sledujte a čítajte:
Stiahnite si knihu Programovanie v štandarde POSIX, 1. časť, Galatenko V.A., 2016 - fileskachat.com, rýchle a bezplatné stiahnutie.

POSIX a RV OS: pokus o systematizáciu

Sergej Zolotarev, Nikolaj Gorbunov

Cieľom tohto článku je pokus vniesť trochu jasnosti do histórie vývoja štandardu POSIX, ktorý sa uplatňuje na operačné systémy v reálnom čase (RT OS).

Na úvod: prečo je potrebná štandardizácia softvérového rozhrania?

Jednou z najdôležitejších vlastností štandardu POSIX je, že definuje „štandardizované programovacie rozhranie“, ktoré musia vývojári komplexných softvérových a hardvérových systémov dodržiavať. Tvorcovia týchto systémov sú nútení čeliť takým požiadavkám, ako je obmedzený čas uvedenia na trh (kvôli tvrdej konkurencii), minimalizácia nákladov a zrýchlenie návratnosti investícií. Leví podiel na nákladoch v dôsledku spomalenia vývojového procesu je zároveň spôsobený tým, že programátori musia „znovu objaviť koleso“, znova a znova implementovať funkčnosť, ktorá je už nejaký čas k dispozícii. Tomu sa však dalo vyhnúť:

• opätovné použitie kódu z minulých a paralelných projektov;
• prenos kódu z iných operačných systémov;
• prilákanie vývojárov z iných projektov (vrátane tých, ktorí používajú iné operačné systémy).

To všetko je možné vďaka použitiu OS so štandardizovaným API. Navyše, ak v prvom prípade stačí, aby organizácia mala určitý interný štandard (čo je obzvlášť typické pre proprietárne operačné systémy), potom druhé dva prípady vyžadujú iba prítomnosť všeobecne uznávaných štandardov - napríklad POSIX.

Vývojár tak pomocou OS kompatibilného s POSIX ako platformy pre svoje projekty dostane príležitosť preniesť hotový kód na úroveň zdrojového kódu zo svojich minulých alebo paralelných projektov, ako aj z projektov tretích strán. To nielenže výrazne skracuje čas vývoja softvéru, ale tiež zlepšuje jeho kvalitu, pretože testovaný kód vždy obsahuje menej chýb.

Kto je kto vo vývoji POSIX

A nezačneme samotným štandardom POSIX, ale usporiadaním úlohy organizácií zapojených do práce na ňom.

Prvým účastníkom je IEEE(Ústav elektrotechnických a elektronických inžinierov, Ústav elektrotechnických a elektronických inžinierov), verejné neziskové združenie profesionálov. IEEE siaha do roku 1884 (formálne - od roku 1963), združuje 380 000 jednotlivých členov zo 150 krajín, vydáva tretiu časť technickej literatúry súvisiacej s používaním počítačov, riadiacej, elektrickej a informačnej technológie, ako aj viac ako 100 časopisov. populárne medzi profesionálmi; okrem toho združenie organizuje viac ako 300 veľkých konferencií ročne. IEEE sa podieľal na vývoji viac ako 900 existujúcich štandardov (www.ieee.ru/ieee.htm). Dnes sa tento ústav zaoberá prípravou, koordináciou, schvaľovaním a vydávaním noriem, ale vzhľadom na svoj formálny štatút nemá právomoc prijímať také dokumenty ako medzinárodné alebo národné normy. Preto by mal byť pojem „štandard“ v chápaní IEEE chápaný skôr ako „špecifikácia“, ktorá je v súlade so stavom dokumentov prijatých asociáciou. V súlade s IEEE sa zúčastňuje na programoch viacerých medzinárodných a regionálnych organizácií - IEC, ISO, ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute), CENELEC (Európsky výbor pre elektrotechnickú štandardizáciu) a na národných programy, napríklad v programe takej organizácie, ako je ANSI.

IEEE obsahuje výbor PASC (Portable Application Standards Committee), asociačný výbor, ktorý vyvíja skupinu štandardov POSIX (www.pasc.org/). PASC bol predtým známy ako technický výbor pre operačné systémy.

Druhý účastník práce - ANSI(American National Standards Institute, American National Standards Institute) - súkromná nezisková organizácia, ktorá v USA spravuje a koordinuje činnosti v oblasti normalizácie. Zamestnáva iba 75 ľudí, ale ANSI má viac ako 1 000 členov, spoločností, organizácií, vládnych agentúr a inštitúcií (www.ansi.org). ANSI zastupuje Spojené štáty v dvoch veľkých medzinárodných normalizačných orgánoch, ISO a IEC.

Tretí účastník - ISO(Medzinárodná organizácia pre štandardizáciu). Bol vytvorený v roku 1946 rozhodnutím Výboru pre koordináciu noriem a Valného zhromaždenia OSN a oficiálne začal pracovať 23. februára 1947 (www.iso.org). ISO je sieť národných normalizačných inštitútov zo 146 krajín (jedna krajina - jeden člen ISO) s ústredným sekretariátom v Ženeve (Švajčiarsko). Normy ISO sú vyvíjané v technických komisiách, ktorých prvým výstupom je návrh medzinárodnej normy (DIS), ktorý sa po niekoľkých schváleniach stáva konečným návrhom medzinárodnej normy (FDIS). Potom sa hlasuje o otázke schválenia tohto dokumentu; ak bude úspešný, stane sa medzinárodným štandardom.

A nakoniec - IEC(International Electrotechnical Commission, International Electrotechnical Commission - IEC), založená v roku 1906, IEC pripravuje a vydáva medzinárodné normy pre všetky elektrické, elektronické a súvisiace technológie (www.iec.ch/). K 1. novembru 2004 boli aktívnymi členmi tejto komisie národné výbory 64 krajín. IEC taktiež vydáva odporúčania, ktoré sú publikované v angličtine a francúzštine a majú štatút medzinárodných štandardov. Na ich základe sú vyvinuté regionálne a národné normy. Technické komisie (TC) sú zodpovedné za prípravu noriem v rôznych oblastiach činností IEC, na ktorých sa zúčastňujú národné výbory zaujímajúce sa o činnosti konkrétnej TC.

IEC je kľúčovou organizáciou pri príprave medzinárodných štandardov informačných technológií. V tejto oblasti existuje spoločný technický výbor pre informačné technológie - JTC 1, vytvorený v roku 1987 v súlade s dohodou medzi IEC a ISO. JTC1 má 17 podvýborov, ktoré dohliadajú na všetko od softvéru po programovacie jazyky, počítačovú grafiku a úpravu obrázkov, prepojenie zariadení a bezpečnostné postupy.

Príprava nových noriem IEC zahŕňa niekoľko etáp (predbežná, fáza návrhu, prípravná fáza, fáza technickej komisie, fáza žiadosti, fáza schválenia, publikácia). Ak sa má dokument IEC stať iba technickou špecifikáciou a nie medzinárodnou normou, revidovaná verzia dokumentu sa odošle na publikovanie. Dokončenie konečného návrhu medzinárodnej normy (FDIS) bude trvať štyri mesiace. Ak to schvália všetci členovia technickej komisie, zašle sa to ústrednému úradu na zverejnenie bez fázy schválenia FDIS. Potom ide FDIS do národných výborov, ktoré ho musia schváliť do dvoch mesiacov. FDIS sa považuje za schválený, ak zaň hlasovali viac ako dve tretiny národných výborov a počet záporných hlasov nepresahuje 25%. Ak dokument nie je schválený, je odoslaný na revíziu technickým výborom a podvýborom. Norma musí byť zverejnená najneskôr dva mesiace po schválení FDIS.

Na vývoji a prijímaní štandardov POSIX sa podieľa niekoľko ďalších organizácií.

Otvorená skupina Je medzinárodná organizácia pre štandardizáciu softvéru, ktorá združuje takmer 200 výrobcov a užívateľských komunít pracujúcich v oblasti informačných technológií (www.opengroup.org/). Skupina Open Group vznikla v roku 1995 zlúčením dvoch svojich predchodcov: X / Open a Open Software Foundation (OSF). Open Group sa špecializuje na vývoj metodík certifikácie softvéru a testovanie zhody. Open Group sa zaoberá predovšetkým certifikáciou pre oblasti ako COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S / MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specification (WAP) a, nakoniec rodina štandardov POSIX (www.opengroup.org/certification/).

Austin Common Standards Revision Group (CSRG)- spoločný technický pracovná skupina vytvorená v roku 2002 ISO, IEC a otvorenou skupinou na vytváranie a údržbu najnovšie verzieštandard 1003.1, ktorý bude vytvorený na základe ISO / IEC 9945-1-1996, ISO / IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 a jednotnej špecifikácie UNIX (www.opengroup.org / press/ 14nov02.htm).

Národný inštitút pre štandardy a technológie (NIST)- federálna agentúra v rámci správy technológie ministerstva obchodu (www.nist.gov/public_affairs/general2.htm), založená v USA v roku 1901. Poslaním NIST je vyvíjať a podporovať štandardy a technológie na zlepšenie kvality výrobkov. NIST obsahuje Laboratórium informačných technológií (ITL), ktorého jedným z výsledkov sú federálne normy pre spracovanie informácií (FIPS, www.opengroup.org/testing/fips/general_info.html). NIST / ITL ponúkla počiatočný súbor testov na certifikáciu POSIX podľa FIPS PUB 151-1 1990 v roku 1991.

Čo je POSIX?

Formálne termín POSIX navrhol Richard Stallman ako skratku pre P ortable O perating S ystem rozhranie pre un IX(rozhranie prenosného operačného systému pre Unix). POSIX bol navrhnutý pre operačné systémy podobné UNIX (ich najskoršie verzie pochádzajú zo začiatku sedemdesiatych rokov minulého storočia) s cieľom poskytnúť prenos aplikácií zdrojov.

Prvotný popis rozhrania bol publikovaný v roku 1986, keď sa nazýval IEEE-IX (verzia systému UNIX pre IEEE). Názov sa však rýchlo zmenil, zmenil sa na POSIX a už v ďalšej publikácii (v roku 1986) táto nová verzia určitý čas bol POSIX chápaný ako odkaz (alebo synonymum) na skupinu súvisiacich dokumentov IEEE 1003.1-1988 a častí ISO / IEC 9945 a ako úplnú a schválenú medzinárodnú normu ISO / IEC 9945.1: 1990 bol POSIX prijaté v roku 1990. Špecifikácie POSIX definujú štandardný mechanizmus interakcie medzi aplikačným programom a operačným systémom a v súčasnosti obsahujú viac ako 30 štandardov pod záštitou IEEE, ISO, IEC a ANSI.

POSIX prešiel počas svojej histórie mnohými krokmi a notácie špecifikácií, ich konkrétneho obsahu, postupov a logistiky ich overovania sa mnohokrát menili. Odvtedy bolo vydaných niekoľko vydaní štandardu POSIX v rámci rôznych medzinárodných organizácií.

História vývoja štandardu POSIX

Prvá verzia špecifikácie IEEE Std 1003.1 bola publikovaná v roku 1988. Následne boli ako medzinárodné štandardy prijaté mnohé edície IEEE Std 1003.1.

Fázy vývoja POSIX:

Rok 1990

Edícia vydaná v roku 1988 bola zrevidovaná a stala sa základom pre ďalšie revízie a doplnky. Bol schválený ako medzinárodná norma ISO / IEC 9945-1: 1990.

Rok 1993

Publikované je vydanie 1003.1b-1993.

Rok 1996

Boli vykonané zmeny v normách IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 a 1003.1i-1995, ale väčšina dokumentu zostáva nezmenená. V roku 1996 bola revízia IEEE Std 1003.1 schválená aj ako medzinárodná norma ISO / IEC 9945-1: 1996.

Rok 1998

Objavil sa prvý štandard pre „reálny čas“ - IEEE Std 1003.13-1998. Je to rozšírenie štandardu POSIX pre vstavané aplikácie v reálnom čase.

Rok 1999

Rozhodlo sa vykonať významné zmeny v hlavnom texte normy prvýkrát za posledných 10 rokov, vrátane zlúčenia so štandardom 1003.2 (Shell a verejné služby), pretože v tom čase to už boli samostatné štandardy. PASC sa rozhodol dokončiť zmeny základného textu po dokončení štandardov IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q a 1003.2b.

2004 r.

Najnovšia revízia štandardu 1003.1 bola zverejnená 30. apríla a vydaná pod záštitou skupiny Austin Common Standards Revision Group. Je zmenený a doplnený k vydaniu normy 2001. Vydanie 2004 je vo všeobecnosti známe ako IEEE Std 1003.1, vydanie 2004, Open Group Technical Standard Base Specifications, Issue 6 a zahŕňa IEEE Std 1003.1-2001, IEEE Std 1003.1-2001 / Cor 1-2002 a IEEE Std 1003.1-2001 / Cor 2-2004.

Najdôležitejšie štandardy POSIX pre RT OS

Pre operačné systémy v reálnom čase je najdôležitejších sedem špecifikácií normy (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), ale iba tri získali širokú podporu v komerčných operačných systémoch:

• 1003.1a (definícia OS) definuje hlavné rozhrania OS, riadenie úloh, signály, funkcie súborového systému a prácu so zariadeniami, skupinami používateľov, kanálmi, vyrovnávacími pamäťami FIFO;
• 1003,1b (rozšírenia v reálnom čase) popisuje rozšírenia v reálnom čase, ako sú signály v reálnom čase, prioritné odosielanie, časovače, synchrónne a asynchrónne I / O, semafory, zdieľanú pamäť, správy. Pôvodne (pred rokom 1993) bol tento štandard označovaný ako POSIX.4.
• 1003,1c (vlákna) definuje funkcie podpory vlákna - ovládanie vlákna, atribúty vlákna, mutexy, dispečing. Pôvodne označený ako POSIX.4a.

Okrem týchto štandardov sú pre RT OS dôležité nasledujúce normy, ktoré boli implementované ako súčasť práce na projekte Std 1003.1-2001:

• IEEE 1003.1d-1999.Ďalšie rozšírenia v reálnom čase. Pôvodne označený ako POSIX.4b;
• IEEE 1003.1j-2000. Vylepšené (pokročilé) rozšírenia v reálnom čase;
• IEEE 1003.1q-2000. Sledovanie.

Certifikačný postup

Aby bol operačný systém kompatibilný s POSIX, musí byť certifikovaný podľa príslušnej testovacej sady. Od zavedenia systému POSIX prešiel testovací balík formálnymi a de facto zmenami.

V roku 1991 vyvinul NIST testovací program POSIX podľa FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). Táto možnosť testu bola založená na návrhu normy IEEE 1003.3 „Štandard pre testovacie metódy na meranie zhody s POSIX“, návrh 10, 3. mája 1989. V roku 1993 NIST dokončila testovací program POSIX pre FIPS 151-1 a začala program pre FIPS 151 -2. (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 upravil "Informačné technológie - rozhranie prenosného operačného systému (POSIX) - časť 1: Rozhranie API systému systému (API)", čo je norma ISO / IEC 9945-1: 1990. Testovacie sady pre FIPS 151-2 boli založené na IEEE 2003.1-1992 „Štandard pre testovacie metódy na meranie zhody s POSIX“.

NIST rozlišuje dve certifikačné metodiky: vlastnú certifikáciu a certifikáciu testovacích laboratórií akreditovaných IEEE (Accredited POSIX Testing Laboratories - APTL). V prvom prípade spoločnosť vykonáva testovanie sama, ale podľa plánu schváleného NIST. V druhom prípade testovanie vykonáva nezávislé laboratórium pomocou automatizovaných testovacích balíkov. Celkovo boli akreditované dve laboratória APTL: Mindcraft (www.mindcraft.com) a Perennial (www.peren.com).

V roku 1997 NIST / ITL oznámila svoj zámer ukončiť certifikáciu FIPS 151-2 na konci tohto roku (oficiálne 31. decembra 1997), zatiaľ čo Open Group oznámila, že prevezme kontrolu od 1. októbra toho istého roku. ročná certifikačná služba v súlade s FIPS 151-2, založená na programe NIST / ITL. Rovnaké funkcie prevzala IEEE Standards Association (IEEE-SA) od 1. januára 1998 a tiež na základe FIPS 151-2.

V roku 2003 IEEE-SA a Open Group oznámili nový spoločný certifikačný program pre najnovšie verzie POSIX od IEEE 1003.1 ™ 2001. Open Group má teraz niekoľko testovacích balíkov, ktoré pokrývajú IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 , IEEE Std 1003.1-2003 a IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Výrobok sa považuje za certifikovaný POSIX, ak prešiel úplným certifikačným postupom, podľa výsledkov testov spĺňa všetky požiadavky a je zapísaný v oficiálnom registri certifikovaných výrobkov.

Testovacie sady zahŕňajú:

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm)-sada testov zhody pre systémové rozhrania IEEE Std 1003.1-1990;
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - sada testov zhody pre IEEE Std 1003.13-1998 Profile PSE54 (viacúčelový v reálnom čase);
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm)-sada testov zhody pre systémové rozhrania IEEE Std 1003.1-2003 (iba povinné diely);
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) je sada testov zhody pre IEEE Std 1003.1-2003 (shell a pomocné programy-iba povinné diely).

Open Group okrem toho vyvinula benchmarky pre štandardy POSIX Realtime Standards a Embedded POSIX Standards Profile. POSIX Realtime Test Suite (www.opengroup.org/testing/testsuites/realtime.html) obsahuje nasledujúce testy:

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 rozšírenie v reálnom čase a vydanie IEEE POSIX 1003.1,2003;
• Rozšírenie IEEE Std POSIX 1003.1c-1995 Threads (pthreads) a vydanie IEEE POSIX 1003.1,2003;
• IEEE POSIX 1003.1d-1999 Ďalšie rozšírenie v reálnom čase a IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1j-2000 Advanced Realtime Extension a IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1q-2000 Trace a IEEE POSIX 1003.1,2003 Edition a IEEE POSIX 1003.1,2003 Edition;

Embedded POSIX Standards Profile Test Suite (www.opengroup.org/testing/testsuites/embedded.html) obsahuje nasledujúce testy:

• IEEE POSIX 1003.1-1990 (5310 testov);
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 rozšírenie v reálnom čase (1430 testov);
• Rozšírenie IEEE Std POSIX 1003.1c-1995 Threads (pthreads) (1232 testov);
• IEEE POSIX 1003.13-1998 profil 52.

Trochu o zmätku v terminológii

V súvislosti so skupinou štandardov POSIX anglický jazyk často používa nie jeden, ale až tri výrazy. Bohužiaľ, majú podobný význam a často sú preložené rovnakým spôsobom, čo spôsobuje určité nejasnosti. Tieto podmienky sú nasledujúce:

• kompatibilita (doslova "kompatibilita");
• súlad (doslova - „súlad“);
• zhoda (doslova - „konzistencia“).

Prvý výraz použitý v systéme POSIX nie je formálne definovaný. Druhý znamená, že organizácia - výrobca softvérového produktu nezávisle vyhlasuje, že tento produkt (úplne alebo čiastočne) vyhovuje uvedeným normám NIST -PCTS. Z toho vyplýva tretí termín softvér prešiel zavedeným testovacím systémom buď pomocou akreditovaného laboratória, alebo v rámci otvorenej skupiny a existujú na to listinné dôkazy (takzvané vyhlásenie o zhode). Ďalej v texte článku budú všade citované originály výrazov, aby sa odstránili nejednoznačnosti.

Certifikovaný OS RV

Ak dodržujete prísne pravidlá, ktoré vyžadujú, aby boli údaje o certifikovanom RT OS zverejnené v oficiálnom registri a testovanie prebieha na úrovni zhody, potom v súčasnosti existujú iba dva certifikované RT OS (údaje sú uvedené v chronologickom poradí):

LynxOS v.3(produkt Lynx Real-Time Systems, teraz nazývaný LynuxWorks, Inc., www.lynuxworks.com) je určený na vývoj softvéru pre vstavané systémy pracujúce v reálnom čase, výrobcov OEM a telekomunikačných zariadení, najmä výrobcov palubných systémov. pre vojenské aplikácie ... Vývoj je možné vykonávať na cieľovom systéme (hostiteľskom počítači) aj na inštrumentálnom počítači (hostiteľ), hotový softvér je navrhnutý tak, aby pracoval na cieľovom systéme (cieľovom systéme). LynxOS v.3 je certifikovaná zhoda POSIX na platformách Intel a PowerPC. Informácie o tom nájdete na webovej stránke IEEE na adrese http://standards.ieee.org/regauth/posix/posix2.html. LynxOS je certifikovaný POSIX 1003.1-1996 od spoločnosti Mindcraft, akreditovaného testovacieho laboratória POSIX IEEE POSIX v súprave na testovanie zhody NIST FIPS 151-2. Číslo certifikačného dokumentu: Referenčný súbor: IP-2LYX002, Referenčný súbor: IP-2LYX001.

INTEGRITA v.5(produkt spoločnosti Green Hills Software, www.ghs.com) je certifikovaná podľa POSIX 1003.1-2003, Systémové rozhrania pre architektúru PowerPC v júli 2004 (http://get.posixcertified.ieee.org/select_product. tpl). Testovacia súprava VSX-PCTS 2003.

POSIX a operačný systém QNX

QNX v.4.20 (vyvinutý spoločnosťou QNX Software Systems, www.qnx.com) je certifikovaný podľa POSIX 1003.1-1988 pre platformu Intel od DataFocus Incorporated. Testovanie sa uskutočnilo 13. septembra 1993 a bolo vydané 1. novembra 1993. NIST PCTS 151-1 Test Suite, verzia 1.1.

QNX Neutrino (verzia 6.3) vyhovuje nasledujúcim štandardom rodiny POSIX (www.qnx.com/download/download/8660/portability.pdf):

• POSIX.1 (IEEE 1003.1);
• POSIX.1a (IEEE 1003.1a);
• POSIX.2 (IEEE 1003.2);
• POSIX.4 (IEEE 1003.1b);
• POSIX.4a (IEEE 1003.1c);
• POSIX.1b (IEEE 1003.1d), IEEE 1003.1j;
• POSIX.12 (IEEE 1003,1 g).

QNX Software Systems, tvorca QNX Neutrino, taktiež plánuje súlad QNX Neutrino s niektorými z týchto štandardov; práce sú naplánované na rok 2005 (www.qnx.com/news/pr_959_1.html).

Literatúra

1. Návod na obsluhu asociácie štandardov IEEE. IEEE, október 2004.
2. Kevin M. Obeland. POSIX v reálnom čase, programovanie vstavaných systémov, 2001.
3. IEEE / ANSI Standard 1003.1: Information Technology - (POSIX) - Part1: System Application: Program Interface (API).
4. Gallmeister, B. O. Programovanie pre skutočný svet, POSIX.4 Sebastopol, CA: O'Reilly & Associates, 1995.
5. Národný inštitút pre štandardy a technológie, PCTS: 151-2, POSIX Test Suite.
6. POSIX: Certifikovaný IEEE a The Open Group. Certifikovaná politika. Otvorená skupina, 21. októbra 2003, revízia 1.1.

Alexej Fedorčuk
Rok 2005

Jednou z charakteristických vlastností logickej štruktúry súborového systému operačných systémov rodiny POSIX je ich hierarchická alebo stromová organizácia (ako som však povedal, strom vyzerá trochu divne). To znamená, že ako v systéme DOS alebo Windows akéhokoľvek druhu, neexistuje žiadne označenie (napríklad abecedné alebo akékoľvek iné) pre jednotlivé médiá a ich oddiely: všetky sú zahrnuté v jednej štruktúre ako podadresáre hlavného adresára. nazývaný koreň. Proces pripojenia súborové systémy na nezávislých fyzických médiách (a ich oddieloch) do koreňa stromu súborov sa nazýva mount a podadresáre, ktoré obsahujú, sa nazývajú body pripojenia.

Historicky Unix vyvinul špecifickú adresárovú štruktúru, ktorá je v celej rodine veľmi podobná, ale v detailoch sa mierne líši. Najmä hierarchia súborov v systémoch BSD je takmer rovnaká, ale líši sa od hierarchie v systéme Linux. A v druhom prípade sú medzi rôznymi distribúciami nájdené významné rozdiely. Do tej miery, že štruktúra hierarchie súborov je jednou z vlastností špecifických pre distribúciu.

Tento stav vecí sťažuje vytváranie aplikácií pre rôzne platformy. Preto existuje a aktívne sa vyvíja projekt na štandardizáciu hierarchie súborov - FHS (Filesystem Hierarchy Standard).

FHS bol pôvodne zameraný na zefektívnenie adresárovej štruktúry mnohých distribúcií Linuxu. Neskôr bol upravený pre ostatných Unixové systémy(vrátane klanu BSD). A teraz existujú aktívne (ale nie veľmi úspešné) snahy, aby sa stal štandardom pre systémy POSIX, a to nielen názvom, ale aj faktom.

Štandard FHS spočíva na dvoch základných princípoch - jasnom oddelení v hierarchii súborov adresárov, ktoré sú zdieľané a nezdieľané na jednej strane a nemenné a meniteľné na strane druhej.

Kontrast medzi zdieľanými a nezdieľanými adresármi je spôsobený inherentnou sieťovou povahou Unixu. To znamená, že údaje súvisiace s lokálnym počítačom (napríklad konfiguračné súbory pre jeho zariadenia) by mali byť umiestnené v adresároch oddelene od tých, ktorých obsah je dostupný z iných počítačov v sieti, lokálnych alebo globálnych (ktorých príkladom je nielen používateľ dáta, ale aj programy) ...

Podstatu opozície medzi nemennými a premennými adresármi je ľahké vysvetliť na príklade. Rovnaké všeobecné užívateľské programy by preto mali byť svojou povahou nemenné (alebo skôr dostupné na úpravu iba správcovi systému, ale nie samotnému používateľovi, ktorý ich používa vo svojej práci). Tieto programy zároveň počas svojej práce generujú nielen dátové súbory, povedzme, texty alebo obrázky (ich variabilná povaha je jasná bez komentárov), ale všetky druhy servisných informácií, ako sú súbory denníka, dočasné súbory a podobne) . Ktoré by mali byť zoskupené v adresároch oddelených od skutočných spustiteľných programových súborov potrebných na ich spustenie, knižníc, konfiguračných súborov atď.

Napriek aktívnej propagácii v mnohých distribúciách Linuxu z najbežnejších FHS nezískal status skutočného štandardu. Existuje pomerne málo distribúcií Linuxu, ktoré nepoužívajú niektoré z jeho ustanovení. A len čiastočne koreluje s tradičnou hierarchiou súborov systémov BSD.

Dôvodom je, že FHS ignoruje ešte jednu opozíciu, ktorá je pre používateľa veľmi dôležitá: opozícia ľahko obnoviteľných častí systému súborov a tých jeho komponentov, ktoré je ťažké obnoviť alebo nie je možné ich obnoviť.

Prvý, napodiv, možno pripísať samotnému základnému systému: jeho opätovné nainštalovanie z distribučného média v prípade smrteľného zlyhania nie je také ťažké. Ťažko obnoviteľné časti systému súborov očividne obsahujú údaje o používateľoch: aj keď sú pravidelne zálohované (a koľko používateľov je tak opatrných?), Ich zavedenie z archívov bude trvať veľa času (a takmer nevyhnutne) spôsobiť určité straty).

Okrem toho by som v systémoch BSD a distribúciách Linuxu založených na zdrojoch klasifikoval všetko, čo súvisí so správou balíkov, ako ťažko obnoviteľné adresáre-strom portov FreeBSD alebo pkgsrc v NetBSD (a systémoch, ktoré si ho požičali), ich obdoby v distribúciách Linuxu, skutočné zdroje prenesených programov a zdrojový kód systému tiež. Pretože aj keď je to všetko na distribučnej súprave, tieto súčasti súborového systému spravidla používateľ aktualizuje synchronizáciou prostredníctvom siete so servermi projektu (inak ich použitie nemá zmysel). A ich strata bude mať za následok dočasné (najmä s modemovým pripojením) a finančné (len málo ľudí je šťastnými vlastníkmi bezplatného prístupu na internet) straty.

Prísne dodržiavanie konceptu vzájomného oddeľovania zdieľaných a nezdieľaných, nemenných a nemenných, obnoviteľných a neobnoviteľných adresárov umožňuje v rámci jednej stromovej hierarchie súborov fyzicky oddeliť jednotlivé vetvy-tj. nezávislých súborových systémov umiestnených na izolovaných zariadeniach (disky, sekcie diskov, rezy, oddiely atď.). Existuje mnoho dôvodov - zvýšenie výkonu a spoľahlivosť a jednoduché aspekty pohodlia - ale teraz o nich nebudeme hovoriť. Pretože v tento moment záleží nám na tom, aby tieto vetvy stromu súborov boli začlenené do spoločného systému súborov.

Typická sada adresárov systému POSIX

V skutočnosti je na fungovanie úplne nevyhnutný iba jeden súborový systém - ten, ktorý je namontovaný v koreňovom adresári stromu súborov (akýsi analóg svetového stromu Yggdrassil). Koreňový adresár a jeho nepostrádateľné vetvy musia predstavovať jeden súborový systém umiestnený na jednom médiu - disku, diskovej oblasti, softvérovom alebo hardvérovom poli RAID alebo logickom zväzku v chápaní LVM. A mal by obsahovať všetky komponenty potrebné na spustenie systému a v ideálnom prípade nič viac.

Zloženie koreňového adresára môžete zobraziť pomocou príkazu

$ ls -1 /

ktorý v každom systéme POSIX zobrazí minimálnu gentlemanskú množinu adresárov:

Kôš / boot / etc / root / sbin /

Práve v nich sa zhromažďujú všetky súbory, bez ktorých systém nemôže existovať. Ostatné adresáre sú podobné tomuto:

Domov / mnt / opt / tmp / usr / var /

Nie sú a) požadované (prinajmenšom teoreticky - je prakticky nemožné ich zvládnuť), b) nie každý z nich je prítomný vo všetkých systémoch a distribúciách a c) každý z nich môže byť (a často je - ak robíte všetko podľa svojho rozumu) bod pripojenia vlastnej vetvy stromu súborov.

Okrem toho vo väčšine prípadov existujú ďalšie dva podadresáre v koreňovom adresári súborového systému OS kompatibilných s POSIX:

Vývojár / proc /

Spravidla ide o body pripojenia virtuálnych súborových systémov - zariadenia a procesy (aj keď, ak sa súborový systém zariadení nepoužíva, adresár / dev musí byť súčasťou koreňového systému súborov. Nakoniec v systémoch Linux, ako spravidla je koreň stromu súborov a adresár / lib pre hlavné systémové knižnice a pri udev je nevyhnutný adresár / sys aj tam, kde je pripojený virtuálny súborový systém sysfs.

Koreňový súborový systém

Koreňový súborový systém nie je zdieľateľný (to znamená, že nie je určený na zdieľanie rôznymi počítačmi v sieti) a je nemenný (to znamená, že zmeny v ňom môže vykonávať iba správca systému, nie však užívateľské programy a navyše nie používatelia). Okrem toho sa dôrazne neodporúča vytvárať v ňom podadresáre nad rámec tých, ktoré poskytuje štandard (a sú uvedené vyššie).

Vyplnenie koreňového systému súborov je zvolené tak, aby počítač mohol štartovať a zachovať si minimálnu funkčnosť aj počas núdzového spustenia (alebo v režime pre jedného používateľa), keď nie sú pripojené všetky ostatné systémy súborov (a podľa toho jeho vetvy, ako napr. / usr alebo / var nemusí byť k dispozícii.

V súlade s tým je štart počítača zabezpečený súbormi adresárov / boot a / atď. Prvá obsahuje jadro systému - spustiteľný súbor „na špeciálne účely“ - a všetko, čo je potrebné na jeho načítanie - v systéme Linux, napríklad mapu systému (/etc/System.map), a vo FreeBSD - načítateľné jadro moduly. Niekedy sa však jadro nachádza priamo v koreňovom adresári súborového systému a potom priečinok / boot nemusí vôbec chýbať a adresár / modules môže byť vyhradený pre moduly jadra.

Adresár / etc je pre konfiguračné súbory celého systému, ktoré určujú podmienky jeho načítania. Jeho obsah veľmi závisí od systému (a v Linuxe - tiež od distribučnej súpravy), a preto ho tu nebudem zvažovať - ​​k tejto téme sa budem musieť vrátiť viackrát.

Minimálnu potrebnú funkčnosť poskytuje obsah adresárov / bin a / sbin - obsahujú spustiteľné súbory najdôležitejších používateľských a systémových programov, respektíve tie, ktoré vám umožnia vykonať komplex opatrení na opravu a záchranu a po poruche vrátiť auto do ľudskej podoby.

Rozdelenie systémových a užívateľských programov na koreňové podadresáre je dosť ľubovoľné. Žiadny z týchto príkazov nie je skutočne určený na riešenie problémov používateľov. Ide len o to, že adresár / bin obsahuje administračné príkazy, ku ktorým z času na čas pristupuje (alebo k nim má prístup) bežný používateľ, a adresár sbin je určený pre príkazy, o ktorých by užívateľ nemal vedieť. A ktoré vo väčšine prípadov stále nebude môcť používať z dôvodu nedostatku príslušných právomocí (napríklad požadovaných prístupových práv k súborom zariadenia).

Na spustenie programov POSIX (vrátane tých, ktoré sú kompilované v adresároch / bin a sbin), spravidla potrebujete prístup k funkciám knižníc celého systému (predovšetkým k hlavnej knižnici glibc). A preto (takmer) nepostrádateľnou súčasťou koreňového adresára je podadresár / lib, v ktorom sú zostavené.

V systéme Linux slúži adresár / lib na ďalší dôležitý účel - jeho podadresár ( / lib / modules) obsahuje moduly jadra, ktoré je možné načítať (vo FreeBSD je ich miesto / boot / kernel).

Vo FreeBSD sa adresár / lib nenachádza v koreňovom súborovom systéme - zodpovedajúce komponenty sú umiestnené tu v / usr / lib (pozri nižšie). Dôvodom je to, že FreeBSD historicky vybudoval hlavné programy celého systému, takže funkcie knižníc, ktoré požadujú, sú vložené do ich spustiteľných súborov (nazýva sa to statické prepojenie, o ktorom sa bude diskutovať v kapitole 14). Vo FreeBSD sú 5. vetvové programy z adresárov / bin a / sbin dynamicky prepojené, to znamená, že v prípade absencie adresára / usr (a vo Free je takmer vždy samostatnou vetvou súborového systému) nefungujú. Na kompenzáciu tohto problému existuje adresár / restore, ktorý presahuje štandardy a obsahuje rovnaké programy, ale je staticky prepojený (ako naznačuje názov adresára, jediným účelom jeho obsahu sú záchranné operácie).

Nakoniec / root. Toto je obvyklý domovský adresár používateľa s rovnakým menom, to znamená správcu systému. Pretože nevykonáva žiadnu praktickú prácu (alebo by aspoň nemal), jeho obsahom sú iba vlastné konfiguračné súbory superužívateľa (príkazový shell používateľa, obľúbený editor a podobne).

Pobočka / usr

Historicky bol adresár / usr určený pre užívateľské programy a údaje. Tieto funkcie sú teraz rozdelené medzi / usr / local a / home (aj keď toto je teraz predvolene vo FreeBSD symbolický odkaz na / usr / home). Adresár / usr - nemeniteľný, ale zdieľaný - slúži ako úložisko pre väčšinu aplikačných programov a všetkého, čo s nimi súvisí - zdrojový kód, konfiguračné súbory, zdieľané knižnice, dokumentáciu a podobne.

Zloženie adresára / usr sa medzi systémami BSD a Linux výrazne líši. V prvom prípade obsahuje iba integrálne časti operačného systému (ten, ktorý vo FreeBSD spája koncept distribúcií). Aplikácie nainštalované z portov alebo balíkov majú svoje miesto v podadresári / usr / local, ktorý môže predstavovať samostatnú vetvu stromu súborov.

V systéme Linux slúži adresár / usr ako úložisko pre všetky programy (a ich súčasti) zahrnuté v distribučnej súprave. Podadresár / usr / local je zvyčajne určený pre programy, ktoré sú nezávisle skompilované zo zdroja.

V každom prípade je obvyklé zloženie adresára / usr nasledovné (ako uvádza príkaz ls -1):

X11R6 / bin / etc / include / lib / libexec / local / sbin / share / src /

Ako už bolo spomenuté, podadresár / usr / local je samostatnou vetvou stromu súborov, a preto bude posudzovaný oddelene. Účel ostatných adresárov je nasledujúci:

• / usr / bin a / usr / sbin sú určené pre spustiteľné súbory používateľských a systémových programov (tu je hranica medzi nimi ešte ľubovoľnejšia než v prípade koreňového adresára), ktorých účel presahuje zabezpečenie základného fungovania systém;
• / usr / etc je pre konfiguračné súbory jednotlivých aplikácií;
• / usr / include obsahuje takzvané hlavičkové súbory potrebné na prepojenie spustiteľné súbory s knižničnými komponentmi;
• / usr / lib a / usr / libexec sú adresáre pre zdieľané knižnice, od ktorých závisia užívateľské aplikácie;
• / usr / share - úložisko najrozmanitejších, tzv. architektonicky nezávislé komponenty: tu môžete vidieť dokumentáciu v rôznych formátoch, príklady konfiguračných súborov a údaje používané programami na správu konzoly (písma, rozloženia klávesnice) a popis časových pásiem;
• / usr / src - adresár zdrojového kódu; v Linuxe je tu zvyčajne umiestnený iba zdrojový kód jadra (jadier) systému, v klonoch BSD - úplná sada zdrojových kódov komplexu, ktorý sa vo FreeBSD nazýva Distribúcie; spravidla je nežiaduce umiestňovať sem zdroje programov zostavených samostatne;
• / usr / X11R6 - adresár pre komponenty systému Windows X - spustiteľné súbory ( / usr / X11R6 / bin), knižnice ( / usr / X11R6 / lib), hlavičky ( / usr / X11R6 / include), dokumentácia ( / usr / X11R6 / muž); Nemali by ste sem umiestňovať súbory X aplikácií (snáď okrem správcov okien) - ich miesto je v / usr, / usr / local alebo / opt, v závislosti od systému.

Adresár / usr môže navyše obsahovať podadresáre / usr / var a / usr / tmp - spravidla symbolické odkazy na zodpovedajúce vetvy koreňového adresára. A pri niektorých distribúciách Linuxu je hlavná dokumentácia celého systému, manuálové stránky (v podadresári / usr / man), umiestnená priamo v adresári / usr.

Nakoniec v systémoch BSD a niektorých distribúciách Linuxu založených na zdrojoch (napríklad Gentoo) obsahuje adresár / usr podadresár pre systém správy balíkov - porty FreeBSD a OpenBSD ( / usr / porty), ich obdoby v iných systémoch ( / usr / portage v Gentoo). Aj keď z hľadiska dodržiavania litery a ducha štandardu FHS (on sám neuvádza ani slovo o portoch a podobných systémoch), logickejším miestom na ich umiestnenie by bol adresár / var (pozri nižšie) - a presne to sa robí v distribúciách ako CRUX a Archlinux.

Pobočka / usr / miestna

Ako už bolo spomenuté, lokálna vetva / usr / v Linuxe je určená pre programy, ktoré si sami kompilujete zo zdrojov (nie sú súčasťou tejto distribučnej sady). A na FreeBSD slúži ako úložisko pre väčšinu aplikácií používateľa - takmer všetko mimo Distribúcií a nainštalované z balíkov alebo portov. Štruktúra adresárov ako celok teda zodpovedá štruktúre vetvy / usr (s pochopiteľnými výnimkami):

Kôš / etc / include / lib / man / sbin / share /

Obsah podadresárov je tiež podobný: spustiteľné súbory programu ( / usr / local / bin a / usr / local / sbin), ich konfigurácie ( / usr / local / atď.), Knižnice, s ktorými sú prepojené, a ich hlavičkové súbory ( / usr / local / lib a / usr / local / include, v uvedenom poradí), manuálové stránky ( / usr / local / man) a všetky druhy vecí nezávislých na architektúre ( / usr / local / share), vrátane dokumentácie v iných formátoch.

/ Opt pobočka

Adresár / opt je poskytovaný štandardom FHS, ale v skutočnosti sa nepoužíva vo všetkých distribúciách Linuxu a v systémoch BSD úplne chýba. Napriek tomu je stále viac programov napísaných s očakávaním predvolenej inštalácie.

Historicky sa / opt používal v Linuxe na komerčné aplikácie a všetky druhy nie úplne bezplatného softvéru. Teraz je jeho účelom hostenie veľkých samostatných softvérových systémov, ako je knižnica Qt, KDE so všetkými komponentmi a aplikáciami, OpenOffice.org a podobne. Štruktúra adresárov by mala byť / opt / pkg_name. Takto to vyzerá v mojom systéme (Archlinux):

$ ls -1 / opt gnome / kde / OpenOffice.org1.1.2 / qt /

Každý z podadresárov má svoju vlastnú vnútornú štruktúru:

$ ls -1 / opt / * / opt / gnome: bin / lib / man / share / / opt / kde: bin / etc / include / lib / share / /opt/OpenOffice.org1.1.2: help / LICENSE LICENSE. html program / README README.html [chránené e -mailom] zdieľam / [chránené e -mailom] THIRDPARTYLICENSEREADME.html užívateľ / / opt / qt: bin / doc / include / lib / mkspecs / frázy / pluginy / šablóny / preklady /

Účel podadresárov vo vnútri / opt / pkg_name je možné uhádnuť analogicky s / usr a / usr / local. Napríklad / opt / kde / bin je pre spustiteľné súbory systému KDE a jeho aplikácií, / opt / kde / etc je pre jeho konfiguračné súbory, / opt / kde / include je pre hlavičkové súbory, / opt / kde / lib je pre knižnice a / opt / kde / share - pre zdieľané súbory vrátane dokumentácie. V KDE neexistuje žiadna dokumentácia vo formáte man, ak je, potom (ako v prípade Gnome - neinštaloval som to, do toho sa vtiahol Gimp a podobné aplikácie Gtk) môžete vidieť / opt / pkg_name / podadresár muž.

Môžete vidieť, že adresárová štruktúra / opt sa líši od historicky založenej (a vnútorne odôvodnenej tradície POSIXu kombinovania komponentov rovnakého typu do adresárov - spustiteľných súborov, knižníc atď.) A keďže je v ňom nainštalovaný veľký počet programov, spôsobuje určité ťažkosti: buď musíte preťažiť premennú $ PATH, ktorá poskytuje rýchly prístup k príkazom (o ktorej sa bude diskutovať v kapitole 12), alebo vytvorte špeciálny adresár / opt / bin a vložte do neho symbolické odkazy na spustiteľné binárne súbory programu. , v niektorých distribúciách Linuxu (napríklad v CRUX) / opt sa v zásade nepoužíva. Ako v skutočnosti vo všetkých systémoch BSD. Je celkom možné, že je to takto lepšie ...

/ Pobočka Var

Ako naznačuje názov, adresár / var je určený na ukladanie premenlivých súborov generovaných počas normálneho života rôznych programov - medzipamäte softvéru (napríklad prehliadača), súbory denníka, spoolovanie tlače a poštové systémy. schránky, popisy spustených procesov a pod. Najmä do adresára / var sú umiestnené takzvané skládky - snímky stavu pamäte RAM generované počas núdzového vypnutia na identifikáciu dôvodov. Charakteristickou črtou všetkých týchto komponentov je ich premenlivá povaha počas práce a skutočnosť, že napriek tomu musia byť zachované pri reštarte systému.

Vnútorná štruktúra / var sa veľmi líši od systému k systému, a preto sa nebudem zaoberať podrobnosťami o jeho štruktúre. Poznamenám len, že tento adresár je logickým miestom na umiestnenie komponentov všetkých druhov portových systémov na správu balíkov, ako sa to robí napríklad v distribúcii Archlinux, kde je podadresár / var / abs (abs - Archlinux Building System ) je na to vyhradené.

Adresár / mnt

Adresár / mnt je určený na pripojenie dočasne používaných súborových systémov, ktoré sa zvyčajne nachádzajú na vymeniteľné médiá... V zavedenom systéme je zvyčajne prázdny a jeho štruktúra nie je nijako regulovaná. Užívateľ môže v ňom voľne vytvárať podadresáre pre určité typy médií. V mojom systéme sú to napríklad / mnt / cd, / mnt / dvd, / mnt / usb a / mnt / hd - pre disky CD, DVD, flash disky a vymeniteľné pevné disky.

Vo FreeBSD sú predvolenými adresármi na pripojenie diskov CD a diskiet / cdrom a / floppy priamo v koreňovom adresári. Čo nie je celkom v súlade so štandardom, ale svojím spôsobom je to logické - body pripojenia zariadení, ktoré existujú (napríklad CD ROM) alebo ešte nedávno existovali (disketová mechanika) na akomkoľvek počítači, sú prevzaté z koreňa.

/ Domáca pobočka

Adresár / home je na hosťovanie domácich adresárov používateľov. Jeho obsah nie je nijako regulovaný, ale zvyčajne vyzerá ako /home/(username1,...,username#). Vo veľkých systémoch s veľkým počtom používateľov však môžu byť ich domovské adresáre zoskupené.

Adresár / home môže obsahovať domovské adresáre nielen skutočných používateľov, ale aj niektorých virtuálnych používateľov. Ak sa teda počítač používa ako webový server alebo server ftp, zobrazia sa podadresáre ako / home / www alebo / home / ftp.

Vetva / tmp

Zostáva hovoriť iba o adresári na ukladanie dočasných súborov - / tmp. Rovnako ako / var komponenty sú generované rôznymi programami počas ich normálneho života. Na rozdiel od súborov / var, / tmp sa však neočakáva, že budú uložené mimo aktuálnej relácie. Všetky príručky správy systému navyše odporúčajú pravidelne (napríklad pri reštartovaní počítača) alebo pravidelne mazať tento adresár. Preto je ako / tmp vhodné pripojiť súborové systémy do pamäte RAM - tmpfs (v Linuxe) alebo mfs (vo FreeBSD). Okrem toho, že to zaisťuje vymazanie jeho obsahu po reštarte, prispieva to aj k výkonu, napríklad pri kompilácii programov, ktorých dočasné produkty nie sú zapísané na disk, ale sú umiestnené vo virtuálnom adresári ako / tmp / obj.

Na mnohých systémoch uvidíte adresáre ako / usr / tmp a / var / tmp. Spravidla ide o symbolické odkazy na súbor / tmp.

Stratégia rozdeľovania súborov v systéme súborov

Na záver rozhovoru o hierarchii súborov je potrebné zdôrazniť, že iba adresáre uvedené v odseku Koreňový súborový systém... Všetky ostatné adresáre - / usr, / opt, / var, / tmp a samozrejme / home môžu predstavovať body pripojenia nezávislých súborových systémov na samostatných fyzických médiách alebo ich oddieloch.

Navyše v lokálna sieť tieto adresáre môžu byť dokonca umiestnené aj na rôznych počítačoch. Jeden počítač fungujúci ako aplikačný server môže napríklad obsahovať adresáre / usr a / opt v sieti, iný súborový server, ktorý môže obsahovať všetky domovské adresáre používateľa a podobne.

Zostáva len rozhodnúť, ktoré súborové systémy je vhodné izolovať od spoločného stromu súborov a prečo to urobiť. Odpoveď na tieto otázky veľmi závisí od použitého OS a v prípade Linuxu aj od jeho distribúcie. Napriek tomu je možné načrtnúť všeobecné zásady oddelenia súborových systémov. Prečo by sme si mali pamätať na opozíciu na jednej strane nemenných a premenlivých adresárov na strane druhej na ľahko obnoviteľné, ťažko obnoviteľné a prakticky neobnoviteľné údaje. Urobme tento pokus vo vzťahu k užívateľskej ploche - v prípade servera sa výpočty výrazne líšia.

Koreňový súborový systém v adresároch / bin, / boot, / etc, / root, / sbin obsahujúci ľahko obnoviteľné údaje z distribučného média a prakticky nezmenené údaje by mal byť umiestnený na izolovanom oddiele disku. V systéme Linux by mal byť tiež pridaný adresár / lib. Na druhej strane, keď používate GRUB ako zavádzač (bez ohľadu na operačný systém), odporúča sa presunúť priečinok / boot do samostatného oddielu.

V starých zdrojoch o Linuxe si môžete prečítať o inom dôvode pridelenia oddielu pre adresár / boot a na úplnom začiatku disku: kvôli nemožnosti načítať jadro Lilo z čísla valca vyššieho ako 1023. V moderné verzie zavádzačov, neexistujú žiadne také obmedzenia. Ak však vytvárate oddiel pre / boot, má zmysel vytvoriť z neho prvý na disku a odkladací oddiel umiestniť priamo za neho: tým sa rýchlosť pri výmene zvýši o päť kopejiek.

A tiež z oblasti histórie: Požiadavka, aby koreňové a zavádzacie oddiely boli v každom prípade primárne, bola tiež dávno odstránená. A tieto systémy súborov sa môžu hodiť na logické oddiely v rámci rozšíreného oddielu.

Rovnako je zrejmé, že premenlivé vetvy systému súborov - / var a / tmp - je potrebné presunúť mimo koreňový oddiel. Navyše, ako už bolo mnohokrát povedané, je všeobecne vhodné umiestniť ho na súborový systém v pamäti RAM (tmpfs alebo mfs). V prípade, že adresár / var obsahuje podadresáre pre systémy správy balíkov podobné portom, ako sú / var / abs, / var / cache / pacman / src a / var / cache / pacman / pkg v Archlinuxe, mali by tiež vytvoriť vlastný súbor systémy.

Teraz adresár / usr, ktorý obsahuje buď komponenty základného systému (ako v BSD), alebo väčšinu používateľských aplikácií (ako vo väčšine distribúcií Linuxu). Obsahuje ľahko obnoviteľné údaje a z dobrého dôvodu by mal byť prakticky nemeniteľný, a preto si, samozrejme, zaslúži zdôraznenie v nezávislej sekcii. Okrem toho je vhodné izolovať od jeho zloženia na jednej strane podadresáre / usr / X11R6 a / usr / local, na druhej strane podadresáre pre systémy správy balíkov podobné portom: / usr / porty, / usr / pkgsrc a / usr / pkg v systémoch BSD., / usr / portuje na Gentoo Linux a podobne. Navyše by mali byť oddelené podadresáre na umiestnenie zdrojov stiahnutých zo siete pri vytváraní portov - / usr / porty / distfiles, / usr / pkgsrc / disfiles, / usr / portages / distfiles a podobne.

V systémoch BSD má okrem toho zmysel oddeliť z adresára / usr podadresáre / usr / src a / usr / obj, ktoré obsahujú zdroje základných komponentov (vrátane jadra) a ich kompilačné medziprodukty, ktoré sú generované svetmi make buildworld a make buildkernel ....

Nakoniec adresár / home, ktorý obsahuje prchavé a často neobnoviteľné údaje, musí byť bez problémov odstránený z koreňa hierarchie súborov. A vždy sa to snažím umiestniť buď na samostatný plátok (v BSD), alebo na primárny oddiel (v Linuxe).

Navrhovaná schéma rozdelenia súborov na systém súborov sa môže zdať príliš komplikovaná. Poskytuje však záruku izolácie medzi ľahko obnoviteľnými, ťažko obnoviteľnými a neobnoviteľnými údajmi, čo uľahčuje preinštalovanie systému v prípade núdze a dokonca aj migráciu zo systému na systém.

Jeho ďalšou výhodou je, že pre jednotlivé vetvy stromu súborov si v Linuxe v závislosti od povahy údajov, ktoré sa na ňom nachádzajú, môžete vybrať fyzicky optimálny súborový systém. Napríklad pre oddiel pod / boot nemá zmysel používať nič iné ako Ext2fs. Spravidla sa odporúča naformátovať koreňový oddiel pomocou bezpečného a napriek tomu najkompatibilnejšieho Ext3fs. Pre adresáre s veľkým počtom malých súborov, ako sú / var / abs v Archlinuxe, / usr / portages v Gentoo, je vhodné použiť ReiserFS: šikovná manipulácia s malými súbormi je predsa jeho profilom. A v adresári / home, kde sa môžu objaviť obrovské multimediálne súbory (a ktoré sú samy o sebe zvyčajne veľmi veľké), môže XFS prísť na súd (aj keď, ako ukazujú merania, ReiserFS tu vyzerá celkom slušne). Takéto opatrenia môžu zvýšiť spoľahlivosť ukladania údajov a rýchlosť operácií so súbormi.

Používatelia operačných systémov BSD sú viazaní na súborové systémy FFS bez akejkoľvek alternatívy. Majú však aj manévrovací priestor. Po prvé, zmenou veľkosti bloku a fragmentu jednotlivých súborových systémov, čo prispieva buď k výkonu operácií na disku, alebo k úspore miesta na disku. A za druhé, niektoré vetvy stromu súborov (ako / tmp alebo / usr / obj, na rozdiel od odporúčaní, je možné nebojácne namontovať v čisto asynchrónnom režime a získať tak percentuálny alebo iný výkon.

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) spočiatku nemajú zmysel, pretož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.

Tomuto názoru by sa asi nemalo venovať pozornosť, ak nie za dvoch okolností:

(1) vyjadrujú to odborníci z praxe, to znamená presne tí, ktorí „vydávajú softvér“;

(2) Vyššie uvedené úvahy objavil autor tohto článku v jednej z publikácií na internete venovaných štandardu pre programovací jazyk C, z ktorých vysvitlo, že takýto názor je rozšírený „v medzinárodnom meradle“, a nielen medzi arogantných ruských „super programátorov“.

Slovo „štandard“ je zvyčajne spojené s niečím materiálnym (štandardné rozmery, štandardné elektrické napätie atď.), Zatiaľ čo počítačový program je nehmotným predmetom („nový nehmotný“) a možno sú štandardy v nehmotnej sfére skutočne bezvýznamné?

Existuje však vyvracajúci príklad. Súbor pravidiel pravopisu ruského jazyka je v zásade štandardom, aj keď nie je schválený normalizačnými orgánmi. Okrem pravidiel (alebo, ak chcete, požiadaviek) pravopisu existujú aj syntaktické pravidlá a čo je najdôležitejšie, sémantika. Ten dobre ilustruje „detskú“ otázku: prečo sa mačka nazýva mačka? Na túto otázku existuje presná odpoveď: pretože naši predkovia s tým súhlasili; predkovia Britov súhlasili s nazývaním tej istej šelmy, predkovia Nemcov - mačiatka atď. A vo všeobecnosti je význam alebo sémantika alebo pravidlá výkladu akéhokoľvek slova alebo kombinácie slov vecou dohody.

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

Ako naznačuje názov, POSIX (Portable Operating System Interface) je štandardom rozhrania (rozhrania) medzi operačným systémom a aplikačným programom. Časy, keď programátori písali programy pre „holý“ stroj (implementácia vlastných balíkov vstupno / výstupných programov, goniometrické funkcie atď.) Sú nenávratne preč. Text POSIX opakovane zdôrazňuje, že norma nekladie žiadne požiadavky na podrobnosti implementácie operačného systému; je možné ho považovať za súbor dohôd medzi programátormi aplikácií 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 minulého storočia, keď sa rozšírili operačné systémy UNIX. 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 nemožno vždy vykonávať v inom systéme. Práve na tento problém, známy ako problém s prenosnosťou softvéru, sa chce POSIX zamerať. Prvé vydanie štandardu bolo vydané v roku 1988 (existuje preklad, pozri), v ktorom boli všetky rôzne problémy súvisiace s prenosnosťou programu rozdelené na dve časti: (1) rozhranie aplikačného programu, (2) interpret príkazov a pomocné programy (užívateľské rozhranie); tieto časti sa nazývajú POSIX.1 a POSIX.2.

Vysvetlíme, že v tomto článku budeme hovoriť iba o štandarde pre rozhranie 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. POSIX tiež nemôže slúžiť ako sprievodca resp študijná príručka o operačných systémoch, aj keď informatívna časť obsahuje odporúčania pre programátorov a fragmenty programu.

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

O sémantike

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

Ako sprostredkovať význam v preklade

V prvom rade je potrebné pripomenúť, že štandard POSIX je napísaný v angličtine, čo zo svojej podstaty vyvoláva nejednoznačnosť (napríklad to isté slovo môže byť podstatné meno, prídavné meno a sloveso) a „sémantické pasce“ číhajú na takmer každá stránka. Dobrou ilustráciou je príklad z beletrie. Jedno z najznámejších diel Oscara Wilda, ktorý túto funkciu bravúrne využil anglického jazyka, - Dôležitosť byť Earnest - v ruštine známy ako „Dôležitosť byť Earnest“. ale anglické meno má druhý význam: Earnest (vážny) je meno jednej z postáv a meno by sa dalo preložiť inak: „Ako dôležité je byť Ernstom.“ Existuje ruské priezvisko Serebryany a keby existovalo priezvisko Vážny, preklad by bol úplne presný s prenosom oboch významov.

Podobná je situácia aj so samotným názvom štandardu: Rozhranie prenosného operačného systému. Prívlastok prenosný (mobilný) sa týka operačného systému aj aplikačného programu, ale v ruštine sa nedá vyjadriť tak krátko, 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 štandardu, ale zároveň sa stráca prvý význam (počas prekladu bola zachovaná známejšia prvá možnosť).

Sémantika slova „štandard“

Hlavnému textu normy predchádza preambula, ktorá vysvetľuje význam slov IEEE Standards2. Ako vyplýva z týchto vysvetlení, od ruského výrazu GOST existujú najmenej tri sémantické rozdiely:

(1) Intuitívne sa verí, ž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 platí, kým nie je zrušený (mnohí pravdepodobne už počuli výraz „GOST nebol zrušený“); preambula POSIX hovorí, že ak norma nebola revidovaná 5 rokov, znamená to, že problémy v nej diskutované pravdepodobne stratia svoj význam a je možné ich považovať za zrušené automaticky;

(3) GOST je anonymný; úvodná časť POSIX poskytuje zoznam tých, ktorí sa podieľali na vývoji tohto štandardu, a tiež uvádza adresu, na ktorú je možné zasielať žiadosti o tlmočenie; taktiež sa v ňom uvádza, že odpoveď na každú žiadosť podlieha schvaľovaciemu postupu (inými slovami, autori normy sa pred poskytnutím odpovede dohodnú).

Preklad dokonca tak známeho slova ako štandardu slovom „štandard“ si vyžaduje komentár.

Sémantika slov „by mala“, „nie je špecifikovaná“, „nie je definovaná“, „je definovaná implementácia“

Oddiel 2 normy sa nazýva Terminológia a všeobecné požiadavky. Obsahuje definície nielen špeciálnych termínov (ako „proces“ alebo „semafor“), ale aj také zdanlivo samozrejmé slová ako „by mal“ alebo „môže“. Pretože POSIX.1 je štandardom rozhrania, jeho požiadavky platia pre operačný systém aj pre aplikačný program. Výslovnú požiadavku vyjadruje slovo „musí“, napríklad: „V prípade úspechu musí funkcia link () vrátiť nulu.“ V tomto prípade hovoríme o požiadavke operačného systému: funkcia link () musí byť implementovaná tak, aby pri úspechu vrátila nulu.

Výrazy „nešpecifikované“ a „nedefinované“ vyjadrujú rovnakú myšlienku, že štandard umožňuje slobodu voľby, ale význam týchto pojmov je odlišný. Pojem „nešpecifikovaný“ znamená, že hovoríme o niektorých správnych (akcie, konštrukcie programu atď.) A výraz „nedefinované“ - o nesprávnych (chybných). Informačná časť normy poskytuje nasledujúce vysvetlenie.

Pojem „nešpecifikovaný“ znamená, že sa predpokladá, že je známych veľa možností (výstupov, volaní funkcií atď.), A že štandard umožňuje ktorúkoľvek z nich; pri konkrétnej implementácii operačného systému je možné zvoliť ľubovoľný a takýto systém sa považuje za zhodný s normou. Aplikačný program (striktne sa zhodujúci s normou) musí byť napísaný tak, aby správne fungoval v akomkoľvek variante; ako taký, termín implicitne vyjadruje požiadavku na aplikačný program.

Uveďme príklad: „Funkcia readdir () musí vrátiť ukazovateľ na štruktúru, ktorá odkazuje na ďalší prvok adresára. To, či sa položky z katalógu s názvom „bod“ a „bod-bod“ vrátia alebo nie, štandard nešpecifikuje. “ V tomto prípade existujú š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 čakať na signál so zadaným číslom, vyvolaná vo viacerých riadiacich vláknach, potom keď signál príde nie viac ako do jedného z nich, sigwait () sa musí vrátiť. V akom druhu toku riadenia sa to stane, nie je štandardom stanovené. “ V tomto prípade môže byť oveľa viac možných výsledkov, ale všetky sú tiež známe a požiadavkou aplikácie je, aby správne fungovala pri každom výsledku.

Pojem „nedefinovaný“ znamená, že nie je známych ani veľa výsledkov, je možný akýkoľvek výsledok, dokonca katastrofálny (napríklad zlyhanie systému, strata údajov atď.). Tento termín v zásade implicitne vyjadruje požiadavku, aby aplikačný program nepoužíval zodpovedajúce údaje alebo konštrukcie. Napríklad: "Ak argument dirp pre readdir () neodkazuje na aktuálne otvorený adresár, výsledok nie je definovaný."

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

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

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

Význam pojmu „definovaný implementáciou“ sa líši od intuitívneho. Je zrejmé, že v konkrétnom operačnom systéme nemôže existovať žiadny „nešpecifikovaný“ alebo „nedefinovaný“ výsledok, určitý konkrétny výsledok sa získa bez problémov. Termín „definovaný implementáciou“ vyjadruje požiadavku normy na dokumentáciu operačného systému: výsledok musí byť nielen špecifikovaný (vývojár operačného systému to bude musieť urobiť tak či tak), ale musí byť tiež výslovne uvedený v systémovej dokumentácii.

Predvolená sémantika

Ani jeden regulačný dokument nemôže pokrývať celú škálu prípadov, ktoré sa môžu vyskytnúť v praxi, takže o niečom nevyhnutne mlčí3. Popis funkcie môže napríklad hovoriť, že jej argument môže preberať hodnoty z určitého rozsahu, ale nehovorí sa nič o tom, aký bude výsledok, ak argument nespadá do tohto rozsahu. Aby sa predišlo nedorozumeniam, je zrejmé, že je potrebná jednotná predvolená sémantika. V informatívnej časti štandardu je zaujímavá fráza: „všeobecne akceptovaná sémantika predvoleného nastavenia je zakázaná“. Toto tvrdenie je v rozpore so známym desať rokov starým sloganom „všetko je dovolené, čo nie je výslovne zakázané“. Zdá sa, že je to v hlavách občanov tak zakorenené, že mnohí, dokonca ani programátori, nesúhlasia s citovaným vyhlásením normy. Medzitým, ak použitie akéhokoľvek konštruktu nie je výslovne 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 uplatnenie nároku.

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 viac užívateľov a programy spustené rôznymi užívateľmi musia byť navzájom spoľahlivo izolované, aby nedošlo k náhodnému skresleniu údajov „niekoho iného“. Táto izolácia je zaistená skutočnosťou, že užívateľský program je spustený v procese, ktorý sa vyvíja vo vlastnom virtuálnom adresnom priestore. Aj keď program obsahuje globálne údaje, pri ich spustení v rôznych procesoch budú automaticky „rozvedené“ do rôznych adresných priestorov.

Procesný mechanizmus však nie je úplne uspokojivý pri programovaní úloh v reálnom čase. Aplikáciu v reálnom čase (spustenú v mene toho istého používateľa) možno často prirodzene predstavovať ako súbežne vykonávajúce časti nazývané „vlákna“. Ich najdôležitejším rozdielom od procesov je, že všetky riadiace toky sa vyvíjajú v jednom adresnom priestore; poskytuje rýchly prístup k globálnym údajom, ale zároveň existuje riziko ich neúmyselného skreslenia a aby sa tomu zabránilo, je potrebné dodržať určitú disciplínu programovania. Príslušné odporúčania sú obsiahnuté v informatívnej časti normy.

Je potrebné zdôrazniť, že myšlienka viacvláknového spracovania je implementovaná v mnohých operačných systémoch v reálnom čase a je implementovaná rôznymi spôsobmi v tom zmysle, že každé vlákno ovládania má inú sadu atribútov a funkcií rozhrania; niekedy sa namiesto vlákna používa výraz úloha. Aby sa zabránilo zámene, norma zdôrazňuje, že sa zaoberá výlučne vláknami POSIX a názvy zodpovedajúcich funkcií rozhrania majú predponu pthread_ (napríklad pthread_create (), pthread_join () atď.).

Zhoda so štandardom. Sémantika slova „zápas“

Intuitívne sa verí, že ak sú dve položky vyrobené v súlade s rovnakou normou, potom sa zaručene navzájom „spoja“ a budú spolupracovať vo dvojiciach; toto je presne účel zavedenia štandardu rozhrania (rozhrania). Pretože POSIX je štandardom rozhrania, 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ň jeden z nich, potom systém (alebo aplikačný program) nie je v súlade s normou. Súčasne bolo do dnešného dňa napísaných toľko operačných systémov a aplikačných programov triedy UNIX, že je sotva rozumné vyžadovať úplnú zhodu v uvedenom zmysle. Ťažkosti s rozvojom medzinárodnej normy tohto druhu zhoršuje existencia rôznych národných jazykov. Aj keď zabudneme na aplikačné programy určené na spracovanie textov v národných jazykoch, takmer každý aplikačný program musí vydávať nejaké diagnostické správy a / alebo vnímať texty zadané 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;
• POSIX.1 súlad s rozšíreniami.

Za druhé, mnohé zariadenia rozhrania sú voliteľné; Štandard vyžaduje, aby sa voliteľné funkcie rozhrania správali podľa štandardov alebo aby vždy vracali špeciálny chybový kód ENOSYS (čo znamená, že funkcia nie je implementovaná). Voliteľné zariadenia sú rozdelené do niekoľkých skupín, z ktorých každá zodpovedá nejakej konfiguračnej konštante, ktorá je deklarovaná (operátorom #define) v zodpovedajúcom hlavičkovom súbore; to umožňuje zistiť, či bola funkcia implementovaná počas fázy kompilácie.

Popísaný spôsob dosiahnutia mobility nevymysleli autori POSIX, ale v praxi sa už dlho používa; v mnohých operačných systémoch sa na identifikáciu samotného systému alebo jeho verzie používajú konfiguračné konštanty. A tu štandard neponúka nič zásadne nové, ale iba systematizuje existujúcu prax.

Predmety normalizácie a štruktúra normy

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

• Názvy funkcií rozhrania. Štandardizovaných je 357 funkcií, pričom 107 funkcií je prevzatých zo štandardných knižníc C (matematické, spracovanie reťazcov, vstup / výstup atď.); tieto funkcie sú považované za súčasť štandardu POSIX.1, ale sú Úplný popis obsiahnuté v norme pre programovací jazyk C.
• Názvy typových údajov systému. Tieto názvy majú príponu _t.
• Názvy hlavičkových súborov a minimálne zloženie týchto súborov.
• Globálne názvy globálnych premenných v celom systéme (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 názvy 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 po SIGRTMAX vrátane, obsahujúci najmenej čí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é vlajky, premenné prostredia.

Štandard sa vo všeobecnosti 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 dodatky, ktoré poskytujú zoznam odkazov, komentárov a vysvetlení k normatívnej časti, zloženie hlavičky súbory, príklad profilu („projekcie“) normy (pre Dánsko), charakteristiky a metodika merania výkonu najdôležitejších funkcií, ako aj popis ďalších funkcií rozhrania na 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 doložiek štandardu“ 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 dosiahnuť dohodu dokonca aj pre dve osoby) 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á ako „proces“, „úloha“ a „riadiaci tok“, ale z hľadiska praktického programovania „úloha“ v operačnom systéme IBM OS / 360 a časový operačný systém VxWorks nie je rovnaký. a tiež. Ďalším príkladom sú semafory. Semafory sú binárne, celočíselné („s počítadlom“) a vzájomné vylúčenie (ktoré mimochodom programátori medzi sebou nazývajú „mutexy“, pričom sa spontánne pokúšajú vyhnúť nedorozumeniam). A celočíselné semafory, napríklad v operačnom systéme VxWorks, nie sú vôbec rovnaké ako semafory POSIX.

Autori štandardu POSIX, ktorí si dobre uvedomujú, aké ťažké je prinútiť ľudí opustiť svoje návyky (ktoré nazývajú „zavedená prax“), vyhlasujú, že zostavili ucelený a minimálny systém funkcií rozhrania, ktorý tradične pokrýva väčšinu služieb. poskytované operačným systémom, podrobne popísal presnú sémantiku týchto funkcií a pozýva všetkých, aby ich použili vo svojom vývoji4.

Pri čítaní normy má človek niekedy dojem, že niektoré znenia mali jediný účel: nevyňať niektoré aplikačné programy alebo operačné systémy z kategórie spĺňania normy. Takýto cieľ bol skutočne stanovený a explicitne formulovaný v úvode: norma by mala v čo najväčšej miere brať do úvahy prevládajúcu prax. Hlavným cieľom však stále je zaistiť mobilitu aplikačných programov.

O autorovi

Sergej Romanyuk - senior researcher of the Research Institute for System Research, vedúci skupiny POSIX standard translator group. Je možné ho kontaktovať e -mailom na adrese: [chránené e -mailom]

1 Je potrebné dodať, že práca na štandarde prebieha už mnoho rokov; sú identifikované nové problémy, ktoré sú buď zahrnuté v jednej z existujúcich častí, alebo sú formalizované ako samostatná časť, ktorú je možné následne zrušiť. Stalo sa to napríklad s front-endovými 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 žiadnych implikovaných hodnotách, ktoré sú skutočne deklarované, ale o absencii odkazov vôbec.

4 Začiatkom roku 2000 bude vydaný ruský preklad normy.

Literatúra

Medzinárodná norma ISO / IEC 9945-1 (ANSI / IEEE Std 1003.1), druhé vydanie. 1996-07-12. Informačné technológie - Rozhranie prenosného operačného systému (POSIX) - Časť 1: Rozhranie aplikačného programu systému (API).

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

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

Sekcia 1	- Úvod
Oddiel 2	- Terminológia a definície
Oddiel 3	- Funkcie pre správu procesov (vytváranie, nahrádzanie obrazu, dokončovanie) a signálov (správa masiek, odpovedanie na signály)
Oddiel 4	- Identifikácia (procesy, používatelia, systém, terminál), zisťovanie času stráveného vykonaním procesu, zisťovanie premenných prostredia.
Oddiel 5	- Správa súborov a adresárov
Oddiel 6	- Vstupné a výstupné funkcie
Oddiel 7	- Terminálne riadiace funkcie
Oddiel 8	- Funkcie požičané z jazykovej normy C.
Oddiel 9	- Prístup k databázam užívateľov a skupín užívateľov
Oddiel 10	- Dátové formáty na archiváciu a výmenu (tar a cpio)
Oddiel 11	- Možnosti synchronizácie: semafory, mutexy a podmienkové premenné
Oddiel 12	- Funkcie správy pamäte: pripnutie a odpojenie adresného priestoru procesu, mapovanie súborov do pamäte, ochrana pamäte, zdieľaná pamäť
Oddiel 13	- Funkcie súvisiace s plánovaním procesov a kontrolnými tokmi
Oddiel 14	- Správa hodín a časovača
Oddiel 15	- Správa frontu správ
Oddiel 16	- Základné funkcie súvisiace s riadením tokov
Oddiel 17	- Údaje špecifické pre vlákna
Oddiel 18	- Prostriedky ničenia kontrolných tokov

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

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

Princípy konštrukcie OS:

1.) Zásada modularity- modul je vo všeobecnosti chápaný ako funkčne kompletný 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 za predpokladu, že sú k dispozícii uvedené rozhrania. Rozdelenie systému na moduly je do značnej miery určené použitou metódou návrhu OS (zdola nahor alebo naopak).

Privilegované, znovu vstupujúce a znova vstupujúce moduly sú obzvlášť dôležité pri vytváraní operačného systému (opätovné oprávnenie je doslova opätovné oprávnenie; špeciálny výraz na označenie zdravia programu; vlastnosť programu, ktorý sa má správne vykonať pomocou rekurzívny (vrátený) hovor z prerušenia).

Najväčší efekt z použ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- určitá časť dôležitých modulov je alokovaná v OS, ktorý musí byť neustále v pamäti RAM, aby bola efektívnejšia organizácia výpočtového procesu. Táto časť sa v OS nazýva jadro, pretože je základom systému. Pri formovaní zloženia jadra je potrebné vziať do úvahy dve protichodné požiadavky. Na jednej strane by mali byť v jadre zahrnuté najčastejšie používané systémové moduly, na druhej strane by počet modulov mal byť taký, aby množstvo pamäte obsadenej jadrom nebolo príliš veľké. Okrem softvérových modulov, ktoré sú súčasťou jadra a sú trvalo umiestnené v pamäti RAM, môže existovať mnoho ďalších modulov systémového softvéru, ktoré sa nazývajú tranzit. Tranzit softvérových modulov načítané do pamäte RAM iba v prípade potreby a v neprítomnosti voľné miesto môžu byť nahradené inými tranzitnými modulmi.

3.) Princíp generovateľnosti operačného systému: Podstata princípu spočíva v zorganizovaní (výbere) takej metódy pre počiatočnú prezentáciu programu centrálneho riadenia systému OS (jadro a hlavné komponenty trvalo uložené v pamäti RAM), ktoré umožnili prispôsobiť túto časť dohľadu nad systémom. na základe konkrétnej konfigurácie konkrétneho počítačového komplexu a rozsahu úloh, ktoré je potrebné vyriešiť. Tento postup sa zriedka vykonáva pred dostatočne dlhým operačným obdobím 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ýsledkom generovania je plná verzia OS. Vygenerovaná verzia OS je zbierka systémových súborov modulov a údajov.

4.) Princíp funkčnej redundancie: Tento princíp zohľadňuje možnosť vykonávania tej istej práce rôznymi prostriedkami. Operačný systém môže zahŕňať niekoľko typov monitorov (moduly dohľadu, ktoré riadia jeden alebo iný typ zdroja), rôzne spôsoby organizácie komunikácie medzi výpočtovými procesmi. Prítomnosť niekoľkých typov monitorov, niekoľkých systémov na správu súborov umožňuje používateľom rýchlo a najvhodnejšie prispôsobiť OS konkrétnej konfigurácii počítačového systému, zaistiť čo najefektívnejšie načítanie 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 konkrétnej sady plánovačov procesov a alokátorov zdrojov (monitorov) a používať jednu centralizovanú schému prideľovania zdrojov.

Najprirodzenejším a najkompletnejším prejavom konceptu virtuality je koncept virtuálny prístroj ... Virtuálny stroj poskytovaný používateľovi reprodukuje architektúru skutočného stroja, ale architektonické prvky v tomto zobrazení majú nové alebo vylepšené vlastnosti, ktoré spravidla zjednodušujú prácu so systémom. Charakteristiky môžu byť ľubovoľné, ale najčastejšie chcú používatelia mať 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 činnosti.

- ľ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 počítača paralelne alebo sekvenčne, asynchrónne alebo synchrónne vzhľadom na činnosť jedného alebo druhého virtuálneho procesora, ktorý iniciuje činnosť týchto zariadení.

Jedným z aspektov virtualizácie je organizácia možnosti spustenia v danom OS aplikácie, ktoré boli vyvinuté pre iný OS. Inými slovami, hovoríme o organizácii niekoľkých operačných prostredí.

6.) Princíp nezávislosti programov od externých zariadení: tento princíp je teraz implementovaný v prevažnej väčšine operačných systémov na všeobecné účely. Tento princíp bol po prvý raz konzistentne implementovaný v systéme UNIX. Je implementovaný aj vo väčšine moderných operačných systémov pre počítače. Tento princíp spočíva v skutočnosti, že spojenie programov so špecifickými zariadeniami sa neuskutočňuje na úrovni vysielania programu, ale počas plánovacieho obdobia jeho vykonávania. V dôsledku toho nie je potrebná opätovná kompilácia, keď je program spustený s novým zariadením, na ktorom sú umiestnené údaje.

7.) Zásada 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. Otázky je potrebné oddeliť binárna kompatibilita a kompatibilita zdroja aplikácií.

Binárnu kompatibilitu dosiahnete, keď si môžete vziať spustiteľný program a spustiť ho na inom OS. To vyžaduje kompatibilitu na úrovni procesných inštrukcií a kompatibilitu na úrovni systémových volaní a dokonca aj na úrovni hovorov knižnice, ak sú dynamicky prepojené.

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

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

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

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

8.) Princíp otvorenosti a škálovateľnosti: Otvorený operačný systém je k dispozícii na analýzu používateľom aj systémovým špecialistom, ktorí spravujú počítačový systém. Rozbaliteľný (modifikovateľný, vyvinutý) operačný systém umožňuje nielen využívať možnosti generovania, ale aj zavádzať do jeho zloženia nové moduly, zlepšovať existujúce atď. Inými slovami, malo by byť možné ľahko vykonávať doplnky a zmeny podľa potreby bez toho, aby bola ohrozená integrita systému. Prístup klient-server k štruktúrovaniu OS pomocou mikro-jadrovej technológie poskytuje vynikajúce príležitosti na rozšírenie. V súlade s týmto prístupom je operačný systém vytvorený ako sada privilegovaných riadiacich programov a sada neprivilegovaných služieb (serverov). Hlavná časť operačného systému zostáva nezmenená a súčasne je možné pridať nové servery alebo vylepšiť staré. Tento princíp sa niekedy interpretuje ako rozšíriteľnosť systému.

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

pripojiť sa z jedného typu procesora k inému typu procesora a z hardvérovej platformy jedného typu, ktorá spolu s typom procesora a spôsobom organizácie celého počítačového hardvéru (architektúra počítačového systému) zahŕňa aj iný typ hardvérovej platformy . Všimnite si toho, že princíp prenosnosti je veľmi blízko princípu kompatibility, aj keď nie sú to isté. Písanie prenosného operačného systému je podobné písaniu akéhokoľvek prenosného kódu, ale musíte sa nimi riadiť pravidlá:

- väčšina operačného systému musí byť spustená v jazyku, ktorý je dostupný vo všetkých systémoch, do ktorých sa plánuje jeho prenos v budúcnosti. To v prvom rade znamená, že OS musí byť napísaný v jazyku vysoký stupeň, výhodne štandardizované, napríklad v C. Program napísaný v zostave nie je spravidla 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. Medzi zrejmé formy závislosti patrí priama manipulácia s registrami a iným hardvérom. Nakoniec, ak kód závislý od hardvéru nemožno úplne vylúčiť, 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 zaistenie prenosnosti vytvoreného softvéru.

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

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

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

ČoPOSIX: platformové 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 prostredí, obslužných programov a súprav nástrojov. Okrem toho POSIX štandardizoval 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 je možné ho implementovať aj do iných operačných systémov. POSIX vznikol ako pokus na celom svete známa organizácia IEEE podporuje prenosnosť aplikácií v prostrediach UNIX vývojom abstraktného štandardu nezávislého na platforme. Napríklad známy operačný systém QNX v reálnom čase vyhovuje špecifikáciám tohto štandardu.

Tento štandard podrobne popisuje virtuálny pamäťový systém VMS (Virtual Memory System), multitasking MPE (Multi-Process Executing) a Convergent Technology ... (CTOS). POSIX je teda vlastne súbor štandardov nazývaných POSIX.I –POSIX.12. Je tiež potrebné poznamenať, že POSIX.1 predpokladá C ako hlavný jazyk.

Jazyk popisu funkcií systému API.

Programy napísané v súlade s týmito štandardmi teda budú fungovať identicky na všetkých systémoch kompatibilných s POSIX. V niektorých prípadoch má však štandard iba poradný charakter. Niektoré zo štandardov sú popísané veľmi striktne, zatiaľ čo druhá časť iba povrchne odhaľuje základné požiadavky.

Implementácie POSIX API do operačného systému sú rôzne. Ak prevažná väčšina systémov UNIX pôvodne vyhovuje špecifikáciám IEEE Standard 1003.1-1990, WinAPI nie je kompatibilný s POSIX. Na podporu tohto štandardu v operačnom systéme MS Windows NT bol však zavedený špeciálny modul podpory rozhrania POSIX API, ktorý funguje na úrovni oprávnení používateľských procesov.

Tento modul poskytuje konverziu a prenos hovorov z používateľského programu do systémového jadra a späť, pričom s jadrom pracuje pomocou rozhrania Win API. Ostatné aplikácie postavené pomocou WinAPI môžu prenášať informácie do aplikácií POSIX prostredníctvom štandardných mechanizmov toku I / O (stdin, stdout).

Žiadne súvisiace príspevky ...