Kurz zkoumá standard pro rozhraní mobilního operačního systému (POSIX) a také techniky a metody pro programování aplikací založené na tomto standardu, ilustrovaný mnoha příklady. Dotčeny jsou otázky programování víceprocesových systémů, interakce aplikací v rámci distribuovaných konfigurací. Poskytování mobility (přenositelnost, přenositelnost) software(PO) - úkol mimořádné důležitosti a složitosti; V dnešní době tato okolnost stěží potřebuje rozsáhlé odůvodnění. Jedním z obecně uznávaných způsobů, jak zvýšit mobilitu softwaru, je standardizace aplikačního prostředí: poskytovaná softwarová rozhraní, nástroje atd. Na úrovni systémových služeb takové prostředí popisuje standard POSIX (Interface Portable Operating System Interface); název navrhl známý specialista, zakladatel Free Software Foundation Richard Stallman.

Kurz zkoumá jeho nejmodernější verzi z edice 2003, kterou lze nazvat „trojitým standardem“, konkrétně: standard IEEE Std 1003.1, technická norma Open Group a hlavně pro nás mezinárodní ISO / IEC 9945 Tento kurz je o porozumění technikám a metodám používání standardizovaných nástrojů a funkcí. Cílem nebylo převyprávět standard, zdůraznit všechny jemnosti implementace OS, všechny možné chybové kódy atd. Hlavní věcí podle nás je cítit ducha standardu, naučit se využívat možnosti, které jsou mu vlastní, mobilním způsobem. Za předpokladu, že čtečka hovoří plynně C, nezvažovali jsme ani její funkce syntaxe ani knihovny učebnic. Pokud jde o standardní příkazový jazyk a jeho tlumočníka, toto téma je podrobně popsáno, ačkoli mnoho praktických programátorů dává přednost použití jiných tlumočníků. Významné místo - co do objemu i role - je dáno příkladům programů. Mnoho ustanovení normy (souvisejících například s řešením chybových situací) není uvedeno v hlavním textu, ale v odpovídajících příkladech. Ty druhé, pokud je to možné, byly sestaveny a provedeny na několika hardwarových a softwarových platformách, do jedné titul nebo jiný nárok na dodržování standardu POSIX. Přehlédnutí je však určitě možné. Budeme vděční za všechny připomínky a návrhy související jak s kurzem jako celkem, tak s jednotlivými příklady programů.

Historie vytvoření a aktuální stav standardu POSIX.

Zajištění mobility (přenositelnosti, přenositelnosti) softwaru (SW) je úkolem mimořádné důležitosti a složitosti; v naší době tato okolnost stěží potřebuje rozsáhlé odůvodnění. Jedním z obecně uznávaných způsobů, jak zvýšit přenositelnost softwaru, je standardizace aplikačního prostředí: poskytovaná rozhraní API, obslužné programy atd. Na úrovni systémových služeb takové prostředí popisuje standard POSIX (Interface Portable Operating System Interface); jméno navrhl známý odborník, zakladatel Free Software Foundation, Richard Stallman.

Titulní strana.
Výstup.
Přednáška 1. Základní pojmy a myšlenky standardu POSIX.
Přednáška 2. Shell language.
Přednáška 3. Nástroje a funkce sloužící konceptu „uživatel“.
Přednáška 4. Organizace systému souborů.
Přednáška 5. Vstup / výstup souboru.
Přednáška 6. Nástroje pro zpracování strukturovaných dat.
Přednáška 7. Procesy.
Přednáška 8. Prostředky meziprocesové komunikace.
Přednáška 9. Společné rozhraní terminálu.
Přednáška 10. Výzkum charakteristik hostitele a jejich využití v aplikacích.
Přednáška 11. Síťová zařízení.
Přednáška 12. Čas a práce s ním.
Přednáška 13. Jazykové a kulturní prostředí.
Přednáška 14. Závěr.
Bibliografie.

Stažení zdarma e-kniha ve vhodném formátu sledujte a čtěte:
Stáhněte si knihu Programování ve standardu POSIX, část 1, Galatenko V.A., 2016 - fileskachat.com, rychlé a bezplatné stažení.

POSIX a RV OS: pokus o systematizaci

Sergej Zolotarev, Nikolaj Gorbunov

Účelem tohoto článku je pokus vnést určitou jasnost do historie vývoje standardu POSIX aplikovaného na operační systémy v reálném čase (RT OS).

Na úvod: proč je potřeba standardizace softwarového rozhraní?

Jednou z nejdůležitějších vlastností standardu POSIX je, že definuje „standardizované programovací rozhraní“, které musí vývojáři komplexních softwarových a hardwarových systémů dodržovat. Tvůrci těchto systémů jsou nuceni čelit takovým požadavkům, jako je krátký čas uvedení na trh (kvůli tvrdé konkurenci), minimalizace nákladů a zrychlení návratnosti investic. Lví podíl na nákladech v důsledku zpomalení vývojového procesu je přitom způsoben skutečností, že programátoři musí „znovu objevit kolo“, znovu a znovu implementovat funkce, které jsou k dispozici již dlouhou dobu. Tomu se však dalo zabránit:

• opětovné použití kódu z minulých a paralelních projektů;
• přenesení kódu z jiných operačních systémů;
• přilákání vývojářů z jiných projektů (včetně těch, kteří používají jiné operační systémy).

To vše je možné díky použití OS se standardizovaným API. Navíc pokud v prvním případě stačí, aby organizace měla určitý vnitřní standard (což je zvláště typické pro proprietární operační systémy), pak druhé dva případy vyžadují pouze přítomnost obecně přijímaných standardů - například POSIX.

Díky použití OS kompatibilního s POSIX jako platformy pro své projekty dostane vývojář příležitost přenést hotový kód na úroveň zdrojového kódu ze svých minulých nebo paralelních projektů i z projektů třetích stran. To nejen výrazně zkracuje dobu vývoje softwaru, ale také zlepšuje jeho kvalitu, protože testovaný kód vždy obsahuje méně chyb.

Kdo je kdo ve vývoji POSIX

A nezačneme samotným standardem POSIX, ale uspořádáním role organizací zapojených do práce na něm.

Prvním účastníkem je IEEE(Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers), veřejné neziskové sdružení profesionálů. IEEE pochází z roku 1884 (formálně - od roku 1963), sdružuje 380 000 jednotlivých členů ze 150 zemí, vydává třetí část technické literatury související s používáním počítačů, řídicí, elektrické a informační technologie a také více než 100 časopisů. populární mezi profesionály; kromě toho asociace pořádá přes 300 velkých konferencí ročně. IEEE se podílel na vývoji více než 900 stávajících standardů (www.ieee.ru/ieee.htm). Dnes se tento institut zabývá přípravou, koordinací, schvalováním a vydáváním norem, ale vzhledem ke svému formálnímu postavení nemá pravomoc přijímat takové dokumenty jako mezinárodní nebo národní normy. Proto by měl být termín „standard“ v chápání IEEE chápán spíše jako „specifikace“, což je více v souladu se stavem dokumentů přijímaných asociací. V souladu s IEEE se podílí na programech řady mezinárodních a regionálních organizací - IEC, ISO, ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute), CENELEC (Evropský výbor pro elektrotechnickou standardizaci) a v národních programy, například v programu takové organizace, jako je ANSI.

IEEE zahrnuje výbor PASC (Portable Application Standards Committee), asociační výbor, který vyvíjí řadu standardů POSIX (www.pasc.org/). PASC byl dříve známý jako technický výbor pro operační systémy.

Druhý účastník práce - ANSI(American National Standards Institute, American National Standards Institute) - soukromá nezisková organizace, která spravuje a koordinuje ve Spojených státech normalizační činnosti. Zaměstnává pouze 75 lidí, ale ANSI má více než 1 000 členů, společností, organizací, vládních agentur a institucí (www.ansi.org). ANSI zastupuje Spojené státy ve dvou hlavních mezinárodních normalizačních orgánech, ISO a IEC.

Třetí účastník - ISO(Mezinárodní organizace pro normalizaci). Byla vytvořena v roce 1946 rozhodnutím Výboru pro koordinaci norem a Valného shromáždění OSN a oficiálně zahájena práce 23. února 1947 (www.iso.org). ISO je síť národních normalizačních institutů ze 146 zemí (jedna země - jeden člen ISO) s ústředním sekretariátem v Ženevě (Švýcarsko). Normy ISO jsou vyvíjeny v technických komisích, jejichž prvním výstupem je návrh mezinárodní normy (DIS), který se po několika schváleních stává konečným návrhem mezinárodní normy (FDIS). Poté se o otázce schválení tohoto dokumentu hlasuje; pokud bude úspěšný, stane se mezinárodním standardem.

A nakonec - IEC(International Electrotechnical Commission, International Electrotechnical Commission - IEC), založená v roce 1906, IEC připravuje a vydává mezinárodní standardy pro všechny elektrické, elektronické a související technologie (www.iec.ch/). K 1. listopadu 2004 byly aktivními členy této komise národní výbory 64 zemí. IEC také vydává doporučení, která jsou publikována v angličtině a francouzštině a mají status mezinárodních norem. Na jejich základě jsou vyvinuty regionální a národní standardy. Technické komise (TC) jsou odpovědné za přípravu norem v různých oblastech činností IEC, ve kterých se účastní národní výbory, které se zajímají o činnosti konkrétního TC.

IEC je klíčovou organizací při přípravě mezinárodních standardů informačních technologií. V této oblasti existuje společný technický výbor pro informační technologie - JTC 1, vytvořený v roce 1987 v souladu s dohodou mezi IEC a ISO. JTC1 má 17 podvýborů dohlížejících na vše od softwaru po programovací jazyky, počítačovou grafiku a úpravy obrázků, propojení zařízení a bezpečnostní postupy.

Příprava nových norem IEC zahrnuje několik fází (předběžná fáze, fáze návrhu, přípravná fáze, fáze technické komise, fáze žádosti, fáze schválení, publikace). Pokud se má dokument IEC stát pouze technickou specifikací, a nikoli mezinárodní normou, je revidovaná verze dokumentu odeslána do centrály k publikaci. Dokončení konečného návrhu mezinárodní normy (FDIS) bude trvat čtyři měsíce. Pokud je schválen všemi členy technické komise, je odeslán do ústředí ke zveřejnění bez fáze schválení FDIS. Poté jde FDIS do národních výborů, které jej musí schválit do dvou měsíců. FDIS je považován za schválený, pokud pro něj hlasovaly více než dvě třetiny národních výborů a počet záporných hlasů nepřesahuje 25%. Pokud dokument není schválen, je odeslán k přepracování technickým výborům a podvýborům. Norma musí být zveřejněna nejpozději dva měsíce po schválení FDIS.

Na vývoji a přijímání standardů POSIX se podílí několik dalších organizací.

Otevřená skupina Je mezinárodní organizací pro standardizaci softwaru, která sdružuje téměř 200 výrobců a uživatelských komunit působících v oblasti informačních technologií (www.opengroup.org/). Skupina Open Group vznikla v roce 1995 sloučením jejích dvou předchůdců: X / Open a Open Software Foundation (OSF). Otevřená skupina se specializuje na vývoj metodik certifikace softwaru a testování shody. Otevřená skupina se zabývá zejména certifikací pro oblasti jako COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S / MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) a, konečně rodina standardů POSIX (www.opengroup.org/certification/).

Austin Common Standards Revision Group (CSRG)- společný technický pracovní skupina vytvořené v roce 2002 ISO, IEC a Open Group za účelem vytváření a údržby nejnovější verze standard 1003.1, který bude vytvořen na základě ISO / IEC 9945-1-1996, ISO / IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 a Single UNIX Specification (www.opengroup.org / press/ 14nov02.htm).

National Institute of Standards and Technology (NIST)- federální agentura v rámci správy technologií ministerstva obchodu (www.nist.gov/public_affairs/general2.htm), založená ve Spojených státech v roce 1901. Posláním NIST je vyvíjet a propagovat standardy a technologie ke zlepšení kvality produktů. NIST zahrnuje Laboratoř informačních technologií (ITL), jejíž jedním z výsledků jsou Federální normy pro zpracování informací (FIPS, www.opengroup.org/testing/fips/general_info.html). NIST / ITL nabídl počáteční sadu testů pro certifikaci POSIX podle FIPS PUB 151-1 1990 v roce 1991.

Co je POSIX?

Formálně termín POSIX navržený Richardem Stallmanem jako zkratka pro P ortable Ó perating S ystem rozhraní pro un IX(rozhraní přenosného operačního systému pro Unix). POSIX byl vyvinut pro operační systémy podobné UNIXu (jejich nejstarší verze pocházejí z počátku 70. let) s cílem poskytnout přenositelnost zdrojů aplikacím.

Počáteční popis rozhraní byl publikován v roce 1986, kdy byl nazýván IEEE-IX (verze systému UNIX pro IEEE). Název se však rychle změnil, stal se POSIX a již v další publikaci (v roce 1986) tato nová verze byl nějaký čas POSIX chápán jako odkaz (nebo synonymum) na skupinu souvisejících dokumentů IEEE 1003.1-1988 a části ISO / IEC 9945 a jako úplnou a schválenou mezinárodní normu ISO / IEC 9945.1: 1990 byl POSIX přijato v roce 1990. Specifikace POSIX definují standardní mechanismus pro interakci mezi aplikačním programem a operačním systémem a v současné době zahrnují více než 30 standardů pod záštitou IEEE, ISO, IEC a ANSI.

POSIX prošel v celé své historii dlouhou cestu, kdy se označení specifikací, jejich konkrétní obsah, postupy a logistika jejich ověřování mnohokrát změnily. Od té doby bylo vydáno několik edic standardu POSIX v rámci různých mezinárodních organizací.

Historie vývoje standardu POSIX

První verze specifikace IEEE Std 1003.1 byla vydána v roce 1988. Následně byla jako mezinárodní standardy přijata řada edic IEEE Std 1003.1.

Fáze vývoje POSIX:

Rok 1990

Edice, vydaná v roce 1988, byla revidována a stala se základem pro další revize a dodatky. Byl schválen jako mezinárodní norma ISO / IEC 9945-1: 1990.

Rok 1993

Vydání vydání 1003.1b-1993.

Rok 1996

Byly provedeny změny v IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 a 1003.1i-1995, ale většina dokumentu zůstává nezměněna. V roce 1996 byla revize IEEE Std 1003.1 schválena také jako mezinárodní norma ISO / IEC 9945-1: 1996.

Rok 1998

Objevil se první standard pro „real time“ - IEEE Std 1003.13-1998. Jedná se o rozšíření standardu POSIX pro integrované aplikace v reálném čase.

Rok 1999

Bylo rozhodnuto provést první významné změny v hlavním textu normy za posledních 10 let, včetně sloučení se standardem 1003.2 (Shell a veřejné služby), protože v té době to byly samostatné standardy. PASC se rozhodl dokončit změny základního textu po dokončení standardů IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q a 1003.2b.

2004 r.

Poslední revize standardu 1003.1 byla zveřejněna 30. dubna a vydána pod záštitou skupiny Austin Common Standards Revision Group. Je novelizován pro vydání normy 2001. Vydání 2004 je formálně známé jako IEEE Std 1003.1, Edition 2004, The Open Group Technical Standard Base Specifications, Issue 6 and includes IEEE Std 1003.1-2001, IEEE Std 1003.1-2001 / Cor 1-2002 a IEEE Std 1003.1-2001 / Cor 2-2004.

Nejdůležitější standardy POSIX pro RV OS

Pro operační systémy v reálném čase je nejdůležitější sedm specifikací standardu (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), ale pouze tři získaly širokou podporu v komerčních operačních systémech:

• 1003.1a (definice OS) definuje hlavní rozhraní OS, řízení úloh, signály, funkce souborového systému a práci se zařízeními, skupinami uživatelů, kanály, FIFO buffery;
• 1003,1b (rozšíření v reálném čase) popisuje rozšíření v reálném čase, jako jsou signály v reálném čase, prioritní plánování, časovače, synchronní a asynchronní I / O, semafory, sdílená paměť, zprávy. Zpočátku (před rokem 1993) byl tento standard označován jako POSIX.4.
• 1003,1c (vlákna) definuje funkce podpory vláken - ovládání vlákna, atributy vláken, mutexy, dispečink. Původně označen jako POSIX.4a.

Kromě těchto standardů jsou pro RT OS důležité následující standardy, které byly implementovány jako součást práce na projektu Std 1003.1-2001:

• IEEE 1003.1d-1999. Další rozšíření v reálném čase. Původně označen jako POSIX.4b;
• IEEE 1003.1j-2000. Vylepšená (pokročilá) rozšíření v reálném čase;
• IEEE 1003.1q-2000. Trasování.

Certifikační postup

Aby byl operační systém kompatibilní s POSIX, musí být certifikován podle příslušné testovací sady. Od zavedení POSIXu prošla testovací sada formálními a de facto změnami.

V roce 1991 vyvinul NIST testovací program POSIX podle FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). Tato testovací možnost byla založena na návrhu IEEE 1003.3 „Standard pro zkušební metody pro měření shody s POSIX“, návrh 10, 3. května 1989. V roce 1993 NIST dokončila testovací program POSIX pro FIPS 151-1 a zahájila program pro FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 přizpůsobil „Informační technologie - rozhraní přenosného operačního systému (POSIX) - část 1: Rozhraní API pro systémové aplikace (API)“, což je norma ISO / IEC 9945-1: 1990. Testovací sady pro FIPS 151-2 vycházely z IEEE 2003.1-1992 „Standard pro zkušební metody pro měření shody s POSIX“.

NIST rozlišuje dvě metodiky certifikace: vlastní certifikaci a certifikaci zkušebnami akreditovanými IEEE (Accredited POSIX Testing Laboratories - APTL). V prvním případě společnost provádí testování sama, ale podle plánu schváleného NIST. V druhém případě testování provádí nezávislá laboratoř pomocí automatizovaných testovacích sad. Celkem byly akreditovány dvě laboratoře APTL: Mindcraft (www.mindcraft.com) a Perennial (www.peren.com).

V roce 1997 NIST / ITL oznámila svůj záměr ukončit certifikaci FIPS 151-2 na konci tohoto roku (oficiálně 31. prosince 1997), zatímco Open Group oznámila, že převezme od 1. října téhož roku. roční certifikační služba v souladu s FIPS 151-2, na základě programu NIST / ITL. Stejné funkce převzala od 1. ledna 1998 IEEE Standards Association (IEEE-SA) a také na základě FIPS 151-2.

V roce 2003 IEEE-SA a Open Group oznámily nový společný certifikační program pro nejnovější verze POSIX počínaje IEEE 1003.1 ™ 2001. Otevřená skupina má nyní několik testovacích sad, které 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). Produkt je považován za certifikovaný POSIX, pokud prošel úplným certifikačním postupem, podle výsledků testů splňuje všechny požadavky a je zapsán v oficiálním registru certifikovaných produktů.

Testovací sady zahrnují:

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm)-sada testů shody pro systémová rozhraní IEEE Std 1003.1-1990;
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - sada testů shody pro IEEE Std 1003.13-1998 Profile PSE54 (víceúčelový v reálném čase);
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm)-sada testů shody pro systémová rozhraní IEEE Std 1003.1-2003 (pouze povinné součásti);
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) je sada testů shody pro IEEE Std 1003.1-2003 (shell a nástroje-pouze povinné součásti).

Otevřená skupina navíc vyvinula benchmarky pro POSIX Realtime Standards a Embedded POSIX Standards Profile. POSIX Realtime Test Suite (www.opengroup.org/testing/testsuites/realtime.html) obsahuje následující testy:

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Realtime extension a IEEE POSIX 1003.1,2003 Edition;
• Rozšíření IEEE Std POSIX 1003.1c-1995 Threads (pthreads) a IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1d-1999 Další rozšíření v reálném č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 následující testy:

• IEEE POSIX 1003.1-1990 (5310 testů);
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 rozšíření v reálném čase (1430 testů);
• Rozšíření IEEE Std POSIX 1003.1c-1995 Threads (pthreads) (1232 testů);
• IEEE POSIX 1003.13-1998 Profil 52.

Trochu o zmatku v terminologii

Ve vztahu ke skupině standardů POSIX používá anglický jazyk často ne jeden, ale až tři termíny. Bohužel mají podobný význam a často jsou přeloženy stejným způsobem, což přináší určité nejasnosti. Tyto podmínky jsou následující:

• kompatibilita (doslova - „kompatibilita“);
• shoda (doslova - „shoda“);
• konformita (doslova - „konzistence“).

První termín aplikovaný na POSIX není formálně definován. Druhý znamená, že organizace - výrobce softwarového produktu nezávisle prohlašuje, že tento produkt (zcela nebo zčásti) vyhovuje uvedeným normám NIST -PCTS. Z toho vyplývá třetí termín software prošel zavedeným testovacím systémem buď s pomocí akreditované laboratoře, nebo v rámci Otevřené skupiny a existují pro to listinné důkazy (tzv. Prohlášení o shodě). Dále v textu článku budou všude citovány originály termínů, aby se odstranila nejednoznačnost.

Certifikovaný OS RV

Pokud dodržujete přísná pravidla vyžadující zveřejnění údajů o certifikovaném RT OS v oficiálním rejstříku a testování probíhá na úrovni shody, pak v současné době existují pouze dva certifikované RT OS (údaje jsou uvedeny v chronologickém pořadí):

LynxOS v.3(produkt Lynx Real-Time Systems, nyní nazývaný LynuxWorks, Inc., www.lynuxworks.com) je určen k vývoji softwaru pro vestavěné systémy pracující v reálném čase, OEM a výrobců telekomunikačních zařízení, zejména výrobců palubních systémů pro vojenské aplikace ... Vývoj lze provádět jak na samotném cílovém systému (vlastní hostování), tak na instrumentálním počítači (hostitel), hotový software je navržen tak, aby pracoval na cílovém systému (cílovém). LynxOS v.3 je certifikovaná shoda POSIX na platformách Intel a PowerPC. Informace o tom lze nalézt na webových stránkách IEEE na adrese http://standards.ieee.org/regauth/posix/posix2.html. LynxOS je certifikován POSIX 1003.1-1996 společností Mindcraft, akreditovanou zkušební laboratoří POSIX IEEE POSIX v sadě NIST FIPS 151-2 Conformance Test Suite. Číslo certifikačního dokumentu: Referenční soubor: IP-2LYX002, Referenční soubor: IP-2LYX001.

INTEGRITY v.5(produkt společnosti Green Hills Software, www.ghs.com) má certifikovanou shodu s POSIX 1003.1-2003, Systémová rozhraní pro architekturu PowerPC v červenci 2004 (http://get.posixcertified.ieee.org/select_product. tpl). Testovací sada VSX-PCTS 2003.

POSIX a operační systém QNX

QNX v.4.20 (vyvinutý společností QNX Software Systems, www.qnx.com) je certifikován pro kompatibilitu POSIX 1003.1-1988 pro platformu Intel společností DataFocus Incorporated. Testování proběhlo 13. září 1993 a bylo vydáno 1. listopadu 1993. NIST PCTS 151-1 Test Suite, verze 1.1.

QNX Neutrino (verze 6.3) splňuje následující standardy řady 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, tvůrce QNX Neutrino, také plánuje shodu QNX Neutrino s některými z těchto standardů; práce jsou plánovány na rok 2005 (www.qnx.com/news/pr_959_1.html).

Literatura

1. Provozní manuál asociace IEEE Standards Association. IEEE, říjen 2004.
2. Kevin M. Obeland. POSIX v reálném čase, programování vestavěných systémů, 2001.
3. IEEE / ANSI Standard 1003.1: Information Technology - (POSIX) - Part1: System Application: Program Interface (API).
4. Gallmeister, B. O. Programování pro skutečný svět, POSIX.4 Sebastopol, CA: O'Reilly & Associates, 1995.
5. National Institute of Standards and Technology, PCTS: 151-2, POSIX Test Suite.
6. POSIX: Certifikováno IEEE a The Open Group. Certifikovaná politika. Otevřená skupina, 21. října 2003, revize 1.1.

Alexej Fedorčuk
Rok 2005

Jednou z charakteristických vlastností logické struktury systému souborů operačních systémů řady POSIX je jejich hierarchická nebo stromová organizace (i když, jak jsem řekl, strom vypadá trochu divně). To znamená, že stejně jako v DOSu nebo Windows jakéhokoli druhu neexistuje žádné označení (například abecední nebo jiné) pro jednotlivá média a jejich oddíly: všechny jsou zahrnuty v jedné struktuře jako podadresáře hlavního adresáře. volal kořen. Proces připojení souborové systémy na nezávislých fyzických médiích (a jejich oddílech) do kořene stromu souborů se nazývá mount a podadresáře, které obsahují, se nazývají přípojné body.

Historicky Unix vyvinul specifickou adresářovou strukturu, která je v celé rodině obecně velmi podobná, ale v detailech se mírně liší. Zejména hierarchie souborů v systémech BSD je téměř identická, ale liší se od té v systému Linux. A ve druhém případě jsou mezi různými distribucemi nalezeny významné rozdíly. Až na to, že struktura hierarchie souborů je jednou z funkcí specifických pro distribuci.

Tento stav věcí ztěžuje psaní aplikací napříč platformami. A proto existuje a aktivně se vyvíjí projekt pro standardizaci hierarchie souborů - FHS (Filesystem Hierarchy Standard).

FHS byl původně zaměřen na zefektivnění adresářové struktury mnoha distribucí Linuxu. Později byl upraven pro ostatní Unixové systémy(včetně klanu BSD). A nyní existují aktivní (ale ne příliš úspěšné) snahy, aby se stal standardem pro systémy POSIX, a to nejen jménem, ​​ale i fakticky.

Standard FHS spočívá na dvou základních principech - jasném oddělení hierarchie souborů v adresářích, které jsou na jedné straně sdílené a nesdílené, na straně druhé neměnné a proměnlivé.

Kontrast mezi sdílenými a nesdílenými adresáři je způsoben inherentní síťovou povahou Unixu. To znamená, že data související s místním počítačem (například konfigurační soubory pro jeho zařízení) by měla být umístěna v adresářích oddělených od těch, jejichž obsah je k dispozici z jiných počítačů v síti, lokálních nebo globálních (příkladem je nejen uživatel data, ale také programy) ...

Podstatu opozice mezi neměnnými a měnitelnými adresáři lze snadno vysvětlit na příkladu. Stejné obecné uživatelské programy by tedy ze své podstaty měly být neměnné (nebo spíše dostupné k úpravám pouze správci systému, nikoli však samotnému uživateli, který je ve své práci používá). Současně tyto programy během své práce generují nejen datové soubory, řekněme texty nebo obrázky (jejich proměnná povaha je jasná bez komentářů), ale všechny druhy informací o službě, jako jsou soubory protokolu, dočasné soubory a podobně) . Které by měly být seskupeny do adresářů oddělených od skutečných spustitelných programových souborů potřebných k jejich spuštění, knihoven, konfiguračních souborů atd.

Navzdory aktivní propagaci v mnoha distribucích Linuxu z nejběžnějších FHS nezískal status skutečného standardu. Existuje poměrně málo distribucí Linuxu, které nepoužívají některá z jejích ustanovení. A jen částečně koreluje s tradiční hierarchií souborů systémů BSD.

Důvodem je, že FHS ignoruje ještě jednu opozici, která je pro uživatele velmi důležitá: opozici snadno obnovitelných částí systému souborů a těch jeho komponent, které je obtížné obnovit nebo je nelze obnovit vůbec.

První, kupodivu, lze přičíst samotnému základnímu systému: přeinstalovat jej z distribučního média v případě smrtelné havárie není tak obtížné. Těžko obnovitelné části systému souborů samozřejmě obsahují uživatelská data: i když jsou pravidelně zálohována (a kolik uživatelů je tak opatrných?), Jejich nasazení z archivů zabere hodně času (a téměř nevyhnutelně) s sebou nese určité ztráty).

Navíc v systémech BSD a distribucích Linuxu založených na zdrojích bych vše, co souvisí se správou balíků, klasifikoval jako těžko obnovitelné adresáře-strom portů FreeBSD nebo pkgsrc v NetBSD (a systémy, které si jej vypůjčily), jejich protějšky v distribucích Linuxu, skutečné zdroje přenesených programů a také zdrojový kód systému. Neboť i když je to všechno na distribuční sadě, tyto součásti systému souborů jsou zpravidla uživatelem aktualizovány synchronizací s projektovými servery v síti (jinak jejich použití nemá smysl). A jejich ztráta bude znamenat jak dočasné (zejména s modemovým připojením), tak finanční (jen málo lidí je šťastnými vlastníky volného přístupu k internetu) ztráty.

Přísné dodržování koncepce oddělení sdílených a nesdílených, neměnných a neměnných, obnovitelných a neobnovitelných adresářů od sebe navzájem umožňuje v rámci jediné stromové hierarchie souborů fyzicky oddělovat její jednotlivé větve-tj. Ve formě nezávislých souborových systémů umístěných na izolovaných zařízeních (disky, oddíly disků, řezy, oddíly atd.). Důvodů je mnoho - jak zvýšení výkonu, tak i spolehlivosti a jednoduše úvaha o pohodlnosti - ale o nich teď nebudeme mluvit. Protože v tento moment záleží nám na tom, aby tyto větve stromu souborů byly začleněny do společného systému souborů.

Typická sada adresářů systému POSIX

Ve skutečnosti je pro fungování naprosto nezbytné mít pouze jeden souborový systém - ten, který je připojen v kořenovém adresáři stromu souborů (jakýsi analog světového stromu Yggdrassil). Kořenový adresář a jeho nepostradatelné větve musí představovat jeden souborový systém umístěný na jednom médiu - disk, diskový oddíl, softwarové nebo hardwarové pole RAID nebo logický svazek v chápání LVM. A měla by obsahovat všechny komponenty nutné ke spuštění systému a v ideálním případě nic víc.

Složení kořenového adresáře můžete zobrazit pomocí příkazu

$ ls -1 /

který na jakémkoli systému POSIX zobrazí nějakou minimální gentlemanskou sadu adresářů:

Koš / boot / etc / root / sbin /

Právě v nich jsou shromažďovány všechny soubory, bez nichž systém nemůže existovat. Jiné adresáře jsou něco takového:

Domů / mnt / opt / tmp / usr / var /

Jsou a) nejsou požadovány (alespoň teoreticky - je prakticky obtížné se bez nich obejít), b) ne každý z nich je přítomen ve všech systémech a distribucích a c) každý z nich může být (a často je - pokud děláte vše podle své mysli) bod připojení vlastní větve stromu souborů.

Kromě toho jsou ve většině případů v kořenovém adresáři systému souborů OS kompatibilních s POSIX ještě dva podadresáře:

Vývojář / proc /

Obvykle se jedná o body připojení virtuálních souborových systémů - zařízení a procesy (i když, pokud není použit souborový systém zařízení, adresář / dev musí být součástí kořenového systému souborů. Nakonec v systémech Linux, jako zpravidla je kořenem stromu souborů adresář / lib pro hlavní systémové knihovny a u udev je adresář nevyhnutelný / sys také místem, kde je připojen virtuální souborový systém sysfs.

Kořenový souborový systém

Kořenový souborový systém je nesdílný (to znamená, že není určen ke sdílení různými počítači v síti) a neměnný (to znamená, že v něm může provádět změny pouze správce systému, nikoli však uživatelské programy a navíc ne uživatelé). Kromě toho se velmi nedoporučuje vytvářet v něm podadresáře nad rámec těch, které poskytuje standard (a jsou uvedeny výše).

Vyplnění kořenového systému souborů je vybráno tak, aby počítač mohl spouštět a udržovat minimální funkce i během nouzového spuštění (nebo v režimu pro jednoho uživatele), když nejsou připojeny všechny ostatní systémy souborů (a podle toho jeho větve, jako např. / usr nebo / var nemusí být k dispozici.

V souladu s tím je spuštění počítače zajištěno soubory adresáře / boot a / atd. První obsahuje jádro systému - spustitelný soubor „zvláštního účelu“ - a vše, co je k jeho načtení nutné - například v Linuxu, systémovou mapu (/etc/System.map) a ve FreeBSD, načítatelné jádro moduly. Někdy je však jádro umístěno přímo v kořenovém adresáři systému souborů a poté může adresář / boot úplně chybět a adresář / modules může být vyhrazen pro moduly jádra.

Adresář / etc je určen pro konfigurační soubory celého systému, které určují podmínky pro jeho načtení. Jeho obsah velmi závisí na systému (a v Linuxu - také na distribuční sadě), a proto jej zde nebudu zvažovat - budu se muset k tomuto tématu vrátit více než jednou.

Minimální nezbytnou funkčnost zajišťuje obsah adresářů / bin a / sbin - obsahují spustitelné soubory nejdůležitějších uživatelských a systémových programů, respektive těch, které vám umožní provést komplex oprav a záchranných opatření a po selhání vrátit auto zpět do lidské podoby.

Rozdělení systémových a uživatelských programů na kořenové podadresáře je spíše libovolné. Žádný z těchto příkazů opravdu není určen k řešení problémů uživatelů. Prostě adresář / bin obsahuje administrační příkazy, ke kterým čas od času přistupuje (nebo k nim může přistupovat) běžný uživatel a adresář sbin je určen pro příkazy, o kterých by uživatel neměl vědět. A které ve většině případů stále nebude moci používat kvůli nedostatku příslušných pravomocí (například požadovaných přístupových práv k souborům zařízení).

Chcete-li spouštět programy POSIX (včetně těch, které jsou kompilovány v adresářích / bin a sbin), potřebujete zpravidla přístup k funkcím knihoven celého systému (především k hlavní knihovně glibc). A tak (téměř) nepostradatelnou součástí kořenového adresáře je podadresář / lib, ve kterém jsou sestaveny.

V Linuxu má adresář / lib další důležitý účel - jeho podadresář ( / lib / modules) obsahuje moduly jádra, které lze načíst (ve FreeBSD je jejich místo / boot / kernel).

Ve FreeBSD není adresář / lib v kořenovém souborovém systému - odpovídající komponenty jsou umístěny zde v / usr / lib (viz níže). Důvodem je to, že historicky FreeBSD vybudovala hlavní systémové programy, takže funkce knihoven, které vyžadují, jsou vloženy do jejich spustitelných souborů (nazývaných statické propojení, o nichž bude pojednáno v kapitole 14). Ve FreeBSD jsou 5. větve programy z adresářů / bin a / sbin dynamicky propojeny, to znamená, že při absenci adresáře / usr (a ve Free je téměř vždy samostatnou větví systému souborů) nefungují. Aby to bylo možné kompenzovat, existuje adresář / restore, který překračuje standardy, obsahuje stejné programy, ale je staticky propojen (jak naznačuje název adresáře, jediným účelem jeho obsahu jsou záchranné operace).

Nakonec / root. Toto je obvyklý domovský adresář uživatele se stejným jménem, ​​tj. Správce systému. Protože nevykonává žádnou praktickou práci (nebo by alespoň neměl), jsou jeho obsahem pouze vlastní konfigurační soubory superuživatele (příkazový shell uživatele, oblíbený editor atd.).

Pobočka / usr

Historicky byl adresář / usr určen pro uživatelské programy a data. Tyto funkce jsou nyní rozděleny mezi / usr / local a / home (ačkoli ten druhý je nyní ve FreeBSD ve výchozím nastavení symbolickým odkazem na / usr / home). Adresář / usr - neměnný, ale sdílený - slouží jako úložiště většiny aplikačních programů a všeho, co s nimi souvisí - zdrojový kód, konfigurační soubory, sdílené knihovny, dokumentace a podobně.

Složení adresáře / usr se mezi systémy BSD a Linuxem výrazně liší. V prvním případě obsahuje pouze integrální části operačního systému (ten, který ve FreeBSD spojuje koncept distribucí). Aplikace nainstalované z portů nebo balíčků mají své místo v podadresáři / usr / local, což může představovat samostatnou větev stromu souborů.

V systému Linux slouží adresář / usr jako úložiště pro všechny programy (a jejich součásti) zahrnuté v distribuční sadě. A podadresář / usr / local je obvykle určen pro programy, které jsou nezávisle kompilovány ze zdroje.

V každém případě je obvyklé složení adresáře / usr následující (jak uvádí příkaz ls -1):

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

Jak již bylo zmíněno, podadresář / usr / local je samostatnou větví stromu souborů, a proto bude zvažován samostatně. Účel ostatních adresářů je následující:

• / usr / bin a / usr / sbin jsou určeny pro spustitelné soubory uživatelských a systémových programů (zde je hranice mezi nimi ještě libovolnější než v případě kořenového adresáře), jejichž účel přesahuje zajištění základního fungování systém;
• / usr / etc je pro konfigurační soubory jednotlivých aplikací;
• / usr / include obsahuje takzvané hlavičkové soubory potřebné k propojení spustitelné soubory s knihovními komponentami;
• / usr / lib a / usr / libexec jsou adresáře pro sdílené knihovny, na kterých závisí uživatelské aplikace;
• / usr / share - úložiště nejrozmanitějších, tzv. architektonicky nezávislé komponenty: zde můžete vidět dokumentaci v různých formátech, příklady konfiguračních souborů a data používaná programy pro správu konzoly (písma, rozložení klávesnice) a popis časových pásem;
• / usr / src - adresář zdrojového kódu; v Linuxu je zde obvykle umístěn pouze zdrojový kód jádra (jader) systému, v klonech BSD - úplná sada zdrojových kódů komplexu, který se ve FreeBSD nazývá Distribuce; zde je zpravidla nežádoucí umístit zdroje programů sestavených samostatně;
• / usr / X11R6 - adresář pro součásti okenního systému X - spustitelné soubory ( / usr / X11R6 / bin), knihovny ( / usr / X11R6 / lib), záhlaví ( / usr / X11R6 / include), dokumentace ( / usr / X11R6 / muž); Zde by neměly být umístěny soubory aplikací X (snad kromě správců oken) - jejich místo je v / usr, / usr / local nebo / opt, v závislosti na systému.

Adresář / usr může navíc obsahovat podadresáře / usr / var a / usr / tmp - obvykle symbolické odkazy na odpovídající větve kořenového adresáře. A u některých distribucí Linuxu je hlavní dokumentace celého systému, manuálové stránky (v podadresáři / usr / man), umístěna přímo v / usr.

Nakonec v systémech BSD a některých distribucích Linuxu založených na zdrojích (například Gentoo) obsahuje adresář / usr podadresář pro systém správy balíků - porty FreeBSD a OpenBSD ( / usr / porty), jejich protějšky v jiných systémech ( / usr / portage v Gentoo). Ačkoli z hlediska dodržování litery a ducha standardu FHS (on sám neuvádí ani slovo o portech a podobných systémech), logičtějším místem by pro ně byl adresář / var (viz níže) - a přesně to se dělá v distribucích jako CRUX a Archlinux.

Pobočka / usr / místní

Jak již bylo zmíněno, větev / usr / local v Linuxu je určena pro samostatně kompilované programy ze zdrojů (nejsou součástí této distribuční sady). A na FreeBSD slouží jako domov pro většinu uživatelských aplikací - téměř vše mimo Distribuce a instalováno z balíčků nebo portů. Adresářová struktura jako celek tedy odpovídá struktuře větve / usr (s pochopitelnými výjimkami):

Koš / etc / include / lib / man / sbin / share /

Podobný je i obsah podadresářů: spustitelné soubory programu ( / usr / local / bin a / usr / local / sbin), jejich konfigurace ( / usr / local / atd.), Knihovny, se kterými jsou propojeny, a jejich hlavičkové soubory ( / usr / local / lib respektive / usr / local / include), manuálové stránky ( / usr / local / man) a všechny druhy věcí nezávislých na architektuře ( / usr / local / share), včetně dokumentace v jiných formátech.

/ Volit větev

Adresář / opt je poskytován standardem FHS, ale ve skutečnosti se nepoužívá ve všech distribucích Linuxu a v systémech BSD zcela chybí. Přesto je stále více programů napsáno s očekáváním výchozí instalace.

Historicky byl / opt používán v Linuxu pro komerční aplikace a všechny druhy nesvobodného softwaru. V současné době je jeho účelem hostovat velké samostatné softwarové systémy, jako je knihovna Qt, KDE se všemi součástmi a aplikacemi, OpenOffice.org a podobně. Struktura adresářů by měla být / opt / pkg_name. Takto to vypadá v mém systému (Archlinux):

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

Každý z podadresářů má svou vlastní vnitřní strukturu:

$ 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áněno emailem] podíl / [chráněno emailem] THIRDPARTYLICENSEREADME.html uživatel / / opt / qt: bin / doc / include / lib / mkspecs / fráze / pluginy / šablony / překlady /

Účel podadresářů uvnitř / opt / pkg_name lze snadno uhodnout analogicky s / usr a / usr / local. Například / opt / kde / bin je pro spustitelné soubory systému KDE a jeho aplikací, / opt / kde / etc je pro jeho konfigurační soubory, / opt / kde / include je pro hlavičkové soubory, / opt / kde / lib je pro knihovny a / opt / kde / share - pro sdílené soubory včetně dokumentace. V KDE neexistuje žádná dokumentace ve formátu man, pokud ano, pak (jako v případě Gnome - neinstaloval jsem to, do toho se natáhl Gimp a podobné aplikace Gtk) můžete vidět / opt / pkg_name / podadresář muže.

Vidíte, že adresářová struktura / opt se odchyluje od historicky zavedené (a interně odůvodněné POSIX tradice kombinování komponent stejného typu do adresářů - spustitelných souborů, knihoven atd.) A s velkým počtem programů, které jsou v něm nainstalovány, vytváří určité potíže: musíte buď přetížit proměnnou $ PATH, která poskytuje rychlý přístup k příkazům (o které bude pojednáno v kapitole 12), nebo vytvořit speciální adresář / opt / bin a vložit do něj symbolické odkazy na spustitelné binární soubory programu. , v některých distribucích Linuxu (například v CRUX) / opt se v zásadě nepoužívá. Jako ve všech systémech BSD. Je docela možné, že je to tak lepší ...

/ Větev Var

Jak název napovídá, adresář / var je určen k ukládání měnitelných souborů generovaných během běžného života různých programů - mezipaměti softwaru (například prohlížeče), soubory protokolů, zařazování tisku a poštovní systémy. poštovní schránky, popisy spuštěných procesů atd. Zejména v adresáři / var jsou umístěny takzvané skládky - snímky stavu paměti RAM generované během abnormálního vypnutí, aby se zjistily důvody. Charakteristickým rysem všech těchto komponent je jejich proměnlivá povaha během relace práce a skutečnost, že přesto musí být zachovány při restartu systému.

Vnitřní struktura / var se velmi liší systém od systému, a proto se nebudu pozastavovat nad detaily její struktury. Pouze poznamenám, že tento adresář je logickým místem pro umístění komponentů všech druhů portů podobných systémů pro správu balíků, jak se to děje například v distribuci Archlinux, kde je podadresář / var / abs (abs - Archlinux Building System ) je pro to vyhrazeno.

Adresář / mnt

Adresář / mnt je určen k připojení dočasně používaných souborových systémů, obvykle umístěných na vyměnitelná média... V zavedeném systému je obvykle prázdný a jeho struktura není nijak regulována. Uživatel v něm může volně vytvářet podadresáře pro určité typy médií. Například v mém systému jsou to / mnt / cd, / mnt / dvd, / mnt / usb a / mnt / hd - pro disky CD, DVD, flash disky a vyměnitelné pevné disky.

Ve FreeBSD jsou výchozí adresáře pro připojení CD a disket / cdrom a / floppy přímo v kořenovém adresáři. Což není úplně v souladu se standardem, ale svým způsobem je to logické - připojovací body zařízení, která existují (jako CD ROM) nebo donedávna existovala (disketová mechanika) v jakémkoli počítači, jsou přenesena do kořenového adresáře.

/ Domácí pobočka

Adresář / home slouží k hostování domovských adresářů uživatelů. Jeho obsah není nijak regulován, ale obvykle vypadá jako /home/(username1,...,username#). Ve velkých systémech s velkým počtem uživatelů však lze jejich domovské adresáře seskupit.

Adresář / home může obsahovat domovské adresáře nejen skutečných uživatelů, ale také některých virtuálních uživatelů. Pokud je tedy počítač používán jako webový nebo ftp server, zobrazí se podadresáře jako / home / www nebo / home / ftp.

Větev / tmp

Zbývá mluvit pouze o adresáři pro ukládání dočasných souborů - / tmp. Stejně jako / var komponenty jsou generovány různými programy během jejich normálního života. Ale na rozdíl od / var, / tmp komponenty se neočekávají, že budou uloženy mimo aktuální relaci. Všechny příručky pro správu systému navíc doporučují pravidelně (například při restartování počítače) nebo pravidelně mazat tento adresář. A proto, jako / tmp, je vhodné připojit souborové systémy v RAM - tmpfs (v Linuxu) nebo mfs (ve FreeBSD). Kromě toho, že to zajišťuje vymazání jeho obsahu při restartu, přispívá to také k výkonu, například při kompilaci programů, jejichž dočasné produkty nejsou zapsány na disk, ale jsou umístěny ve virtuálním adresáři jako / tmp / obj.

Na mnoha systémech uvidíte adresáře jako / usr / tmp a / var / tmp. Obvykle se jedná o symbolické odkazy na / tmp.

Strategie dělení systému souborů

Na závěr rozhovoru o hierarchii souborů je třeba zdůraznit, že pouze adresáře uvedené v odstavci Kořenový souborový systém... Všechny ostatní adresáře - / usr, / opt, / var, / tmp a samozřejmě / home mohou představovat body připojení nezávislých souborových systémů na samostatných fyzických médiích nebo jejich oddílech.

Navíc v lokální síť tyto adresáře mohou být dobře umístěny i na různých počítačích. Například jeden počítač fungující jako aplikační server může obsahovat adresáře / usr a / opt v síti, jiný souborový server, který může obsahovat všechny domovské adresáře uživatelů atd.

Zbývá jen rozhodnout, které souborové systémy je vhodné izolovat od společného stromu souborů a proč to udělat. Odpověď na tyto otázky velmi závisí na použitém operačním systému a v případě Linuxu také na jeho distribuci. Přesto lze nastínit obecné principy oddělení souborových systémů. Proč bychom si měli pamatovat na opozici na jedné straně neměnných a měnitelných adresářů, na straně druhé snadno obnovitelných, obtížně obnovitelných a prakticky neobnovitelných dat. Udělejme tento pokus ve vztahu k uživatelské ploše - v případě serveru se výpočty výrazně liší.

Kořenový souborový systém v adresářích / bin, / boot, / etc, / root, / sbin obsahující snadno obnovitelné z distribučních médií a prakticky nezměněná data by zjevně měl ležet na izolovaném diskovém oddílu. V systému Linux by měl být také přidán adresář / lib. Na druhou stranu, když používáte GRUB jako zavaděč (bez ohledu na operační systém), je doporučeno přesunout adresář / boot do samostatného oddílu.

Ve starých zdrojích o Linuxu si můžete přečíst o dalším důvodu přidělení oddílu pro adresář / boot a na úplném začátku disku: kvůli nemožnosti načíst jádro Lilo z čísla válce vyššího než 1023. V moderní verze zavaděčů, taková omezení neexistují. Pokud však vytváříte oddíl pro / boot, má smysl jej nastavit jako první na disk a odkládací oddíl umístit přímo za něj: při provádění swapování to zvýší rychlost o pět kopií.

A také z říše historie: požadavek, aby kořenové a spouštěcí oddíly byly v každém případě primární, byl také již dávno odstraněn. A tyto systémy souborů se mohou dobře hodit na logické oddíly v rámci rozšířeného oddílu.

Stejně tak je jasné, že proměnlivé větve systému souborů - / var a / tmp - musí být přesunuty mimo kořenový oddíl. Navíc, jak již bylo mnohokrát řečeno, je obecně vhodné umístit jej na souborový systém v paměti RAM (tmpfs nebo mfs). V případě, že adresář / var obsahuje podadresáře pro portové systémy pro správu balíčků, jako / var / abs, / var / cache / pacman / src a / var / cache / pacman / pkg v Archlinuxu, měly by také vytvořit vlastní soubor systémy.

Nyní adresář / usr, který obsahuje buď komponenty základního systému (jako v BSD), nebo většinu uživatelských aplikací (jako ve většině distribucí Linuxu). Obsahuje snadno obnovitelná data a z dobrého důvodu by měl být prakticky neměnný, a proto si samozřejmě zaslouží zdůraznění v nezávislé sekci. Kromě toho je vhodné z jeho složení izolovat na jedné straně podadresáře / usr / X11R6 a / usr / local, na druhé straně podadresáře pro systémy správy balíčků podobné portům: / usr / porty, / usr / pkgsrc a / usr / pkg v systémech BSD., / usr / portages na Gentoo Linux atd. Kromě toho by měly být odděleny podadresáře pro umístění zdrojů stažených ze sítě při vytváření portů - / usr / porty / distfiles, / usr / pkgsrc / disfiles, / usr / portages / distfiles a podobně.

V systémech BSD má navíc smysl oddělit z adresáře / usr podadresáře / usr / src a / usr / obj, které obsahují zdroje základních komponent (včetně jádra) a jejich kompilační meziprodukty, které jsou generované postupy make buildworld a make buildkernel ...

Nakonec adresář / home, který obsahuje nestálá a často neobnovitelná data, musí být bez problémů odstraněn z kořenového adresáře hierarchie souborů. A vždy se to snažím umístit buď na samostatný plátek (v BSD), nebo na primární oddíl (v Linuxu).

Navrhované schéma rozdělení systému souborů se může zdát příliš komplikované. Zaručuje však izolaci snadno obnovitelných, těžko obnovitelných a neobnovitelných dat, což usnadňuje přeinstalaci systému v případě nouze a dokonce i migraci ze systému do systému.

Jeho dalším plusem je, že pro jednotlivé větve stromu souborů, v závislosti na povaze dat na něm umístěných, v Linuxu můžete zvolit fyzicky optimální souborový systém. Například nemá smysl používat pro oddíl pod / boot nic jiného než Ext2fs. Obecně se doporučuje formátovat kořenový oddíl pomocí zabezpečeného a přesto nejkompatibilnějšího Ext3fs. Pro adresáře s velkým množstvím malých souborů, jako jsou / var / abs v Archlinuxu, / usr / portages v Gentoo, je vhodné použít ReiserFS: koneckonců dovedná manipulace s malými soubory je jeho profilem. A v adresáři / home, kde se mohou objevit obrovské multimediální soubory (a které jsou samy o sobě obvykle velmi velké), může XFS přijít na kurt (i když, jak ukazují měření, ReiserFS zde vypadá docela slušně). Taková opatření mohou zlepšit jak spolehlivost ukládání dat, tak rychlost operací se soubory.

Uživatelé operačních systémů BSD jsou vázáni na souborové systémy FFS bez jakékoli alternativy. Mají však také manévrovací prostor. Za prvé změnou velikosti bloku a fragmentu jednotlivých souborových systémů, což přispívá buď k výkonu operací na disku, nebo k úspoře místa na disku. A za druhé, některé větve stromu souborů (jako / tmp nebo / usr / obj, na rozdíl od doporučení, lze nebojácně připojit v čistě asynchronním režimu a získat tak procentuální nebo jiný výkon.

O normách obecně

Mezi praktikujícími programátory existuje názor, že standardy v programování nejsou vůbec potřeba, protože:

(1) zpočátku nemají smysl, protože jejich autoři nepíší počítačové programy;

(2) spoutávají iniciativu programátorů;

(3) programátoři budou vždy souhlasit bez standardů.

Možná by tomuto názoru neměla být věnována pozornost, nebýt dvou okolností:

(1) vyjadřují to praktici, tedy přesně ti, kteří „vydávají software“;

(2) Výše uvedené úvahy objevil autor tohoto článku v jedné z publikací na internetu věnovaných standardu pro programovací jazyk C, ze kterých vyšlo najevo, že takový názor je rozšířený „v mezinárodním měřítku“, a nejen mezi arogantními ruskými „super programátory“.

Slovo „standard“ je obvykle spojeno s něčím hmotným (standardní rozměry, standardní elektrické napětí atd.), Zatímco počítačový program je nehmotný předmět („nový nehmotný“) a možná jsou standardy v nehmotné sféře skutečně bezvýznamné?

Existuje však vyvracející příklad. Soubor pravidel pravopisu ruského jazyka je v zásadě standardem, i když není schválen normalizačními orgány. Kromě pravidel (nebo chcete -li požadavků) pravopisu existují ještě syntaktická pravidla a hlavně sémantika. Poslední dobře ilustruje „dětskou“ otázku: proč se kočce říká kočka? Na tuto otázku existuje přesná odpověď: protože naši předkové s tím souhlasili; předkové Britů souhlasili, že budou říkat stejné šelmě, předkové Němců - kotě atd. A obecně platí, že význam nebo sémantika nebo pravidla výkladu jakéhokoli slova nebo kombinace slov je věcí dohody.

Účel a „super úkol“ standardu POSIX

Jak název napovídá, POSIX (Portable Operating System Interface) je standard pro rozhraní (rozhraní) mezi operačním systémem a aplikačním programem. Doby, kdy programátoři psali programy pro „holý“ stroj (implementace vlastních balíčků vstupních / výstupních programů, goniometrické funkce atd.), Jsou nenávratně pryč. Text POSIX opakovaně zdůrazňuje, že norma neklade žádné požadavky na podrobnosti implementace operačního systému; lze jej považovat za soubor dohod mezi aplikačními programátory a vývojáři operačních systémů. POSIX tedy (opět na rozdíl od dosti rozšířeného názoru) zajímá nejen vývojáře operačních systémů, ale především mnohem početnější kategorii programátorů - aplikovaných.

Potřeba standardu tohoto druhu byla uznána již v 80. letech minulého století, kdy se rozšířily operační systémy UNIX. Ukázalo se, že ačkoli byl tento systém koncipován jako jednotný systém, rozdíly mezi jeho konkrétními implementacemi vedly k tomu, že aplikační programy napsané pro jeden systém nelze vždy spouštět v jiném. Právě na tento problém, známý jako problém s přenositelností softwaru, se POSIX snaží řešit. První vydání standardu bylo vydáno v roce 1988 (existuje překlad, viz), ve kterém byla celá řada problémů souvisejících s přenositelností programu rozdělena do dvou částí: (1) rozhraní aplikačního programu, (2) interpret příkazů a nástroje (uživatelské rozhraní); tyto části se nazývají POSIX.1 a POSIX.2.

Ujasněme si, že v tomto článku budeme hovořit pouze o standardu pro rozhraní aplikačního programu POSIX.1, jehož druhé (a zatím poslední) vydání bylo schváleno 12. července 1996.

Informativní část normy také zdůrazňuje, že POSIX není popisem rozhraní nějakého „ideálního“ operačního systému, ale výsledkem zobecnění a systematizace zkušeností získaných při vývoji operačních systémů UNIX. POSIX také nemůže sloužit jako průvodce nebo studijní průvodce na operačních systémech, přestože informativní část obsahuje doporučení pro programátory a fragmenty programů.

Norma přímo uvádí, že není možné vytvořit plnohodnotný operační systém se zaměřením pouze na funkce rozhraní, které jsou v něm popsány. (POSIX.1 zejména neřeší problémy, jako je síť a související funkce rozhraní nebo grafické rozhraní.) Finanční náklady spojené s nehybností programů a z toho vyplývající potřeba sjednocení rozhraní jsou tak velké, že většina prodejců dává přednost alespoň nějaký standard, než žádný mít. Z tohoto důvodu se mnoho vývojářů softwaru zaměřuje na POSIX. To umožňuje, ne -li zcela eliminovat nehybnost programů, pak alespoň výrazně snížit nehybnou část programu.

O sémantice

Jak již bylo zmíněno dříve, POSIX lze považovat za sadu dohod mezi vývojářem operačního systému a programátorem aplikace. „Dohoda“ znamená v první řadě stejný výklad (sémantiku) slov a výrazů. Následující příklady ilustrují obtížnost dosažení „dohody“.

Jak předat význam v překladu

Nejprve je třeba připomenout, že standard POSIX je napsán v angličtině, což ze své podstaty vyvolává nejednoznačnost (například stejné slovo může být podstatné jméno, přídavné jméno a sloveso) a „sémantické pasti“ na ně číhají téměř každou stránku. Dobrá ilustrace toho, co bylo řečeno, je příkladem z beletrie. Jedno z nejslavnějších děl Oscara Wilda, který tuto funkci skvěle využil anglického jazyka, - Důležitost bytí Earnest - v ruštině známý jako „Důležitost bytí Earnest“. ale anglické jméno má druhý význam: Earnest (vážný) je jméno jedné z postav a jméno by se dalo přeložit jinak: „Jak důležité je být Ernstem.“ Existuje ruské příjmení Serebryany a pokud by existovalo příjmení Vážné, překlad by byl naprosto přesný, s přenesením obou významů.

Podobná je situace se samotným názvem standardu: Rozhraní přenosného operačního systému. Adjektivum Portable (mobilní) odkazuje jak na operační systém, tak na aplikační program, ale v ruštině jej nelze vyjádřit tak stručně, lze jej přeložit jako „Rozhraní mobilního operačního systému“ nebo „Rozhraní operačního systému, který poskytuje mobilita aplikačních programů “. Druhá možnost lépe odráží záměry vývojářů standardu, ale zároveň se ztrácí první význam (při překladu byla zachována známější první možnost).

Sémantika slova „standard“

Hlavnímu textu normy předchází preambule, která vysvětluje význam slov IEEE Standards2. Jak vyplývá z těchto vysvětlení, existují nejméně tři sémantické rozdíly od ruského výrazu GOST:

(1) Intuitivně se věří, že GOST má sílu zákona, jehož porušení je stíháno; POSIX je soubor požadavků, jejichž dodržování je zcela dobrovolné.

(2) GOST platí do zrušení (mnozí pravděpodobně slyšeli výraz „GOST nebyl zrušen“); preambule POSIX říká, že pokud norma nebyla revidována po dobu 5 let, znamená to, že problémy v ní diskutované pravděpodobně ztratily svůj význam a lze ji považovat za zrušenou automaticky;

(3) GOST je anonymní; úvodní část POSIXu poskytuje seznam těch, kteří se podíleli na vývoji tohoto standardu, a také uvádí adresu, na kterou lze zasílat žádosti o tlumočení; rovněž uvádí, že odpověď na každou žádost podléhá schvalovacímu postupu (jinými slovy, autoři normy se před odpovědí dohodnou).

Překlad i tak známého slova jako Standard slovem „standard“ vyžaduje komentáře.

Sémantika slov „by měla“, „není specifikována“, „není definována“, „je definována implementace“

Oddíl 2 normy se nazývá Terminologie a obecné požadavky. Obsahuje definice nejen speciálních termínů (jako „proces“ nebo „semafor“), ale také zdánlivě samozřejmá slova jako „měl by“ nebo „může“. Protože je POSIX.1 standardem rozhraní, jeho požadavky platí jak pro operační systém, tak pro aplikační program. Výslovný požadavek je vyjádřen slovem „musí“, například: „Pokud je úspěšné, funkce link () musí vrátit nulu.“ V tomto případě mluvíme o požadavku operačního systému: funkci link () je nutné implementovat tak, aby při úspěchu vrátila nulu.

Termíny „nespecifikováno“ a „není definováno“ vyjadřují stejnou myšlenku, že standard umožňuje svobodu volby, ale význam těchto termínů je odlišný. Pojem „není specifikován“ znamená, že mluvíme o nějakých správných (akce, konstrukce programu atd.), A termín „není definován“ - o nesprávných (chybných). Informativní část normy poskytuje následující vysvětlení.

Termín „nespecifikovaný“ znamená, že se předpokládá, že jsou známy různé možnosti (výsledky, výsledky volání funkce atd.), A norma umožňuje jakoukoli z nich; v konkrétní implementaci operačního systému může být vybrán jakýkoli a takový systém je považován za v souladu s normou. Aplikační program (přísně odpovídající standardu) musí být napsán tak, aby správně fungoval v jakékoli variantě; termín jako takový implicitně vyjadřuje požadavek na aplikační program.

Uveďme příklad: „Funkce readdir () by měla vrátit ukazatel na strukturu, která odkazuje na další prvek adresáře. Zda jsou či nejsou vráceny katalogové položky s názvem "bod" a "bod-bod", standard nestanovuje. " V tomto případě existují čtyři možné výsledky a požadavek na aplikaci je, že musí být navržen pro jakýkoli z nich.

Další příklad: „Pokud je funkce sigwait (), která dává pokyn čekat na signál se zadaným číslem, vyvolána v několika řídicích vláknech, pak když signál dorazí do více než jednoho z nich, musí se sigwait () vrátit. Ve kterém druhu toku řízení k tomu dojde, není standardem stanoveno. “ V tomto příkladu může být mnohem více možných výsledků, ale všechny jsou také známé a požadavek pro aplikaci je, že musí správně fungovat pro jakýkoli výsledek.

Termín „není definován“ znamená, že ani mnoho výsledků není známo, jakýkoli výsledek je možný, dokonce katastrofický (například selhání systému, ztráta dat atd.). Tento termín v podstatě implicitně vyjadřuje požadavek, aby aplikační program nepoužíval odpovídající data nebo konstrukce. Například: "Pokud argument dirp readdir () neodkazuje na aktuálně otevřený adresář, výsledek není definován."

Tento příklad vyžaduje, aby aplikace nahradila argument funkce readdir () pouze odkazem na otevřený adresář; porušení tohoto požadavku může mít katastrofální důsledky a odpovědnost za to nese aplikační programátor.

Zde je další příklad: „V případě úspěchu by funkce read () měla vrátit celé číslo představující počet skutečně načtených bytů. V opačném případě musí funkce přiřadit chybový kód errno a vrátit -1 a obsah vyrovnávací paměti, na kterou odkazuje buf, není definován. "

Norma zakazuje použití dat z vyrovnávací paměti v aplikačním programu v případě chyby ve funkci read () a důsledky porušení tohoto požadavku jsou přiřazeny aplikačnímu programátorovi.

Význam pojmu „definovaný implementací“ se liší od intuitivního. Je zřejmé, že v konkrétním operačním systému nemůže být žádný „nespecifikovaný“ nebo „nedefinovaný“ výsledek, nějaký konkrétní výsledek bude získán bez selhání. Termín „definovaný implementací“ vyjadřuje požadavek normy na dokumentaci operačního systému: výsledek musí být nejen specifikován (vývojář operačního systému to stejně bude muset udělat), ale také se výslovně promítne do systémové dokumentace.

Výchozí sémantika

Ani jeden regulační dokument nemůže pokrýt celou škálu případů, které se mohou v praxi vyskytnout, takže o něčem nevyhnutelně mlčí3. Například popis funkce může říkat, že její argument může nabývat hodnot z určitého rozsahu, ale není řečeno nic o tom, jaký bude výsledek, pokud argument nespadá do tohoto rozsahu. Je zřejmé, že aby se předešlo nedorozuměním, je nutné mít jednotnou výchozí sémantiku. V informativní části standardu je zajímavá fráze: „obecně přijímaná sémantika defaultu je zakázána“. Toto tvrzení je v rozporu se známým deset let starým sloganem „vše je dovoleno, co není výslovně zakázáno“. Zjevně je to v hlavách občanů tak zakořeněno, že mnoho, dokonce i programátorů, s citovaným prohlášením normy nesouhlasí. Mezitím, pokud použití jakéhokoli konstruktu není výslovně povoleno a nevyplývá to z popisu, pak si jakýkoli cvičný programátor uvědomí, že jeho použití je riskantní, a pokud to nefunguje, nenapadne ho uplatnit nárok.

Procesy a toky řízení

Oba tyto termíny vyjadřují myšlenku paralelního provádění. Operační systém UNIX byl původně koncipován jako víceuživatelský a programy spuštěné různými uživateli musí být navzájem bezpečně izolovány, aby náhodou nezkreslovaly data „někoho jiného“. Tuto izolaci zajišťuje skutečnost, že uživatelský program je spuštěn v rámci procesu, který se vyvíjí ve vlastním virtuálním adresním prostoru. I když program obsahuje globální data, při spuštění v různých procesech budou automaticky „rozvedena“ do různých adresních prostorů.

Procesní mechanismus však není při programování úloh v reálném čase zcela uspokojivý. Aplikaci v reálném čase (spuštěnou jménem stejného uživatele) lze často přirozeně reprezentovat jako souběžně provádějící části nazývané „vlákna“. Jejich nejvýznamnějším rozdílem od procesů je, že všechny řídicí toky se vyvíjejí v jednom adresním prostoru; to poskytuje rychlý přístup ke globálním datům, ale zároveň existuje riziko jejich neúmyslného zkreslení a aby se tomu zabránilo, je nutné dodržovat nějakou programátorskou disciplínu. Příslušná doporučení jsou obsažena v informativní části normy.

Je třeba zdůraznit, že myšlenka multithreadingu je implementována v mnoha operačních systémech pracujících v reálném čase a je implementována různými způsoby v tom smyslu, že každé řídicí vlákno má jinou sadu atributů a funkcí rozhraní; někdy se místo vlákna používá výraz task. Aby nedošlo k záměně, norma zdůrazňuje, že se zabývá výhradně vlákny POSIX a názvy odpovídajících funkcí rozhraní mají předponu pthread_ (například pthread_create (), pthread_join () atd.).

Shoda se standardem. Sémantika slova „zápas“

Intuitivně se věří, že pokud jsou dvě položky vyrobeny podle stejné normy, pak se zaručeně vzájemně „spojí“ a budou spolupracovat ve dvojicích; to je přesně účel zavedení standardu rozhraní (rozhraní). Protože je POSIX standardem pro rozhraní, můžeme hovořit o souladu se standardem operačního systému i aplikačního programu.

Standard POSIX.1 obsahuje několik stovek (ne -li tisíc) požadavků; považuje se za samozřejmé, že pokud alespoň jeden z nich není splněn, pak systém (nebo aplikační program) nevyhovuje normě. Současně bylo dosud napsáno tolik operačních systémů a aplikačních programů třídy UNIX, že je stěží rozumné požadovat plnou shodu v uvedeném smyslu. Obtíže při vývoji mezinárodního standardu tohoto druhu zhoršuje existence různých národních jazyků. I když zapomeneme na aplikační programy určené pro zpracování textů v národních jazycích, téměř každý aplikační program musí vydávat nějaký druh diagnostických zpráv a / nebo vnímat texty zadané operátorem.

• přísné dodržování standardu POSIX.1;
• soulad s mezinárodní verzí POSIX.1;
• soulad s národní verzí POSIX.1;
• Soulad POSIX.1 s rozšířeními.

Za druhé, mnoho zařízení rozhraní je volitelných; Standard vyžaduje, aby se funkce volitelného rozhraní chovaly buď tak, jak je předepsáno normou, nebo vždy vrátily speciální chybový kód ENOSYS (což znamená, že funkce není implementována). Volitelná zařízení jsou rozdělena do několika skupin, z nichž každá odpovídá nějaké konfigurační konstantě, která je deklarována (příkazem #define) v odpovídajícím souboru záhlaví; to umožňuje zjistit, zda byla funkce implementována během fáze kompilace.

Popsaný způsob dosažení mobility nevymysleli autoři POSIX, ale v praxi se dlouhodobě používá; v mnoha operačních systémech se pro identifikaci samotného systému nebo jeho verze používají konfigurační konstanty. A zde standard nenabízí nic zásadně nového, ale pouze systematizuje stávající praxi.

Předměty normalizace a struktura normy

Stručně řečeno, standardizační objekty POSIX.1 jsou názvy a sémantika. Konkrétněji hovoříme o následujícím.

• Názvy funkcí rozhraní. Standardizováno je 357 funkcí, přičemž 107 funkcí je převzato ze standardních knihoven C (matematické, zpracování řetězců, vstup / výstup atd.); tyto funkce jsou považovány za součást standardu POSIX.1, ale jsou Plný popis obsažená ve standardu pro programovací jazyk C.
• Názvy systémových datových typů. Tato jména mají příponu _t.
• Názvy souborů záhlaví a minimální složení těchto souborů.
• Globální názvy globálních proměnných v celém systému (například errno).
• Symbolické názvy chybových kódů, které lze nastavit během provádění funkce. Tato jména začínají písmenem E (EPERM, ENOTEMPTY atd.).
• Názvy konstanty konfigurace. Tyto názvy mají předponu _POSIX_.
• Symbolické názvy čísel signálů; tato jména mají předponu SIG. Kromě 20 „tradičních“ signálů (SIGABRT, SIGALRM atd.) Jsou standardizovány signály v reálném čase, jejichž čísla musí zabírat určitý souvislý rozsah od SIGRTMIN po SIGRTMAX včetně, obsahující alespoň čísla RTSIG_MAX.
• Symbolické názvy odpovídající hodnotám jednotlivých argumentů některých funkcí (například argument cmd funkce fcntl () může nabývat hodnot F_DUPFD, F_GETFD, F_GETLK atd.).
• Názvy maker, konstanty, bitové příznaky, proměnné prostředí.

Obecně se norma skládá ze dvou velkých částí přibližně stejného objemu. První polovina - normativní část - obsahuje požadavky a doporučení normy (18 oddílů), druhá - informativní část - obsahuje přílohy, které poskytují seznam odkazů, komentářů a vysvětlení normativní části, složení záhlaví soubory, příklad profilu („projekce“) standardu (pro Dánsko), charakteristiky a metodika měření výkonu nejdůležitějších funkcí a také popis dalších funkcí rozhraní pro práci se soubory v reálném čase; očekává se, že v budoucích vydáních normy budou tyto funkce zahrnuty do normativní části.

Postranní panel „Souhrny klauzulí standardu“ poskytuje představu o tom, na jaké typy služeb operačního systému se norma vztahuje.

Závěr

Hlavní náplní standardu POSIX je sémantika funkcí rozhraní. Standardizace sémantiky sama o sobě není jednoduchá záležitost (každý ví, jak těžké je dosáhnout dohody i pro dvě osoby) a potíže ještě zhoršuje skutečnost, že programování se v současné době věnuje mnoho lidí. Paradigma souběžnosti je například vyjádřeno výrazy jako „proces“, „úkol“ a „řídicí tok“, ale z hlediska praktického programování „úkol“ v operačním systému IBM OS / 360 a v reálném časový operační systém VxWorks není stejný. a také. Dalším příkladem jsou semafory. Semafory jsou binární, celočíselné („s počítadlem“) a vzájemné vyloučení (které mimochodem programátoři mezi sebou nazývají „mutexy“, spontánně se snažící vyhnout se nedorozuměním). A celočíselné semafory, například v operačním systému VxWorks, nejsou vůbec stejné jako semafory POSIX.

Autoři standardu POSIX, dobře si vědomi toho, jak obtížné je přimět lidi opustit své návyky (kterým říkají „zavedená praxe“), prohlašují, že sestavili ucelený a minimální systém funkcí rozhraní pokrývající většinu služeb tradičně poskytovaný operačním systémem, podrobně popsal přesnou sémantiku těchto funkcí a vyzval všechny, aby je používali při svém vývoji4.

Při čtení normy má člověk někdy dojem, že některé formulace měly jediný účel: nevyjmout některé aplikační programy nebo operační systémy z kategorie splňující normu. Takový cíl byl skutečně stanoven a výslovně formulován v úvodu: norma by měla co nejvíce zohledňovat převládající praxi. Hlavním cílem však stále je zajistit mobilitu aplikačních programů.

O autorovi

Sergej Romanyuk - vedoucí vědecký pracovník Výzkumného ústavu pro systémový výzkum, vedoucí skupiny standardních překladačů POSIX. Lze jej kontaktovat e -mailem na adrese: [chráněno emailem]

1 Je třeba dodat, že práce na standardu probíhají již mnoho let; jsou identifikovány nové problémy a jsou buď zahrnuty v jedné ze stávajících částí, nebo formalizovány jako samostatná část, kterou lze následně zrušit. Stalo se to například u front-endových zařízení v reálném čase, která byla původně deklarována jako POSIX.4 a později zahrnuta do POSIX.1.

2 IEEE je organizace, která vyvinula standard POSIX.

3 Zde „výchozí“ znamená tichý, nikoli výchozí; nemluvíme o žádných implikovaných hodnotách, které jsou ve skutečnosti deklarovány, ale o absenci referencí vůbec.

4 Ruský překlad normy bude zveřejněn počátkem roku 2000.

Literatura

Mezinárodní norma ISO / IEC 9945-1 (ANSI / IEEE Std 1003.1), druhé vydání. 1996-07-12. Informační technologie - Rozhraní přenosného operačního systému (POSIX) - Část 1: Rozhraní aplikačního programu systému (API).

M.I. Belyakov, Yu.I. Rabover, A.L. Fridman. Mobilní operační systém. Adresář. Moskva, „Rádio a komunikace“, 1991.

ISO / IEC 9899: 1990, Programovací jazyky- C.

Sekce 1	- Úvod
Sekce 2	- Terminologie a definice
Oddíl 3	- Funkce pro správu procesů (vytváření, nahrazování obrazu, dokončování) a signálů (správa masek, reakce na signály)
Oddíl 4	- Identifikace (procesy, uživatelé, systém, terminál), dotazování času stráveného prováděním procesu, dotazování proměnných prostředí.
Oddíl 5	- Správa souborů a adresářů
Oddíl 6	- Vstupní a výstupní funkce
Oddíl 7	- Funkce ovládání terminálu
Oddíl 8	- Funkce vypůjčené ze standardu jazyka C.
Oddíl 9	- Přístup k databázím uživatelů a skupin uživatelů
Oddíl 10	- Datové formáty pro archivaci a výměnu (tar a cpio)
Oddíl 11	- Synchronizační zařízení: semafory, mutexy a proměnné podmínek
Oddíl 12	- Funkce správy paměti: připnutí a odpojení adresního prostoru procesu, mapování souborů do paměti, ochrana paměti, sdílená paměť
Oddíl 13	- Funkce související s procesem plánování a řídicími toky
Oddíl 14	- Správa hodin a časovače
Oddíl 15	- Správa fronty zpráv
Oddíl 16	- Základní funkce související s řízením toků
Oddíl 17	- Data specifická pro vlákna
Oddíl 18	- Prostředky ničení kontrolních toků

Předmět: Operační systémy.
Otázka: č. 8

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

Principy konstrukce OS:

1.) Princip modularity- modulem se obecně rozumí funkčně úplný prvek systému vytvořený v souladu s přijatými intermodulárními rozhraními. Podle své definice modul předpokládá schopnost snadno jej nahradit jiným za předpokladu, že jsou k dispozici určená rozhraní. Rozdělení systému na moduly je do značné míry určeno použitou metodou návrhu OS (zdola nahoru nebo naopak).

Privilegované, znovu vstupující a znovu vstupující moduly jsou zvláště důležité při budování OS (opětovné oprávnění je doslova opětovné oprávnění; speciální výraz pro označení stavu programu; vlastnost programu, který se má správně spustit, když dojde k rekurzivnímu (vrácenému) volání z přerušení).

Největší efekt z použití tohoto principu je dosažitelný v případě současného rozšíření tohoto principu na OS, aplikační programy a hardware.

2.) Princip funkční selektivity- určitá část důležitých modulů je přidělena v operačním systému, který musí být neustále v paměti RAM, aby byla efektivnější organizace výpočetního procesu. Tato část se v operačním systému nazývá jádro, protože je základem systému. Při vytváření složení jádra je třeba vzít v úvahu dva protichůdné požadavky. Na jedné straně by do jádra měly být zahrnuty nejčastěji používané systémové moduly, na druhé straně by počet modulů měl být takový, aby velikost paměti obsazené jádrem nebyla příliš velká. Kromě softwarových modulů, které jsou součástí jádra a jsou trvale umístěny v paměti RAM, může existovat mnoho dalších modulů systémového softwaru, které se nazývají tranzit. Tranzit softwarové moduly načten do RAM pouze v případě potřeby a v nepřítomnosti volný prostor mohou být nahrazeny jinými přepravními moduly.

3.) Princip generovatelnosti OS: Podstata principu spočívá v organizaci (volbě) takové metody pro úvodní prezentaci programu centrálního řízení systému OS (jádra a hlavních komponent trvale sídlících v RAM), což umožnilo přizpůsobit tuto část dohledu nad systémem na základě konkrétní konfigurace konkrétního výpočetního komplexu a rozsahu úkolů, které je třeba vyřešit. Tento postup se zřídka provádí před dostatečně dlouhou dobou provozu operačního systému. Proces generování se provádí pomocí speciálního generátorového programu a příslušného vstupního jazyka pro tento program, který umožňuje popsat softwarové možnosti systému a konfiguraci stroje. Výsledkem generace je plná verze OS. Vygenerovaná verze operačního systému je sbírka systémových sad modulů a dat.

4.) Princip funkční redundance: Tato zásada zohledňuje možnost provádění stejné práce různými prostředky. Operační systém může zahrnovat několik typů monitorů (moduly dohledu, které řídí jeden nebo jiný typ zdroje), různé způsoby organizace komunikace mezi výpočetními procesy. Přítomnost několika typů monitorů, několika systémů pro správu souborů umožňuje uživatelům rychle a nejvhodněji přizpůsobit OS konkrétní konfiguraci výpočetního systému, zajistit co nejefektivnější načítání hardwaru při řešení konkrétní třídy problémů, získat maximum výkon při řešení dané třídy problémů.

5.) Princip virtualizace: konstrukce virtuálních zdrojů, jejich distribuce a využití se v současné době používá téměř v každém OS. Tento princip vám umožňuje reprezentovat strukturu systému ve formě konkrétní sady plánovačů procesů a alokátorů zdrojů (monitorů) a používat jediné centralizované schéma přidělování zdrojů.

Nejpřirozenějším a nejúplnějším projevem konceptu virtuality je koncept virtuální stroj ... Virtuální stroj poskytovaný uživateli reprodukuje architekturu skutečného stroje, ale architektonické prvky v této reprezentaci se objevují s novými nebo vylepšenými charakteristikami, které zpravidla zjednodušují práci se systémem. Charakteristiky mohou být libovolné, ale nejčastěji uživatelé chtějí mít svůj vlastní „ideální“ stroj z hlediska architektonických charakteristik v následujícím složení:

- virtuální paměť prakticky neomezeného objemu, jednotná z hlediska logiky provozu.

- libovolný počet virtuálních procesorů schopných pracovat paralelně a interagovat během provozu.

- libovolný počet externích virtuálních zařízení schopných pracovat s pamětí virtuálního stroje paralelně nebo postupně, asynchronně nebo synchronně s ohledem na provoz jednoho nebo druhého virtuálního procesoru, který iniciuje provoz těchto zařízení.

Jedním z aspektů virtualizace je organizace možnosti spuštění v daném OS aplikace, které byly vyvinuty pro jiné OS. Jinými slovy, mluvíme o organizaci několika operačních prostředí.

6.) Princip nezávislosti programů na externích zařízeních: tento princip je nyní implementován v drtivé většině operačních systémů pro obecné účely. Poprvé byla tato zásada nejkonzistentněji implementována v operačním systému UNIX. Je také implementován ve většině moderních operačních systémů pro počítače. Tento princip spočívá ve skutečnosti, že propojení programů s konkrétními zařízeními se neprovádí na úrovni vysílání programu, ale během plánování jeho provádění. V důsledku toho není nutná rekompilace, když je program spuštěn s novým zařízením, na kterém jsou data umístěna.

7.) Princip kompatibility: jedním z aspektů kompatibility je schopnost OS spouštět programy napsané pro jiný OS nebo pro dřívější verze tohoto OS, stejně jako pro jinou hardwarovou platformu. Otázky je nutné oddělit binární kompatibilita a kompatibilita zdroje aplikace.

Binární kompatibility je dosaženo, když můžete vzít spustitelný program a spustit ho na jiném OS. To vyžaduje kompatibilitu na úrovni instrukcí procesoru a kompatibilitu na úrovni systémových volání a dokonce i na úrovni volání knihoven, pokud jsou dynamicky propojena.

Kompatibilita se zdroji vyžaduje vhodný překladač v systémovém softwaru a také kompatibilitu knihoven a systémových volání. V tomto případě je nutné překompilovat stávající zdrojové texty do nového spustitelného modulu.

Je mnohem obtížnější dosáhnout binární kompatibility mezi procesory založenými na různých architekturách. Aby jeden počítač mohl spouštět programy jiného (například program pro počítač, jako je počítač IBM, je žádoucí spustit na počítači, jako je Apple Macintosh), musí tento počítač pracovat s pokyny počítače, které původně rozumět. V takovém případě se musí spustit procesor 680x0 (nebo PowerPC) binární kód určené pro procesor i80x86. Procesor 80x86 má vlastní dekodér instrukcí, registry a vnitřní architekturu. Procesor 680x0 nerozumí binárce 80x86, takže musí vybrat každý příkaz, dekódovat jej a určit, zda

co má dělat, a poté proveďte ekvivalentní podprogram napsaný pro 680 × 0.

Jedním ze způsobů zajištění kompatibility softwaru a uživatelských rozhraní je dodržování standardů POSIX, jejichž použití vám umožňuje vytvářet programy ve stylu UNIX, které lze později snadno přenášet z jednoho systému do druhého.

8.) Princip otevřenosti a škálovatelnosti: Otevřený operační systém je k dispozici pro analýzu jak uživatelům, tak systémovým specialistům, kteří udržují počítačový systém. Rozšiřitelný (modifikovatelný, vyvinutý) OS umožňuje nejen využívat možnosti generování, ale také zavádět nové moduly do svého složení, vylepšovat stávající atd. Jinými slovy, mělo by být možné snadno provádět doplňky a změny podle potřeby, aniž by byla ohrožena integrita systému. Přístup klient-server ke strukturování OS pomocí mikro-jaderné technologie poskytuje vynikající příležitosti pro expanzi. V souladu s tímto přístupem je operační systém vytvořen jako sada privilegovaných řídicích programů a sada neprivilegovaných služeb (serverů). Hlavní část operačního systému zůstává nezměněna a současně lze přidávat nové servery nebo vylepšovat staré. Tento princip je někdy interpretován jako rozšiřitelnost systému.

9.) Princip mobility: operační systém by měl být relativně snadno přenosný

připojit se z jednoho typu procesoru k jinému typu procesoru a z hardwarové platformy jednoho typu, která zahrnuje spolu s typem procesoru a způsobem organizace veškerého počítačového hardwaru (architektura počítačového systému) další typ hardwarové platformy . Všimněte si toho, že princip přenositelnosti je velmi blízký principu kompatibility, i když se nejedná o totéž. Psaní přenosného operačního systému je podobné psaní jakéhokoli přenosného kódu, ale musíte se jím řídit pravidla:

- většina operačního systému by měla být spuštěna v jazyce, který je k dispozici ve všech systémech, do kterých se plánuje pozdější přenesení. To v první řadě znamená, že OS musí být napsán v jazyce vysoká úroveň, přednostně standardizovaný, například v C. Program napsaný v sestavě není obecně přenosný.

- je důležité minimalizovat nebo, je -li to možné, vyloučit ty části kódu, které přímo interagují s hardwarem. Hardwarová závislost může mít mnoho podob. Některé zjevné formy závislosti zahrnují přímou manipulaci s registry a jiným hardwarem. Konečně, pokud nelze kód závislý na hardwaru zcela vyloučit, měl by být izolován v několika dobře lokalizovaných modulech. Hardwarově závislý kód nemusí být distribuován v celém systému. Můžete například skrýt hardwarově závislou strukturu v programovatelném abstraktním datovém typu.

Zavedení standardů POSIX bylo zaměřeno na zajištění přenositelnosti vytvořeného softwaru.

10.) Princip zabezpečení počítače: Zajištění výpočetního zabezpečení je žádoucí pro každý víceuživatelský systém. Pravidla zabezpečení definují vlastnosti, jako je ochrana zdrojů jednoho uživatele před ostatními a nastavení kvót prostředků, aby jeden uživatel nemohl převzít všechny systémové prostředky, například paměť.

Zajištění ochrany informací před neoprávněným přístupem je povinnou funkcí síťových operačních systémů.

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

CoPOSIX: systémové rozhraní nezávislé na platformě pro počítačové prostředí POSIX (Portable Operating System Interface for Computer Environments) je standard IEEE (Institute of Electrical and Electronics Engineers), který popisuje systémová rozhraní pro otevřené operační systémy, včetně prostředí, utilit a sad nástrojů. Kromě toho POSIX standardizoval bezpečnostní úlohy, úlohy v reálném čase, administrativní procesy, síťové funkce a zpracování transakcí. Standard je založen na systémech UNIX, ale lze jej implementovat i do jiných operačních systémů. POSIX vznikl jako pokus po celém světě známá organizace IEEE podporuje přenositelnost aplikací v prostředích UNIX vývojem abstraktního standardu nezávislého na platformě. Například známý OS QNX v reálném čase odpovídá specifikacím této normy.

Tento standard podrobně popisuje virtuální systém VMS (Virtual Memory System), multitasking MPE (Multi-Process Executing) a Convergent Technology ... (CTOS). POSIX je tedy vlastně sada standardů nazývaných POSIX.I –POSIX.12. Je také třeba poznamenat, že POSIX.1 předpokládá C jako hlavní jazyk.

Jazyk popisu funkcí systému API.

Programy napsané v souladu s těmito standardy tedy poběží identicky na všech systémech kompatibilních s POSIX. V některých případech má však standard pouze poradní charakter. Některé standardy jsou popsány velmi přísně, zatímco druhá část pouze povrchně odhaluje základní požadavky.

Implementace POSIX API do operačního systému jsou různé. Pokud drtivá většina systémů UNIX zpočátku vyhovuje specifikacím IEEE Standard 1003.1-1990, pak WinAPI není kompatibilní s POSIX. Pro podporu tohoto standardu v operačním systému MS Windows NT byl však zaveden speciální modul podpory API POSIX, který funguje na úrovni oprávnění uživatelských procesů.

Tento modul zajišťuje převod a přenos hovorů z uživatelského programu do systémového jádra a zpět, přičemž pracuje s jádrem prostřednictvím rozhraní Win API. Jiné aplikace vytvořené pomocí WinAPI mohou předávat informace aplikacím POSIX prostřednictvím standardních mechanismů I / O proudu (stdin, stdout).

Žádné související příspěvky ...