Predmet ispituje standard za sučelje mobilnog operacijskog sustava (POSIX), kao i tehnike i metode za programiranje aplikacija temeljenih na ovom standardu, ilustrirane brojnim primjerima. Dotaknuta su pitanja programiranja višeprocesnih sustava, interakcije aplikacija u okviru distribuiranih konfiguracija. Omogućavanje mobilnosti (prenosivost, prenosivost) softver(PO) - zadatak od iznimne važnosti i složenosti; U današnje vrijeme ta okolnost teško zahtijeva opsežno opravdanje. Jedan od općeprihvaćenih načina povećanja mobilnosti softvera je standardizacija aplikacijskog okruženja: predviđena softverska sučelja, uslužni programi itd. Na razini usluga sustava takvo okruženje opisano je standardom POSIX (Portable Operating System Interface); naziv je predložio poznati stručnjak, osnivač Zaklade za slobodni softver Richard Stallman.

Tečaj ispituje njegovu najmoderniju verziju u izdanju 2003., koja se može nazvati "trostrukim standardom", naime: standard IEEE Std 1003.1, tehnički standard Open Group i, što je za nas najvažnije, međunarodni ISO / IEC 9945 Ovaj tečaj govori o razumijevanju tehnika i metoda korištenja standardiziranih pomoćnih programa i funkcija. Cilj nije bio prepričati standard, ističući sve suptilnosti implementacije OS -a, sve moguće kodove pogrešaka itd. Po našem mišljenju, glavna stvar je osjetiti duh standarda, naučiti koristiti mogućnosti koje su mu svojstvene na mobilni način. Pretpostavljajući da čitatelj tečno govori C, nismo uzeli u obzir niti njegovu sintaksu niti funkcije knjižnice udžbenika. Što se tiče standardnog naredbenog jezika i njegovog tumača, ova je tema detaljno opisana, iako mnogi programeri praktičari radije koriste druge tumače. Značajno mjesto - i po obujmu i po ulozi - imaju primjeri programa. Mnoge odredbe standarda (koje se odnose, recimo, na rješavanje situacija pogrešaka) navedene su ne u glavnom tekstu, već u odgovarajućim primjerima. Potonji su, kad god je to moguće, sastavljeni i izvedeni na nekoliko hardverskih i softverskih platformi, na jednoj stupanj ili neki drugi koji tvrdi da je usklađen sa standardom POSIX. Međutim, propusti su svakako mogući. Bit ćemo zahvalni na svim komentarima i prijedlozima koji se odnose na tečaj u cjelini i na pojedinačne primjere programa.

Povijest stvaranja i trenutačni status standarda POSIX.

Osiguravanje mobilnosti (prenosivosti, prenosivosti) softvera (SW) zadatak je od iznimne važnosti i složenosti; u naše vrijeme ova okolnost teško treba opsežno opravdanje. Jedan od općeprihvaćenih načina povećanja prijenosnosti softvera je standardizacija aplikacijskog okruženja: dani API -i, uslužni programi itd. Na razini usluga sustava takvo okruženje opisano je standardom POSIX (Portable Operating System Interface); naziv je predložio poznati stručnjak, osnivač Zaklade za slobodni softver, Richard Stallman.

Naslovnica.
Izlaz.
Predavanje 1. Osnovni pojmovi i ideje standarda POSIX.
Predavanje 2. Jezik ljuske.
Predavanje 3. Pomoćni programi i funkcije koji služe konceptu "korisnika".
Predavanje 4. Organizacija datotečnog sustava.
Predavanje 5. Ulaz / izlaz datoteke.
Predavanje 6. Alati za obradu strukturiranih podataka.
Predavanje 7. Procesi.
Predavanje 8. Sredstva međuprocesne komunikacije.
Predavanje 9. Zajedničko terminalno sučelje.
Predavanje 10. Ispitivanje karakteristika domaćina i njihova uporaba u aplikacijama.
Predavanje 11. Mrežni sadržaji.
Predavanje 12. Vrijeme i rad s njim.
Predavanje 13. Jezično i kulturno okruženje.
Predavanje 14. Zaključak.
Bibliografija.

Besplatno preuzimanje e-knjiga u prikladnom formatu gledajte i čitajte:
Preuzmite knjigu Programiranje u standardu POSIX, 1. dio, Galatenko V.A., 2016. - fileskachat.com, brzo i besplatno preuzimanje.

POSIX i RV OS: pokušaj sistematizacije

Sergej Zolotarev, Nikolaj Gorbunov

Svrha ovog članka je pokušaj unijeti određenu jasnoću u povijest razvoja standarda POSIX u odnosu na operativne sustave u stvarnom vremenu (RT OS).

Kao uvod: zašto je potrebna standardizacija softverskog sučelja?

Jedna od najvažnijih značajki POSIX standarda je ta što definira "standardizirano programsko sučelje" kojega se programeri složenih softverskih i hardverskih sustava moraju pridržavati. Tvorci ovih sustava prisiljeni su suočiti se sa zahtjevima poput kratkog vremena za nastup na tržištu (zbog žestoke konkurencije), minimiziranja troškova i ubrzanja povrata ulaganja. Istodobno, lavovski dio troškova zbog usporavanja razvojnog procesa posljedica je činjenice da programeri moraju „izumiti kotač“, uvijek iznova implementirajući funkcionalnost koja je već dugo dostupna. No to se moglo izbjeći:

• ponovna upotreba koda iz prošlih i paralelnih projekata;
• prijenos koda iz drugih operativnih sustava;
• privlačenje programera iz drugih projekata (uključujući one koji koriste druge operativne sustave).

Sve je to moguće zahvaljujući upotrebi OS -a sa standardiziranim API -jem. Štoviše, ako je u prvom slučaju za organizaciju dovoljno imati određeni interni standard (što je osobito tipično za vlasničke operacijske sustave), onda druga dva slučaja samo zahtijevaju prisutnost općeprihvaćenih standarda - na primjer, POSIX.

Tako, koristeći OS kompatibilan s POSIX-om kao platformu za svoje projekte, programer dobiva priliku prenijeti gotov kod na razinu izvornog koda kako iz svojih prošlih ili paralelnih projekata, tako i iz projekata trećih strana. Time se ne samo značajno skraćuje vrijeme razvoja softvera, već se i poboljšava njegova kvaliteta, budući da testirani kod uvijek sadrži manje pogrešaka.

Tko je tko u razvoju POSIX -a

I nećemo krenuti od samog standarda POSIX, već od uređivanja uloge organizacija uključenih u rad na njemu.

Prvi sudionik je IEEE(Institut inženjera elektrotehnike i elektronike, Institut inženjera elektrotehnike i elektronike), javno neprofitno udruženje profesionalaca. IEEE datira iz 1884. (formalno - od 1963.), ujedinjuje 380.000 pojedinačnih članova iz 150 zemalja, objavljuje treći dio tehničke literature vezane za uporabu računala, upravljanje, električnu i informacijsku tehnologiju, kao i više od 100 časopisa. popularan među profesionalcima; osim toga, udruga održava preko 300 velikih konferencija godišnje. IEEE je sudjelovao u razvoju više od 900 postojećih standarda (www.ieee.ru/ieee.htm). Danas se ovaj institut bavi pripremom, koordinacijom, odobravanjem, objavljivanjem standarda, ali zbog svog formalnog statusa nema ovlaštenja usvajati takve dokumente kao međunarodne ili nacionalne standarde. Stoga se pojam "standard" u razumijevanju IEEE -a radije treba shvatiti kao "specifikacija", što je dosljednije statusu dokumenata koje prihvaća udruga. U skladu s IEEE -om, sudjeluje u programima brojnih međunarodnih i regionalnih organizacija - IEC, ISO, ITU (Međunarodna telekomunikacijska unija), ETSI (Europski institut za telekomunikacijske standarde), CENELEC (Europski odbor za elektrotehničku standardizaciju) i u nacionalnim programe, na primjer, u programu takve organizacije kao što je ANSI.

IEEE uključuje PASC (Portable Application Standards Committee), odbor za pridruživanje koji razvija obitelj standarda POSIX (www.pasc.org/). PASC je prije bio poznat kao Tehnički odbor operativnih sustava.

Drugi sudionik u radu - ANSI(American National Standards Institute, American National Standards Institute) - privatna neprofitna organizacija koja u Sjedinjenim Državama upravlja i koordinira djelatnostima standardizacije. Zapošljava samo 75 ljudi, ali ANSI ima preko 1.000 članova, tvrtki, organizacija, vladinih agencija i institucija (www.ansi.org). ANSI predstavlja Sjedinjene Države u dva glavna međunarodna tijela za norme, ISO i IEC.

Treći sudionik - ISO(Međunarodna organizacija za standardizaciju). Nastao je 1946. odlukom Odbora za koordinaciju standarda i Opće skupštine UN -a, a službeno je započeo s radom 23. veljače 1947. (www.iso.org). ISO je mreža nacionalnih instituta za standarde iz 146 zemalja (jedna država - jedna članica ISO -a) sa središnjim tajništvom u Ženevi (Švicarska). ISO standardi razvijaju se u tehničkim odborima, čiji je prvi izlaz Nacrt međunarodnog standarda (DIS), koji nakon nekoliko odobrenja postaje Završni nacrt međunarodnog standarda (FDIS). Nakon toga, pitanje odobrenja ovog dokumenta stavlja se na glasovanje; ako uspije, postaje međunarodni standard.

I konačno - IEC(Međunarodna elektrotehnička komisija, Međunarodna elektrotehnička komisija - IEC), osnovana 1906., IEC priprema i objavljuje međunarodne standarde za sve električne, elektroničke i srodne tehnologije (www.iec.ch/). Od 1. studenog 2004. nacionalni odbori 64 zemlje bili su aktivni članovi ovog povjerenstva. IEC također objavljuje preporuke koje su objavljene na engleskom i francuskom jeziku i imaju status međunarodnih standarda. Na temelju njih razvijaju se regionalni i nacionalni standardi. Tehnički odbori (TC) odgovorni su za pripremu standarda u različitim područjima aktivnosti IEC -a, u kojima sudjeluju nacionalni odbori zainteresirani za aktivnosti određenog TC -a.

IEC je ključna organizacija u pripremi međunarodnih standarda informacijske tehnologije. U tom području postoji zajednički tehnički odbor za informacijsku tehnologiju - JTC 1, formiran 1987. godine u skladu s sporazumom između IEC -a i ISO -a. JTC1 ima 17 pododbora koji nadgledaju sve, od softvera do programskih jezika, računalne grafike i uređivanja slika, međusobnog povezivanja opreme i sigurnosne prakse.

Priprema novih IEC standarda uključuje nekoliko faza (preliminarna, faza prijedloga, pripremna faza, faza tehničkog odbora, faza zahtjeva, faza odobrenja, faza objavljivanja). Ako namjerava dokument IEC -a postati samo tehnička specifikacija, a ne međunarodni standard, revidirana verzija dokumenta šalje se sjedištu na objavljivanje. Završni nacrt međunarodnog standarda (FDIS) trajat će četiri mjeseca da se dovrši. Ako ga odobre svi članovi tehničkog odbora, šalje se u središnji ured za objavljivanje bez faze odobrenja FDIS -a. Nakon toga FDIS odlazi u nacionalne odbore koji ga moraju odobriti u roku od dva mjeseca. FDIS se smatra odobrenim ako je za njega glasovalo više od dvije trećine nacionalnih odbora, a broj negativnih glasova ne prelazi 25%. Ako dokument nije odobren, šalje se na reviziju tehničkim odborima i pododborima. Standard se mora objaviti najkasnije dva mjeseca nakon odobrenja FDIS -a.

Nekoliko drugih organizacija uključeno je u razvoj i usvajanje POSIX standarda.

Otvorena grupa Međunarodna je organizacija za standardizaciju softvera koja ujedinjuje gotovo 200 proizvođača i korisničkih zajednica koje rade na području informacijske tehnologije (www.opengroup.org/). Otvorena grupa nastala je 1995. spajanjem dva prethodnika: X / Open i Open Software Foundation (OSF). Otvorena grupa specijalizirana je za razvoj metodologija certificiranja softvera i testiranje usklađenosti. Otvorena skupina osobito pruža certifikate za područja kao što su COE platforma, CORBA, LDAP, Linux Standard Base, Okvir za interoperabilnost škola (SIF), S / MIME pristupnik, Jedinstvena UNIX specifikacija, Specifikacije bežičnog aplikacijskog protokola (WAP) i na kraju POSIX obitelj standarda (www.opengroup.org/certification/).

Grupa za reviziju zajedničkih standarda Austina (CSRG)- zajedničko tehničko radna skupina osnovana 2002. godine od strane ISO -a, IEC -a i Otvorene grupe za stvaranje i održavanje najnovije verzije standard 1003.1, koji će biti formiran na temelju ISO / IEC 9945-1-1996, ISO / IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 i Jedinstvene UNIX specifikacije (www.opengroup.org / press/ 14nov02.htm).

Nacionalni institut za standarde i tehnologiju (NIST)- savezna agencija u sastavu Tehnološke uprave Ministarstva trgovine (www.nist.gov/public_a Affairs/general2.htm), osnovana u Sjedinjenim Državama 1901. Misija NIST -a je razvoj i promicanje standarda i tehnologija za poboljšanje kvalitete proizvoda. NIST uključuje Laboratorij za informacijsku tehnologiju (ITL), čiji je jedan od rezultata Federalni standardi obrade informacija (FIPS, www.opengroup.org/testing/fips/general_info.html). NIST / ITL je ponudio početni skup testova za POSIX certifikaciju prema FIPS PUB 151-1 1990. godine.

Što je POSIX?

Formalno termin POSIX predložio Richard Stallman kao skraćenicu za P ortable O. perating S ystem sučelje za un IX(prijenosno sučelje operacijskog sustava za Unix). POSIX je osmišljen za operacijske sustave slične UNIX-u (njihove najstarije verzije datiraju iz ranih 1970-ih) s ciljem pružanja prijenosnosti izvora aplikacijama.

Početni opis sučelja objavljen je 1986., tada se zvao IEEE-IX (IEEE-ina verzija UNIX-a). Međutim, naziv se brzo promijenio, postajući POSIX, a već u sljedećoj publikaciji (davne 1986.) ovaj novi neko se vrijeme koristila verzija POSIX kao referenca (ili sinonim) na grupu povezanih dokumenata IEEE 1003.1-1988 i dijelove ISO / IEC 9945, te kao potpuni i odobreni međunarodni standard ISO / IEC 9945.1: 1990 POSIX usvojena je 1990. POSIX specifikacije definiraju standardni mehanizam za interakciju između aplikacijskog programa i OS -a i trenutno uključuju više od 30 standarda pod pokroviteljstvom IEEE, ISO, IEC i ANSI.

Kroz svoju povijest, POSIX je prešao dug put, pri čemu su se imenovanje specifikacija, njihov specifični sadržaj, postupci i logistika njihove provjere mijenjali mnogo puta. Od tada je u raznim međunarodnim organizacijama izdano nekoliko izdanja standarda POSIX.

Povijest razvoja standarda POSIX

Prva verzija specifikacije IEEE Std 1003.1 objavljena je 1988. Kasnije su brojna izdanja IEEE Std 1003.1 prihvaćena kao međunarodni standardi.

Faze razvoja POSIX -a:

1990 godina

Izdanje, objavljeno 1988., revidirano je i postalo je temelj za daljnje izmjene i dopune. Odobren je kao međunarodni standard ISO / IEC 9945-1: 1990.

1993. godine

Objavljeno je izdanje 1003.1b-1993.

1996. godine

Izmjene su napravljene u IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 i 1003.1i-1995, ali većina dokumenta ostaje nepromijenjena. 1996. revizija IEEE Std 1003.1 također je odobrena kao međunarodni standard ISO / IEC 9945-1: 1996.

1998 godina

Pojavio se prvi standard za "real time" - IEEE Std 1003.13-1998. To je proširenje standarda POSIX za ugrađene aplikacije u stvarnom vremenu.

1999 godine

Odlučeno je napraviti prve značajne promjene u glavnom tekstu standarda u posljednjih 10 godina, uključujući spajanje sa standardom 1003.2 (Shell i komunalije), budući da su do tada bili zasebni standardi. PASC je odlučio dovršiti izmjene osnovnog teksta nakon što je završio rad na IEEE standardima 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q i 1003.2b.

2004. r.

Najnovija revizija Standarda 1003.1 objavljena je 30. travnja i objavljena pod pokroviteljstvom Grupe za reviziju zajedničkih standarda Austina. Izmijenjen je i dopunjen za izdanje standarda iz 2001. Formalno, izdanje za 2004. poznato je kao IEEE Std 1003.1, izdanje za 2004., Tehničke standardne baze otvorene grupe, izdanje 6 i uključuje IEEE Std 1003.1-2001, IEEE Std 1003.1-2001 / Cor 1-2002 i IEEE Std 1003.1-2001 / Cor 2-2004.

Najvažniji POSIX standardi za RV OS

Za operacijske sustave u stvarnom vremenu najvažnije je sedam specifikacija standarda (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), ali samo su tri dobile široku podršku u komercijalnim operativnim sustavima:

• 1003.1a (definicija OS -a) definira glavna OS sučelja, kontrolu poslova, signale, funkcije datotečnog sustava i rad s uređajima, korisničke skupine, cjevovode, FIFO međuspremnike;
• 1003.1b (proširenja u stvarnom vremenu) opisuje proširenja u stvarnom vremenu kao što su signali u stvarnom vremenu, prioritetno raspoređivanje, mjerači vremena, sinkroni i asinkroni I / O, semafori, zajednička memorija, poruke. U početku (prije 1993.) ovaj se standard nazivao POSIX.4.
• 1003.1c (niti) definira funkcije podrške niti - kontrola niti, atributi niti, mutex -ovi, otpremanje. Izvorno označeno kao POSIX.4a.

Osim ovih standarda, za RT OS važni su i sljedeći standardi koji su implementirani u sklopu rada na projektu Std 1003.1-2001:

• IEEE 1003.1d-1999. Dodatna proširenja u stvarnom vremenu. Izvorno označeno kao POSIX.4b;
• IEEE 1003.1j-2000. Poboljšana (napredna) proširenja u stvarnom vremenu;
• IEEE 1003.1q-2000. Praćenje.

Postupak certificiranja

Da bi bio usklađen s POSIX -om, operacijski sustav mora biti certificiran u skladu s odgovarajućim paketom testova. Od uvođenja POSIX -a, testni paket doživio je formalne i de facto promjene.

1991. NIST je razvio program testiranja POSIX-a prema FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). Ova se opcija ispitivanja temeljila na IEEE 1003.3 "Standard za metode ispitivanja za mjerenje sukladnosti s POSIX -om" Nacrt 10., 3. svibnja 1989. Godine 1993. NIST je dovršio POSIX Program testiranja za FIPS 151-1 i započeo program za FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 prilagodio je "Informacijsku tehnologiju - sučelje prijenosnog operacijskog sustava (POSIX) - 1. dio: Sučelje programskog aplikacijskog programa (API)", što je standard ISO / IEC 9945-1: 1990. Ispitni paketi za FIPS 151-2 temeljili su se na IEEE 2003.1-1992 "Standard za metode ispitivanja za mjerenje sukladnosti s POSIX-om".

NIST razlikuje dvije certifikacijske metodologije: samopotvrđivanje i certificiranje od strane IEEE -ov akreditiranih ispitnih laboratorija (Akreditirani POSIX ispitni laboratoriji - APTL). U prvom slučaju, tvrtka sama provodi testiranje, ali prema planu koji je odobrio NIST. U drugom slučaju, testiranje provodi neovisni laboratorij koristeći automatizirane testne pakete. Ukupno su dva APTL laboratorija akreditirana: Mindcraft (www.mindcraft.com) i Perennial (www.peren.com).

Godine 1997. NIST / ITL je najavio svoju namjeru da okonča certifikaciju FIPS 151-2 krajem ove godine (službeno 31. prosinca 1997.), dok je Otvorena skupina najavila da će to preuzeti od 1. listopada iste godine. godine certifikacijska usluga u skladu s FIPS 151-2, na temelju programa NIST / ITL. Iste funkcije preuzela je IEEE Standards Association (IEEE-SA) od 1. siječnja 1998., a također na temelju FIPS 151-2.

Godine 2003. IEEE-SA i Open Group najavili su novi zajednički program certificiranja za najnovije verzije POSIX-a, počevši od IEEE 1003.1 ™ 2001. Otvorena grupa sada ima nekoliko programskih paketa koji pokrivaju IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 , IEEE Std 1003.1-2003 i IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Proizvod se smatra POSIX certificiranim ako je prošao potpuni certifikacijski postupak, prema rezultatima ispitivanja ispunjava sve zahtjeve i upisan je u službeni registar certificiranih proizvoda.

Testni paketi uključuju:

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm)-skup testova sukladnosti za sučelja sustava IEEE Std 1003.1-1990;
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - skup testova sukladnosti za IEEE Std 1003.13-1998 Profil PSE54 (višenamjensko u stvarnom vremenu);
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm)-skup testova sukladnosti za sučelja sustava IEEE Std 1003.1-2003 (samo obavezni dijelovi);
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) je skup testova sukladnosti za IEEE Std 1003.1-2003 (ljuska i pomoćni programi-samo obavezni dijelovi).

Osim toga, Otvorena grupa razvila je mjerila za POSIX standarde u stvarnom vremenu i ugrađeni profil standarda POSIX. POSIX Realtime Test Suite (www.opengroup.org/testing/testsuites/realtime.html) uključuje sljedeće testove:

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Proširenje u stvarnom vremenu i IEEE POSIX 1003.1,2003 izdanje;
• IEEE Std POSIX 1003.1c-1995 Threads (pthreads) proširenje i IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1d-1999 Dodatno proširenje u stvarnom vremenu i IEEE POSIX 1003.1,2003 izdanje;
• IEEE POSIX 1003.1j-2000 Napredno proširenje u stvarnom vremenu i IEEE POSIX 1003.1,2003 izdanje;
• IEEE POSIX 1003.1q-2000 Trace i IEEE POSIX 1003.1,2003 Edition i IEEE POSIX 1003.1,2003 Edition;

Paket za testiranje profila ugrađenih POSIX standarda (www.opengroup.org/testing/testsuites/embedded.html) uključuje sljedeće testove:

• IEEE POSIX 1003.1-1990 (5310 testova);
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Proširenje u stvarnom vremenu (1430 testova);
• IEEE Std POSIX 1003.1c-1995 Niti (pthreads) proširenje (1232 testova);
• IEEE POSIX 1003.13-1998 Profil 52.

Malo o zabuni u terminologiji

U odnosu na skupinu standarda POSIX, engleski jezik često koristi ne jedan, već čak tri izraza. Nažalost, slična su značenja i često se prevode na isti način, što unosi određenu zabunu. Ti su uvjeti sljedeći:

• kompatibilnost (doslovno "kompatibilnost");
• usklađenost (doslovno - "usklađenost");
• sukladnost (doslovno - "dosljednost").

Prvi pojam primijenjen na POSIX nije formalno definiran. Drugo znači da organizacija - proizvođač softverskog proizvoda neovisno izjavljuje da je ovaj proizvod (u cijelosti ili djelomično) usklađen s navedenim NIST -PCTS standardima. Treći pojam to implicira softver položili uspostavljeni sustav ispitivanja bilo uz pomoć akreditiranog laboratorija ili u okviru Otvorene grupe i za to postoje dokumentarni dokazi (tzv. Izjava o sukladnosti). Dalje u tekstu članka svugdje će se citirati izvornici izraza kako bi se uklonile nejasnoće.

Certificirani OS RV

Ako se pridržavate strogih pravila koja zahtijevaju da se podaci o certificiranom RT OS -u objave u službenom registru, a testiranje provodi na razini usklađenosti, tada postoje samo dva certificirana RT OS -a (podaci su navedeni kronološkim redoslijedom):

LynxOS v.3(proizvod Lynx Real-Time Systems, koji se sada naziva LynuxWorks, Inc., www.lynuxworks.com) osmišljen je za razvoj softvera za ugrađene sustave koji rade u teškom stvarnom vremenu, proizvođača OEM-a i telekomunikacijske opreme, posebno proizvođača ugrađenih sustava za vojne svrhe ... Razvoj se može izvesti i na samom ciljnom sustavu (sa vlastitim hostom) i na instrumentalnom računalu (host), gotov softver je dizajniran za rad na ciljnom sustavu (cilj). LynxOS v.3 certificirana je POSIX sukladnost na Intel i PowerPC platformama. Informacije o tome mogu se pronaći na web stranici IEEE -a na http://standards.ieee.org/regauth/posix/posix2.html. LynxOS je POSIX 1003.1-1996 certificiran od strane Mindcrafta, IEEE POSIX akreditiranog POSIX laboratorija za ispitivanje u NIST FIPS 151-2 ispitnom paketu za usklađenost. Broj certifikacijskog dokumenta: Referentna datoteka: IP-2LYX002, Referentna datoteka: IP-2LYX001.

INTEGRITET v.5(proizvod Green Hills Software, www.ghs.com) certificiran je u skladu s POSIX 1003.1-2003, Sustavna sučelja za PowerPC arhitekturu u srpnju 2004. (http://get.posixcertified.ieee.org/select_product. tpl). VSX-PCTS 2003 testni paket.

POSIX i operacijski sustav QNX

QNX v.4.20 (razvijen od strane QNX Software Systems, www.qnx.com) je usklađenost s POSIX 1003.1-1988 potvrđena za Intel platformu od strane DataFocus Incorporated. Testiranje je provedeno 13. rujna 1993. i izdano 1. studenog 1993. NIST PCTS 151-1 Test Suite, verzija 1.1.

QNX Neutrino (verzija 6.3) usklađen je sa sljedećim standardima obitelji 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.1g).

QNX Software Systems, tvorac QNX Neutrina, također planira usklađenost QNX Neutrina s nekim od ovih standarda; radovi su planirani za 2005. (www.qnx.com/news/pr_959_1.html).

Književnost

1. Priručnik za rad udruženja IEEE Standards Association. IEEE, listopad 2004.
2. Kevin M. Obeland. POSIX u programiranju ugrađenih sustava u stvarnom vremenu, 2001.
3. IEEE / ANSI standard 1003.1: Informacijska tehnologija - (POSIX) - 1. dio: Sustavna primjena: programsko sučelje (API).
4. Gallmeister, B. O. Programiranje za stvarni svijet, POSIX.4 Sebastopol, Kalifornija: O'Reilly & Associates, 1995.
5. Nacionalni institut za standarde i tehnologiju, PCTS: 151-2, POSIX Test Suite.
6. POSIX: Certificiran od IEEE -a i The Open Group. Ovjerena politika. Otvorena grupa, 21. listopada 2003., revizija 1.1.

Aleksej Fedorčuk
2005 godine

Jedna od karakterističnih značajki logičke strukture datotečnog sustava operacijskih sustava obitelji POSIX je njihova hijerarhijska ili stablasta organizacija (iako, kao što sam rekao, stablo izgleda pomalo čudno). Odnosno, kao u DOS -u ili Windowsima bilo koje vrste, ne postoje oznake (na primjer, abecedne ili bilo koje druge) za pojedinačne medije i njihove particije: svi su oni uključeni u jednu strukturu kao poddirektoriji glavnog direktorija. zove korijen. Postupak povezivanja datotečni sustavi na neovisnim fizičkim medijima (i njihovim particijama) do korijena stabla datoteke naziva se montiranje, a poddirektoriji koje sadrže nazivaju se točke montiranja.

Povijesno gledano, Unix je razvio specifičnu strukturu direktorija koja je općenito vrlo slična u cijeloj obitelji, ali se malo razlikuje u detaljima. Konkretno, hijerarhija datoteka na BSD sustavima gotovo je identična, ali se razlikuje od one na Linuxu. I u potonjem se nalaze značajne razlike između različitih distribucija. Sve do činjenice da je struktura hijerarhije datoteka jedna od značajki specifičnih za distribuciju.

Takvo stanje otežava pisanje aplikacija na više platformi. Stoga postoji i aktivno se razvija projekt za standardizaciju hijerarhije datoteka - FHS (Filesystem Hierarchy Standard).

FHS je izvorno imao za cilj pojednostaviti strukturu direktorija brojnih distribucija Linuxa. Kasnije je prilagođen drugima Sustavi nalik Unixu(uključujući klan BSD -a). A sada postoje aktivni (ali ne baš uspješni) napori da se to učini standardom za POSIX sustave, ne samo po imenu, već i zapravo.

Standard FHS počiva na dva temeljna načela - jasnom razdvajanju u hijerarhiji datoteka imenika koji su dijeljeni i ne dijeljeni, s jedne strane, i nepromjenjivi i promjenjivi, s druge strane.

Kontrast između dijeljenih i ne-dijeljenih direktorija posljedica je svojstvene mrežne prirode Unixa. Odnosno, podaci koji se odnose na lokalni stroj (na primjer, konfiguracijske datoteke za njegove uređaje) trebali bi se nalaziti u direktorijima odvojenim od onih čiji je sadržaj dostupan na drugim strojevima na mreži, lokalnim ili globalnim (primjer koji nije samo korisnik podatke, ali i programe) ...

Suštinu suprotnosti između nepromjenjivih i promjenjivih direktorija lako je objasniti primjerom. Dakle, isti programi općeg korisnika po svojoj bi prirodi trebali biti nepromjenjivi (ili bolje rečeno, dostupni za izmjene samo administratoru sustava, ali ne i samom korisniku koji ih koristi u svom radu). Istodobno, ti programi tijekom svog rada ne generiraju samo podatkovne datoteke, recimo, tekstove ili slike (njihova je varijabilna priroda jasna bez komentara), već sve vrste servisnih informacija, poput datoteka dnevnika, privremenih datoteka i slično) . Koje treba grupirati u direktorije odvojene od stvarnih izvršnih programskih datoteka, knjižnica, konfiguracijskih datoteka itd. Potrebnih za njihovo pokretanje.

Unatoč tome, unatoč aktivnoj promociji u mnogim distribucijama Linuxa među najčešćim, FHS nije stekao status pravog standarda. Postoji dosta Linux distribucija koje ne koriste neke njegove odredbe. I samo je djelomično u korelaciji s tradicionalnom hijerarhijom datoteka BSD sustava.

A razlog je u tome što FHS zanemaruje još jedno protivljenje, koje je vrlo važno za korisnika: suprotstavljanje dijelova datotečnog sustava koji se lako mogu oporaviti i onih njegovih komponenti koje je teško oporaviti ili ih uopće nije moguće oporaviti.

Prvi se, začudo, može pripisati samom osnovnom sustavu: uostalom, ponovna instalacija s distribucijskog medija, u slučaju smrtonosnog rušenja, nije tako teška. Dijelovi datotečnog sustava koje je teško oporaviti očito uključuju korisničke podatke: čak i ako se redovito izrađuju sigurnosne kopije (a koliko je korisnika toliko opreznih?), Njihovo postavljanje iz arhiva oduzet će puno vremena (i gotovo neizbježno podrazumijevati neke gubici).

Osim toga, u BSD sustavima i izvornim Linux distribucijama, sve što se odnosi na upravljanje paketima klasificirao bih kao teško oporavljive direktorije-stablo portova FreeBSD ili pkgsrc u NetBSD-u (i sustave koji su ga posudili), njihove kolege u distribucijama Linuxa, stvarni izvori prenesenih programa, kao i izvorni kod sustava. Jer, čak i ako se sve to nalazi u distribucijskom kompletu, te komponente datotečnog sustava, u pravilu, korisnici ažuriraju sinkronizacijom s poslužiteljima projekta putem Mreže (inače je njihova upotreba besmislena). Njihov će gubitak značiti i privremene (osobito s modemskom vezom) i financijske (rijetki su ljudi sretni vlasnici besplatnog pristupa internetu) gubitke.

Strogo poštivanje koncepta odvajanja dijeljenih i nepodijeljenih, nepromjenjivih i nepromjenjivih, oporavljivih i nepovratnih imenika jedan od drugog omogućuje, unutar jedne hijerarhije datoteka slične stablu, fizičko odvajanje njegovih pojedinačnih grana-to jest u obliku nezavisnih datotečnih sustava smještenih na izoliranim uređajima (diskovi, odjeljci diskova, kriške, particije itd.). Za to postoji mnogo razloga - i povećanje performansi, i povećanje pouzdanosti, i jednostavno iz praktičnih razloga - ali nećemo sada o njima. Jer u ovaj trenutak važno nam je da se ove grane stabla datoteka moraju uključiti u zajednički datotečni sustav.

Tipičan skup imenika sustava POSIX

Zapravo, za funkcioniranje je apsolutno potrebno imati samo jedan datotečni sustav - onaj koji je montiran u korijenski direktorij stabla datoteka (svojevrsni analog svjetskog stabla Yggdrassil). Korijenski direktorij i njegove neophodne grane moraju činiti jedan datotečni sustav koji se nalazi na jednom mediju - disku, particiji diska, softverskom ili hardverskom RAID nizu ili logičkom volumenu u razumijevanju LVM -a. I trebao bi sadržavati sve komponente potrebne za pokretanje sustava i, idealno, ništa više.

Sastavom korijenskog direktorija možete pogledati naredbom

$ ls -1 /

koji će na bilo kojem POSIX sustavu pokazati neki minimalni džentlmenski skup imenika:

Bin / boot / etc / root / sbin /

U njima se prikupljaju sve datoteke bez kojih sustav ne može postojati. Ostali direktoriji su otprilike ovakvi:

Početna / mnt / opt / tmp / usr / var /

Oni a) nisu potrebni (barem u teoriji - praktički je teško bez njih), b) nije svaki od njih prisutan u svim sustavima i distribucijama, i c) svaki od njih može biti (a često jest - ako sve radite prema svom umu) točka montiranja vlastite grane stabla datoteka.

Osim toga, u većini slučajeva u korijenu datotečnog sustava OS-ova kompatibilnih s POSIX-om postoje još dva poddirektorija:

Dev / proc /

To su obično točke montiranja virtualnih datotečnih sustava - uređaja i procesa (iako, ako se datotečni sustav uređaja ne koristi, direktorij / dev mora biti komponenta korijenskog datotečnog sustava. Konačno, na Linux sustavima, kao u pravilu, korijen stabla datoteka je i / lib direktorij za glavne sistemske knjižnice, a s udevom je neizbježni direktorij / sys također gdje je montiran virtualni datotečni sustav sysfs.

Root datotečni sustav

Korijenski datotečni sustav nije dijeljiv (to jest, ne namjerava ga dijeliti različiti strojevi na mreži) i nepromjenljiv (to jest, samo administrator sustava može u njega unijeti izmjene, ali ne i korisnički programi i, štoviše, ne korisnici). Štoviše, krajnje se ne preporučuje stvaranje unutar njega poddirektorija iznad onih predviđenih standardom (i gore navedenim).

Ispunjavanje korijenskog datotečnog sustava odabrano je tako da se stroj može pokrenuti i zadržati minimalnu funkcionalnost čak i tijekom hitnog pokretanja (ili u načinu rada za jednog korisnika), kada svi drugi sustavi datoteka nisu montirani (i, prema tome, njegove grane, kao što su / usr ili / var možda nisu dostupni.

U skladu s tim, početak stroja omogućuju datoteke direktorija / boot i / itd. Prva sadrži jezgru sustava - izvršnu datoteku "posebne namjene" - i sve što je potrebno za učitavanje - na Linuxu, na primjer, mapu sustava (/etc/System.map), i na FreeBSD - učitavu jezgru moduli. Međutim, ponekad se jezgra nalazi izravno u korijenu datotečnog sustava, a tada direktorij / boot može biti potpuno odsutan, a direktorij / modules može biti rezerviran za module jezgre.

Direktorij / etc služi za konfiguracijske datoteke na razini cijelog sustava koje određuju uvjete za njegovo učitavanje. Njegov sadržaj uvelike ovisi o sustavu (i u Linuxu - također o distribucijskom paketu), pa ga ovdje neću razmatrati - morat ću se vratiti na ovu temu više puta.

Minimalno potrebnu funkcionalnost osigurava sadržaj direktorija / bin i / sbin - oni sadrže izvršne datoteke najvažnijih korisničkih i sistemskih programa, upravo onih koji će vam omogućiti izvođenje kompleksa mjera popravka i spašavanja i vratiti automobil u ljudski oblik nakon kvara.

Podjela sistemskih i korisničkih programa na korijenske podimenike prilično je proizvoljna. Nijedna od ovih naredbi nije namijenjena rješavanju problema korisnika. Samo što direktorij / bin sadrži administracijske naredbe kojima redoviti korisnik povremeno pristupa (ili im može pristupiti), a direktorij sbin namijenjen je naredbama za koje korisnik ne bi trebao znati. I koje u većini slučajeva ipak neće moći koristiti zbog nedostatka odgovarajućih ovlasti (na primjer, potrebna prava pristupa datotekama uređaja).

Za pokretanje POSIX programa (uključujući one sastavljene u / bin i sbin imenicima) u pravilu vam je potreban pristup funkcijama knjižnica na cijelom sustavu (prvenstveno glavnoj glibc knjižnici). I tako je (gotovo) neophodna komponenta korijenskog direktorija poddirektorij / lib u koji su oni sastavljeni.

Na Linuxu direktorij / lib ima drugu važnu svrhu - njegov poddirektorij ( / lib / modules) sadrži učitavajuće module jezgre (na FreeBSD -u njihovo mjesto je / boot / kernel).

U FreeBSD -u direktorij / lib se ne nalazi u korijenskom datotečnom sustavu - odgovarajuće komponente nalaze se ovdje u / usr / lib (vidi dolje). To je zato što je, povijesno gledano, FreeBSD izgradio velike sistemske programe tako da su knjižnične funkcije koje zahtijevaju ugrađene u njihove izvršne datoteke (tzv. Statičko povezivanje, o čemu će biti riječi u poglavlju 14). U FreeBSD -u programi pete grane iz direktorija / bin i / sbin dinamički su povezani, to jest, u nedostatku direktorija / usr (a u besplatnom je to gotovo uvijek zasebna grana datotečnog sustava) ne funkcioniraju. Da bi se to nadoknadilo, postoji direktorij / restore koji nadilazi standarde, sadrži iste programe, ali je statički povezan (kako naziv imenika sugerira, jedina svrha njegova sadržaja su operacije spašavanja).

Na kraju, / root. Ovo je uobičajeni kućni imenik istoimenog korisnika, odnosno administratora sustava. Budući da ne radi nikakav praktičan posao (ili barem ne bi trebao biti), njegov sadržaj su samo vlastite konfiguracijske datoteke superkorisnika (korisnička naredbena ljuska, omiljeni uređivač itd.).

Podružnica / usr

Povijesno je imenik / usr bio namijenjen korisničkim programima i podacima. Ove su funkcije sada podijeljene između / usr / local i / home (iako je potonja sada simbolična veza na / usr / home prema zadanim postavkama u FreeBSD -u). Direktorij / usr - nije promjenjiv, ali se dijeli - služi kao spremište za većinu aplikacijskih programa i sve što je s njima povezano - izvorni kod, konfiguracijske datoteke, zajedničke knjižnice, dokumentaciju i slično.

Sastav direktorija / usr značajno se razlikuje između BSD sustava i Linuxa. U prvom, on sadrži samo sastavne dijelove operacijskog sustava (ono što je u FreeBSD -u objedinjeno konceptom distribucije). Aplikacije instalirane s portova ili paketa imaju svoje mjesto u poddirektoriju / usr / local, što može predstavljati zasebnu granu stabla datoteka.

Na Linuxu direktorij / usr služi kao spremište za sve programe (i njihove komponente) uključene u distribucijski paket. Poddirektorij / usr / local obično je namijenjen programima koji se neovisno sastavljaju iz izvora.

U svakom slučaju, uobičajeni sastav direktorija / usr je sljedeći (prema izvješću naredbe ls -1):

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

Kao što je već spomenuto, / usr / local poddirektorij je zasebna grana stabla datoteka, pa će se stoga razmatrati zasebno. Svrha ostalih direktorija je sljedeća:

• / usr / bin i / usr / sbin namijenjeni su izvršnim datotekama korisničkih i sistemskih programa (ovdje je granica između njih još proizvoljnija nego u slučaju korijenskog direktorija) čija svrha nadilazi osiguravanje osnovnog funkcioniranja sustav;
• / usr / etc služi za pojedinačne konfiguracijske datoteke aplikacija;
• / usr / include sadrži takozvane datoteke zaglavlja potrebne za povezivanje izvršne datoteke s bibliotečkim komponentama;
• / usr / lib i / usr / libexec direktoriji su za dijeljene knjižnice o kojima ovise korisničke aplikacije;
• / usr / share - spremište najrazličitijih, tzv. arhitektonski neovisne komponente: ovdje možete vidjeti dokumentaciju u različitim formatima, primjere konfiguracijskih datoteka i podatke koje koriste programi za upravljanje konzolama (fontovi, rasporedi tipkovnice) i opis vremenskih zona;
• / usr / src - direktorij izvornog koda; u Linuxu se ovdje obično postavlja samo izvorni kod jezgre (jezgre) sustava, u BSD klonovima - cijeli skup izvornih kodova kompleksa, koji se u FreeBSD -u naziva Distribucije; u pravilu je nepoželjno ovdje postavljati izvore programa koji se sami sastavljaju;
• / usr / X11R6 - direktorij za komponente X prozora sustava - izvršne datoteke ( / usr / X11R6 / bin), knjižnice ( / usr / X11R6 / lib), zaglavlja ( / usr / X11R6 / include), dokumentacija ( / usr / X11R6 / čovjek); Ovdje se ne smiju stavljati datoteke X aplikacija (osim, možda, za upravitelje prozora) - njihovo mjesto je u / usr, / usr / local ili / opt, ovisno o sustavu.

Osim toga, direktorij / usr može sadržavati poddirektorije / usr / var i / usr / tmp - obično simbolične veze na odgovarajuće grane korijenskog direktorija. A na nekim distribucijama Linuxa glavna dokumentacija za cijeli sustav, stranice za korisnike (u poddirektoriju / usr / man), smještena je izravno u / usr.

Konačno, na BSD sustavima i nekim izvornim Linux distribucijama (na primjer, Gentoo), direktorij / usr sadrži poddirektorij za sustav upravljanja paketima - portove FreeBSD i OpenBSD ( / usr / portovi), njihove pandane na drugim sustavima ( / usr / portage u Gentoo -u). Iako sa stajališta poštivanja slova i duha FHS standarda (on sam ne spominje niti riječ o portovima i sličnim sustavima), logičnije mjesto za njihovo postavljanje bio bi direktorij / var (vidi dolje) - a upravo se to radi u distribucijama kao što su CRUX i Archlinux.

Podružnica / usr / lokalna

Kao što je već spomenuto, / usr / lokalna podružnica u Linuxu namijenjena je samokompiliranim programima iz izvora (nisu uključeni u ovaj distribucijski paket). A na FreeBSD -u služi kao dom za većinu korisničkih aplikacija - gotovo sve izvan Distribucija i instalirano iz paketa ili portova. Sukladno tome, struktura direktorija u cjelini slijedi strukturu grane / usr (s razumljivim iznimkama):

Kanta / etc / include / lib / man / sbin / share /

Sadržaj poddirektorija također je sličan: izvršne datoteke programa ( / usr / local / bin i / usr / local / sbin), njihove konfiguracije ( / usr / lokalni / itd.), Knjižnice s kojima su povezane i datoteke zaglavlja ( / usr / local / lib i / usr / local / include, respektivno), stranice za korisnike ( / usr / local / man) i sve vrste arhitektonski neovisnih stvari ( / usr / local / share), uključujući dokumentaciju u drugim formatima .

/ Opcija grana

Direktorij / opt pruža FHS standard, ali se zapravo ne koristi u svim distribucijama Linuxa, a u BSD sustavima potpuno je odsutan. Ipak, sve se više programa piše s očekivanjem zadane instalacije u njemu.

Povijesno gledano, / opt se u Linuxu koristio za komercijalne aplikacije i sve vrste neslobodnog softvera. Danas mu je svrha ugostiti velike samostalne softverske sustave, poput knjižnice Qt, KDE-a sa svim njegovim komponentama i aplikacijama, OpenOffice.org i slično. Struktura direktorija trebala bi biti / opt / pkg_name. Ovako to izgleda na mom sustavu (Archlinux):

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

Svaki od poddirektorija ima svoju unutarnju strukturu:

$ ls -1 / opt / * / opt / gnome: bin / lib / man / share / / opt / kde: bin / etc / include / lib / share / /opt/OpenOffice.org1.1.2: help / LICENCNA LICENCA. html program / README README.html [zaštićena e -pošta] udio / [zaštićena e -pošta] THIRDPARTYLICENSEREADME.html korisnik / / opt / qt: bin / doc / include / lib / mkspecs / izraznici / dodaci / predlošci / prijevodi /

Svrha poddirektorija unutar / opt / pkg_name lako se pogađa po analogiji s / usr i / usr / local. Na primjer, / opt / kde / bin je za izvršne datoteke KDE sustava i njegovih aplikacija, / opt / kde / etc je za njegove konfiguracijske datoteke, / opt / kde / include je za datoteke zaglavlja, / opt / kde / lib je za knjižnice i / opt / kde / share - za zajedničke datoteke, uključujući dokumentaciju. U KDE -u nema dokumentacije u man -formatu, ako postoji, tada (kao u slučaju Gnomea - nisam ga instalirao, to su ono što su Gimp i slične Gtk aplikacije povukle) možete vidjeti / opt / pkg_name / poddirektorij čovjek.

Možete vidjeti da struktura / opt direktorija odstupa od povijesno uspostavljene (i interno utemeljene POSIX tradicije kombiniranja sličnih komponenti u direktorije - izvršne datoteke, knjižnice itd.) I s velikim brojem instaliranih programa stvara određene poteškoće : morate ili preopteretiti varijablu $ PATH, koja omogućuje brzi pristup naredbama (o čemu će biti riječi u poglavlju 12), ili stvoriti poseban direktorij / opt / bin i staviti simbolične veze do izvršnih programskih binarnih datoteka. Stoga, u nekim Linux distribucije (na primjer, u CRUX -u) / opt se načelno ne koristi. Kao, doista, u svim BSD sustavima. Sasvim je moguće da je ovako bolje ...

/ Podružnica Var

Kao što naziv implicira, direktorij / var namijenjen je za pohranu promjenjivih datoteka nastalih tijekom normalnog života različitih programa - softverskih (na primjer, preglednika) predmemorije, datoteka dnevnika, ispisivanja i sustava pošte. poštanski sandučići, opisi pokrenutih procesa itd. Konkretno, u direktorij / var postavljaju se takozvani dumpi - snimke stanja RAM -a, generirane tijekom hitnog isključivanja radi identifikacije razloga za to. Posebnost svih ovih komponenti je njihova promjenjiva priroda tijekom sesije rada i činjenica da se one ipak moraju sačuvati pri ponovnom pokretanju sustava.

Unutarnja struktura / var uvelike varira od sustava do sustava, pa se neću zadržavati na detaljima njegove strukture. Primijetit ću samo da je ovaj direktorij logično mjesto za postavljanje komponenti svih vrsta sustava za upravljanje paketima nalik na portove, kao što je to, primjerice, učinjeno u distribuciji Archlinux, gdje je poddirektorij / var / abs (abs - Arhitektonski sustav za izgradnju ) rezervirano je za to.

Imenik / mnt

Direktorij / mnt dizajniran je za montiranje privremeno korištenih datotečnih sustava, koji se obično nalaze na prijenosni mediji... U uspostavljenom sustavu obično je prazan, a njegova struktura nije ni na koji način regulirana. Korisnik može slobodno stvoriti poddirektorije za određene vrste medija. Na primjer, na mom sustavu to su / mnt / cd, / mnt / dvd, / mnt / usb i / mnt / hd - za CD -ove, DVD -ove, flash pogone i prijenosne tvrde diskove.

U FreeBSD -u zadani direktoriji za postavljanje CD -a i disketa su / cdrom i / disketa izravno u korijenskom direktoriju. Što se ne slaže sasvim sa standardom, ali na svoj način logično - točke montiranja uređaja koji postoje (poput CD -a) ili donedavno postoje (disketni pogon) na bilo kojem stroju preuzimaju se u korijen.

/ Podružnica

/ Home direktorij služi za smještaj kućnih direktorija korisnika. Njegov sadržaj nije reguliran ni na koji način, ali obično izgleda kao /home/(username1,...,username#). Međutim, u velikim sustavima s velikim brojem korisnika, njihovi se kućni direktoriji mogu grupirati zajedno.

Direktorij / home može sadržavati kućne direktorije ne samo stvarnih korisnika, već i nekih virtualnih korisnika. Dakle, ako se stroj koristi kao web ili ftp poslužitelj, vidjet ćete poddirektorije kao što su / home / www ili / home / ftp.

Podružnica / tmp

Ostaje govoriti samo o direktoriju za spremanje privremenih datoteka - / tmp. Kao i / var komponente, generiraju ih različiti programi tijekom svog normalnog života. No, za razliku od / var, ne očekuje se da će / tmp komponente biti spremljene izvan trenutne sesije. Štoviše, svi vodiči za administraciju sustava preporučuju redovito (na primjer, pri ponovnom pokretanju stroja) ili povremeno brisanje ovog imenika. Stoga je, kao / tmp, poželjno montirati datotečne sustave u RAM - tmpfs (u Linuxu) ili mfs (u FreeBSD -u). Osim što to osigurava brisanje sadržaja nakon ponovnog pokretanja, također doprinosi izvedbi, na primjer, kompilaciji programa čiji se privremeni proizvodi ne zapisuju na disk, već se stavljaju u virtualni direktorij poput / tmp / obj.

Na mnogim sustavima vidjet ćete direktorije poput / usr / tmp i / var / tmp. To su obično simbolične veze na / tmp.

Strategija particioniranja datotečnog sustava

U zaključku razgovora o hijerarhiji datoteka valja naglasiti da samo direktoriji navedeni u stavku Root datotečni sustav... Svi ostali direktoriji - / usr, / opt, / var, / tmp i, naravno, / home mogu predstavljati točke montiranja neovisnih datotečnih sustava na zasebnim fizičkim medijima ili njihovim particijama.

Štoviše, u lokalnu mrežu ti se direktoriji mogu nalaziti čak i na različitim strojevima. Na primjer, jedno računalo koje djeluje kao aplikacijski poslužitelj može sadržavati direktorije / usr i / opt na mreži, drugo poslužitelj datoteka koje može sadržavati sve kućne direktorije korisnika itd.

Ostaje samo odlučiti koje je datotečne sustave poželjno izolirati iz zajedničkog stabla datoteka i zašto to učiniti. Odgovor na ova pitanja uvelike ovisi o OS -u koji se koristi, a u slučaju Linuxa i o njegovoj distribuciji. Ipak, mogu se navesti opća načela razdvajanja datotečnih sustava. Zašto bismo se trebali sjetiti suprotstavljanja, s jedne strane, nepromjenjivih i promjenjivih direktorija, s druge strane, lako oporavljivih, teško oporavljivih i praktički nepopravljivih podataka. Napravimo ovaj pokušaj u odnosu na radnu površinu korisnika - u slučaju poslužitelja izračuni će se značajno razlikovati.

Očito, korijenski datotečni sustav u direktorijima / bin, / boot, / etc, / root, / sbin, koji sadrži podatke koji se mogu lako oporaviti s distribucijskog medija i praktički nepromijenjen, trebao bi ležati na izoliranoj particiji diska. Na Linuxu treba dodati i / lib direktorij. S druge strane, kada se GRUB koristi kao pokretački program (neovisno o operativnom sustavu), preporučuje se premještanje direktorija / boot na zasebnu particiju.

U starim izvorima o Linuxu možete pročitati o još jednom razlogu dodjele particije za / boot direktorij, a na samom početku diska: zbog nemogućnosti učitavanja jezgre s Lilom s broja cilindra većeg od 1023. U moderne verzije pokretačkih programa, nema takvih ograničenja. Međutim, ako stvarate particiju za / boot, ima smisla učiniti je prvom na disku, a particiju za zamjenu postaviti izravno iza nje: to će dodati pet kopejki na brzinu prilikom izvođenja zamjene.

I također iz područja povijesti: zahtjev da root i boot particije svakako budu primarne također je odavno uklonjen. I ti se datotečni sustavi mogu uklopiti na logičke particije unutar proširene particije.

Jednako je jasno da se promjenjive grane datotečnog sustava - / var i / tmp - moraju premjestiti izvan korijenske particije. Štoviše, potonje je, kao što je već mnogo puta rečeno, općenito preporučljivo smjestiti u datotečni sustav u RAM -u (tmpfs ili mfs). U slučaju da direktorij / var sadrži poddirektorije za sustave za upravljanje paketima nalik portovima, poput / var / abs, / var / cache / pacman / src i / var / cache / pacman / pkg u Archlinuxu, oni bi također trebali formirati vlastitu datoteku sustava.

Sada direktorij / usr, koji sadrži ili komponente osnovnog sustava (kao u BSD -u) ili većinu korisničkih aplikacija (kao u većini distribucija Linuxa). Sadrži podatke koji se lako mogu oporaviti i, s dobrim razlogom, trebali bi biti praktički nepromjenjivi, pa stoga, naravno, zaslužuje istaknuti u neovisnom odjeljku. Štoviše, preporučljivo je izdvojiti iz njegova sastava, s jedne strane, poddirektorije / usr / X11R6 i / usr / local, s druge strane, poddirektorije za sustave za upravljanje paketima nalik portovima: / usr / portovi, / usr / pkgsrc i / usr / pkg u BSD sustavima., / usr / portages na Gentoo Linuxu i tako dalje. Štoviše, poddirektorije za postavljanje izvora preuzetih s mreže pri izgradnji portova treba odvojiti od potonjih - / usr / port / distfiles, / usr / pkgsrc / disfiles, / usr / portages / distfiles i slično.

U BSD sustavima, osim toga, ima smisla odvojiti od direktorija / usr poddirektorije / usr / src i / usr / obj, koji sadrže izvore osnovnih komponenti (uključujući jezgru) i njihove međuproizvode kompilacije, koji su generirane postupcima make buildworld i make buildkernel. ...

Konačno, direktorij / home, koji sadrži promjenjive i često nepopravljive podatke, mora se bez greške ukloniti iz korijena hijerarhije datoteka. I uvijek ga pokušavam postaviti ili na zasebnu krišku (u BSD -u) ili na primarnu particiju (u Linuxu).

Predložena shema particioniranja datotečnog sustava može se činiti pretjerano kompliciranom. Međutim, jamči izolaciju podataka koji se lako mogu oporaviti, teško ih je oporaviti i koje se ne mogu oporaviti, što olakšava ponovnu instalaciju sustava u hitnim slučajevima, pa čak i migraciju iz sustava u sustav.

Njegov dodatni plus je što za pojedine grane stabla datoteka, ovisno o prirodi podataka koji se na njemu nalaze, u Linuxu možete odabrati fizički optimalan datotečni sustav. Na primjer, nema smisla koristiti ništa osim Ext2fs za particiju pod / boot. Općenito se preporučuje formatiranje korijenske particije sa sigurnim, ali ipak najkompatibilnijim Ext3fs. Za direktorije s velikim brojem malih datoteka, poput / var / abs u Archlinux -u, / usr / portages u Gentoo -u, preporučljivo je koristiti ReiserFS: uostalom, vješto rukovanje malim datotekama je njegov profil. A u direktoriju / home, gdje se mogu pojaviti velike multimedijske datoteke (i koje su obično same po sebi vrlo velike), XFS bi mogao doći na sud (iako, kako mjerenja pokazuju, ReiserFS ovdje izgleda sasvim pristojno). Takve mjere mogu poboljšati i pouzdanost pohrane podataka i brzinu rada s datotekama.

Korisnici BSD operativnih sustava vezani su za datotečne sustave tipa FFS bez ikakve alternative. Međutim, oni također imaju manevarski prostor. Prvo, promjenom veličine bloka i fragmenta pojedinih datotečnih sustava, što doprinosi ili izvođenju operacija na disku ili uštedi prostora na disku. I drugo, neke grane stabla datoteka (poput / tmp ili / usr / obj, suprotno preporukama, mogu se neustrašivo montirati u čisto asinkroni način rada, dobivajući postotak ili dva u performansama.

Općenito o standardima

Među programerima postoji mišljenje da standardi u programiranju uopće nisu potrebni, jer:

(1) u početku su besmisleni, jer njihovi autori ne pišu računalne programe;

(2) oni koče inicijativu programera;

(3) programeri će se uvijek složiti bez standarda.

Možda na ovo mišljenje nije trebalo obratiti pažnju, ako ne u dvije okolnosti:

(1) izražavaju ga praktičari, odnosno upravo oni koji "izdaju softver";

(2) Gornje obrazloženje autor ovog članka otkrio je u jednoj od publikacija na internetu posvećenoj standardu za programski jezik C, iz koje je postalo jasno da je takvo mišljenje rašireno "na međunarodnoj razini", a ne samo među arogantnim ruskim "super programerima".

Riječ "standard" obično se povezuje s nečim materijalnim (standardne dimenzije, standardni električni napon itd.), Dok je računalni program nematerijalni objekt ("Novi neopipljivi"), a možda su standardi u neopipljivoj sferi zaista besmisleni?

Postoji, međutim, opovrgavajući primjer. Skup pravopisnih pravila ruskog jezika u biti je standard, iako ih tijela za standardizaciju nisu odobrila. Nadalje, osim pravila (ili, ako hoćete, zahtjeva) pravopisa, postoje i sintaksička pravila i, što je najvažnije, semantika. Ovo posljednje dobro ilustrira "djetinjasto" pitanje: zašto se mačka zove mačka? Na ovo pitanje postoji točan odgovor: jer su se naši preci tako slagali; preci Britanaca složili su se da istu zvijer zovu mačka, preci Nijemaca - mače itd. I općenito, značenje ili semantika ili pravila tumačenja bilo koje riječi ili kombinacije riječi stvar su dogovora.

Svrha i "super zadatak" standarda POSIX

Kao što naziv govori, POSIX (prijenosno sučelje operativnog sustava) standard je za sučelje (sučelje) između operacijskog sustava i aplikacijskog programa. Dani kada su programeri pisali programe za "goli" stroj (implementirajući vlastite pakete ulazno / izlaznih programa, trigonometrijske funkcije itd.) Prošli su zauvijek. POSIX tekst opetovano naglašava da standard ne nameće nikakve zahtjeve za pojedinosti o implementaciji operacijskog sustava; može se promatrati kao skup sporazuma između programera aplikacija i programera operativnih sustava. Stoga (opet, suprotno prilično raširenom mišljenju), POSIX nije od interesa samo za programere operacijskih sustava, nego se prije svega primjenjuje na mnogo brojniju kategoriju programera.

Potreba za standardom ove vrste prepoznata je još 1980 -ih, kada su UNIX operativni sustavi postali široko rasprostranjeni. Pokazalo se da iako je ovaj sustav zamišljen kao jedinstveni sustav, razlike između njegovih specifičnih implementacija dovele su do činjenice da se aplikacijski programi napisani za jedan sustav ne mogu uvijek izvršavati u drugom. POSIX nastoji riješiti ovaj problem, poznat kao problem prenosivosti softvera. Prvo izdanje standarda objavljeno je 1988. (postoji prijevod, vidi), u kojem je sva raznolikost pitanja vezanih za prenosivost programa podijeljena u dva dijela: (1) sučelje aplikacijskog programa, (2) tumač naredbi i pomoćni programi (korisničko sučelje); ti se dijelovi nazivaju POSIX.1, odnosno POSIX.2.

Pojasnimo da ćemo u ovom članku govoriti samo o standardu za sučelje aplikacijskog programa, POSIX.1, čije je drugo (i posljednje do sada) izdanje odobreno 12. srpnja 1996. godine.

U informativnom dijelu standarda također se naglašava da POSIX nije opis sučelja nekog "idealnog" operacijskog sustava, već je rezultat generalizacije i sistematizacije iskustva stečenog u razvoju UNIX operativnih sustava. Također, POSIX ne može poslužiti kao vodič ili vodič za učenje o operacijskim sustavima, iako informativni dio sadrži preporuke za programere i fragmente programa.

Standard izravno navodi da je nemoguće stvoriti punopravni operacijski sustav, fokusirajući se samo na funkcije sučelja opisane u njemu. (Konkretno, POSIX.1 ne rješava pitanja poput umrežavanja i povezanih funkcija sučelja ili grafičkog sučelja.) Međutim, financijski troškovi povezani s nepomičnošću programa i rezultirajućom potrebom za unifikacijom sučelja toliki su da većina prodavača preferira barem neki standard nego da ga nema. Iz tog razloga, mnogi programeri softvera nastoje se usredotočiti na POSIX. To omogućuje, ako ne potpuno ukloniti nepokretnost programa, onda barem značajno smanjiti nepokretni dio programa.

O semantici

Kao što je već spomenuto, POSIX se može promatrati kao skup sporazuma između programera operacijskog sustava i programera aplikacija. "Sporazum" znači, prije svega, isto tumačenje (semantiku) riječi i izraza. Slijede primjeri koji ilustriraju poteškoće u postizanju "sporazuma".

Kako prenijeti značenje u prijevodu

Prije svega, valja se podsjetiti da je standard POSIX napisan na engleskom jeziku, što po svojoj prirodi izaziva nejasnoće (na primjer, ista riječ može biti imenica, pridjev i glagol), a "semantičke zamke" čekaju na gotovo svaku stranicu. Dobra ilustracija ovoga je primjer iz fikcije. Jedno od najpoznatijih djela Oscara Wildea, koji je sjajno iskoristio ovu značajku engleskog jezika, - Važnost biti ozbiljan - na ruskom je poznat kao "Važnost ozbiljnosti". ali englesko ime ima drugo značenje: Earnest (ozbiljan) je ime jednog od likova, a ime bi se moglo prevesti drugačije: "Koliko je važno biti Ernst." Postoji rusko prezime Serebryany, a da postoji prezime Serious, prijevod bi bio savršeno točan, s prijenosom oba značenja.

Slična je situacija i sa samim imenom standarda: Prijenosno sučelje operacijskog sustava. Pridjev Prijenosni (mobilni) odnosi se i na operacijski sustav i na aplikacijski program, no ne može se izraziti tako kratko na ruskom, može se prevesti kao „sučelje mobilnog operacijskog sustava“ ili „sučelje operacijskog sustava koji pruža mobilnost aplikacijskih programa ”. Druga opcija bolje odražava namjere programera standarda, ali se istodobno gubi prvo značenje (tijekom prijevoda zadržana je poznatija prva opcija).

Semantika riječi "standard"

Glavnom tekstu standarda prethodi preambula koja objašnjava značenje riječi IEEE Standardi2. Kako slijedi iz ovih objašnjenja, postoje najmanje tri semantičke razlike od izraza GOST na ruskom jeziku:

(1) Intuitivno se vjeruje da GOST ima snagu zakona čije se kršenje procesuira; POSIX je skup zahtjeva čije je poštivanje potpuno dobrovoljno.

(2) GOST vrijedi do otkazivanja (mnogi su vjerojatno čuli izraz "GOST nije poništen"); preambula POSIX -a kaže da ako standard nije revidiran 5 godina, to znači da će pitanja o kojima se govori u njemu vjerojatno izgubiti relevantnost, pa se može smatrati da se automatski poništava;

(3) GOST je anoniman; uvodni dio POSIX -a daje popis onih koji su sudjelovali u razvoju ovog standarda, a također daje i adresu na koju se mogu slati zahtjevi za tumačenje; također se navodi da je odgovor na svaki zahtjev podložan postupku odobrenja (drugim riječima, autori standarda dogovaraju se prije nego što daju odgovor).

Stoga prijevod čak i tako poznate riječi kao što je Standard riječju "standard" zahtijeva komentare.

Semantika riječi "treba", "nije navedeno", "nije definirano", "definirano implementacijom"

Odjeljak 2 standarda naziva se terminologija i opći zahtjevi. Sadrži definicije ne samo posebnih pojmova (poput "procesa" ili "semafora"), već i takve naizgled razumljive riječi kao "treba" ili "može". Budući da je POSIX.1 standard sučelja, njegovi se zahtjevi primjenjuju i na operacijski sustav i na aplikacijski program. Izričit zahtjev izražen je riječju "must", na primjer: "Uspješno, funkcija link () mora vratiti nulu." U ovom primjeru govorimo o zahtjevu operacijskog sustava: funkcija link () mora biti implementirana tako da vraća nulu nakon uspjeha.

Izrazi "nije navedeno" i "nije definirano" izražavaju istu ideju da standard dopušta slobodu izbora, ali je značenje ovih pojmova različito. Izraz "nije navedeno" znači da govorimo o nekim ispravnim (radnjama, konstrukcijama programa itd.), A izraz "nije definirano" - o netočnim (pogrešnim). Informativni dio standarda nudi sljedeće objašnjenje.

Izraz "neodređeno" znači da se pretpostavlja da su poznate mnoge opcije (ishodi, pozivi funkcija itd.), A standard dopušta bilo koju od njih; u određenoj implementaciji operacijskog sustava može se izabrati bilo koji, a smatra se da je takav sustav u skladu sa standardom. Aplikacijski program (koji je strogo u skladu sa standardom) mora biti napisan tako da radi ispravno u bilo kojoj varijanti; kao takav, izraz implicitno izražava zahtjev za aplikacijski program.

Navedimo primjer: „Funkcija readdir () mora vratiti pokazivač na strukturu koja se odnosi na sljedeći element direktorija. Standard ne navodi nije li vraćene stavke kataloga pod nazivom "point" i "point-to-point". " U ovom primjeru postoje četiri moguća ishoda, a zahtjev za prijavu je da mora biti osmišljena za bilo koji od njih.

Drugi primjer: „Ako se funkcija sigwait () koja upućuje na čekanje signala s navedenim brojem pozove u nekoliko kontrolnih niti, onda kada signal stigne u najviše jednu od njih, sigwait () se mora vratiti. U kakvom će se toku upravljanja to dogoditi, standard ne precizira. " U ovom primjeru može biti mnogo više mogućih ishoda, ali svi su oni također poznati, a zahtjev za prijavu je da mora ispravno djelovati za bilo koji ishod.

Izraz "nije definirano" podrazumijeva da čak ni mnogi ishodi nisu poznati, bilo koji ishod je moguć, čak i katastrofalan (na primjer, pad sustava, gubitak podataka itd.). U biti, ovaj izraz implicitno izražava zahtjev da aplikacija ne koristi odgovarajuće podatke ili konstrukcije. Na primjer: "Ako se dirp argument readdir () ne odnosi na trenutno otvoreni direktorij, rezultat je nedefiniran."

Ovaj primjer zahtijeva da aplikacija zamijeni samo otvorenu referencu direktorija za argument funkcije readdir (); kršenje ovog zahtjeva može dovesti do katastrofalnih posljedica, a odgovornost za to snosi programer aplikacije.

Evo još jednog primjera: „Ako je uspješna, funkcija read () trebala bi vratiti cijeli broj koji predstavlja broj stvarno pročitanih bajtova. Inače, funkcija mora dodijeliti kôd pogreške errno i vratiti -1, a sadržaj međuspremnika na koji ukazuje buf je nedefiniran. "

Standard zabranjuje uporabu podataka iz međuspremnika u aplikacijskom programu u slučaju greške u funkciji read (), a posljedice kršenja ovog zahtjeva dodjeljuju se aplikacijskom programeru.

Značenje izraza "definirano implementacijom" različito je od intuitivnog. Očito, u određenom operacijskom sustavu ne može biti "neodređenog" ili "nedefiniranog" rezultata, neki će se specifični rezultat dobiti bez greške. Izraz "definirano implementacijom" izražava zahtjev standarda za dokumentacijom operacijskog sustava: rezultat ne samo da mora biti naveden (programer operacijskog sustava će to ionako morati učiniti), već i izričito biti odražen u dokumentaciji sustava.

Zadana semantika

Niti jedan regulatorni dokument ne može pokriti čitavu raznolikost slučajeva koji se mogu pojaviti u praksi, pa se o nečemu neizbježno šuti3. Na primjer, opis funkcije može reći da njezin argument može uzeti vrijednosti iz određenog raspona, ali se ne govori ništa o tome kakav će rezultat biti ako argument ne spada u ovaj raspon. Očito, kako bi se izbjegli nesporazumi, potrebno je imati jedinstvenu zadanu semantiku. U informativnom dijelu standarda postoji zanimljiv izraz: "općenito prihvaćena semantika zadane vrijednosti zabranjena je". Ova je izjava u suprotnosti s poznatim desetogodišnjim sloganom "sve je dopušteno što nije izričito zabranjeno". Očigledno, to je toliko ukorijenjeno u svijesti građana da se mnogi, čak ni programeri, ne slažu s citiranom izjavom standarda. U međuvremenu, ako upotreba bilo kojeg konstrukta nije izričito dopuštena i ne slijedi iz opisa, tada svaki programer shvaća da je njegova upotreba rizična, a ako ne uspije, ne pada mu na pamet podnijeti zahtjev.

Procesi i tokovi kontrole

Oba ova izraza izražavaju ideju paralelnog izvođenja. Operacijski sustav UNIX izvorno je zamišljen kao višekorisnički, a programi koje pokreću različiti korisnici moraju biti međusobno sigurno izolirani kako ne bi slučajno iskrivili "strane" podatke. Ova izolacija osigurana je činjenicom da se korisnički program izvršava unutar procesa koji se razvija u vlastitom virtualnom adresnom prostoru. Čak i ako program sadrži globalne podatke, kada se pokrene u različitim procesima, oni će se automatski "razvesti" u različite adresne prostore.

Međutim, procesni mehanizam nije sasvim zadovoljavajući pri programiranju zadataka u stvarnom vremenu. Aplikacija u stvarnom vremenu (koja radi u ime istog korisnika) često se može prirodno predstaviti kao istodobno izvršavanje komada nazvanih "niti". Njihova najznačajnija razlika od procesa je što se svi upravljački tokovi razvijaju u jednom adresnom prostoru; to omogućuje brz pristup globalnim podacima, ali istodobno postoji opasnost od njihovog nenamjernog izobličenja, a kako bi se to spriječilo, potrebno je pridržavati se neke programske discipline. Relevantne preporuke sadržane su u informativnom dijelu standarda.

Valja naglasiti da je ideja o višeslojnosti implementirana u mnoge operativne sustave u stvarnom vremenu, i implementirana na različite načine u smislu da svaka kontrolna nit ima drugačiji skup atributa i funkcija sučelja; ponekad se umjesto niti koristi izraz zadatak. Kako bi se izbjegla zabuna, standard naglašava da se bavi isključivo niti POSIX, a nazivi odgovarajućih funkcija sučelja imaju prefiks pthread_ (na primjer, pthread_create (), pthread_join () itd.).

Usklađenost sa standardom. Semantika riječi "podudaranje"

Intuitivno se vjeruje da će se, ako su dva predmeta izrađena u skladu s istim standardom, zajamčeno međusobno "pariti" i raditi zajedno u parovima; upravo je to svrha uvođenja standarda sučelja (sučelja). Budući da je POSIX standard za sučelje, možemo govoriti o usklađenosti sa standardom i operacijskog sustava i aplikacijskog programa.

Standard POSIX.1 sadrži nekoliko stotina (ako ne i tisuće) zahtjeva; smatra se samorazumljivim da ako barem jedan od njih nije ispunjen, tada sustav (ili aplikacijski program) nije u skladu sa standardom. Istodobno, do sada je napisano toliko operativnih sustava i aplikacijskih programa klase UNIX da je teško razumno zahtijevati potpunu usklađenost u navedenom smislu. Poteškoće u razvoju međunarodnih standarda ove vrste pogoršavaju postojanje različitih nacionalnih jezika. Čak i ako zaboravimo na aplikacijske programe namijenjene obradi tekstova na nacionalnim jezicima, gotovo svaki aplikacijski program mora izdati neku vrstu dijagnostičkih poruka i / ili percipirati tekstove koje unese operater.

• strogo poštivanje standarda POSIX.1;
• usklađenost s međunarodnom verzijom POSIX.1;
• usklađenost s nacionalnom verzijom POSIX.1;
• POSIX.1 usklađenost s proširenjima.

Drugo, mnoge mogućnosti sučelja su izborne; Standard zahtijeva da se izborne funkcije sučelja ponašaju kako je propisano standardom ili da uvijek vraćaju poseban kod pogreške, ENOSYS (što znači da funkcija nije implementirana). Opcije su podijeljene u nekoliko skupina, od kojih svaka odgovara određenoj konfiguracijskoj konstanti, koja je deklarirana (izrazom #define) u odgovarajućoj datoteci zaglavlja; to omogućuje otkrivanje je li funkcija implementirana tijekom faze sastavljanja.

Opisani način postizanja mobilnosti nisu izumili autori POSIX -a, već se dugo koristio u praksi; na mnogim operativnim sustavima konfiguracijske se konstante koriste za identifikaciju samog sustava ili njegove verzije. I ovdje standard ne nudi ništa bitno novo, već samo sistematizira postojeću praksu.

Objekti standardizacije i struktura standarda

Ukratko, standardizacijski objekti POSIX.1 su imena i semantika. Konkretnije, govorimo o sljedećem.

• Nazivi funkcija sučelja. 357 funkcija je standardizirano, sa 107 funkcija preuzetih iz standardnih C knjižnica (matematička, obrada nizova, ulaz / izlaz itd.); te se funkcije smatraju dijelom standarda POSIX.1, ali jesu Potpuni opis sadržan u standardu za programski jezik C.
• Imena vrsta podataka sustava. Ovi nazivi imaju sufiks sa _t.
• Imena datoteka zaglavlja, kao i minimalni sastav ovih datoteka.
• Imena globalnih varijabli na razini cijelog sustava (na primjer, errno).
• Simbolični nazivi kodova pogrešaka koji se mogu postaviti tijekom izvršavanja funkcije. Ovi nazivi počinju slovom E (EPERM, ENOTEMPTY, itd.).
• Imena stalnih konfiguracija. Ovi nazivi imaju prefiks _POSIX_.
• Simbolični nazivi brojeva signala; ti nazivi imaju prefiks SIG. Osim 20 "tradicionalnih" signala (SIGABRT, SIGALRM itd.), Standardizirani su i signali u stvarnom vremenu, čiji brojevi moraju zauzimati određeni kontinuirani raspon od SIGRTMIN do SIGRTMAX, uključujući najmanje RTSIG_MAX brojeve.
• Simbolični nazivi koji odgovaraju vrijednostima pojedinačnih argumenata nekih funkcija (na primjer, cmd argument funkcije fcntl () može poprimiti vrijednosti F_DUPFD, F_GETFD, F_GETLK itd.).
• Nazivi makronaredbi, konstanti, bit zastavica, varijabli okruženja.

Općenito, standard se sastoji od dva velika dijela približno istog volumena. Prva polovica - normativni dio - sadrži zahtjeve i preporuke standarda (18 odjeljaka), druga - informativni dio - sadrži dodatke koji sadrže popis referenci, komentara i objašnjenja normativnog dijela, sastav zaglavlja datoteke, primjer profila ("projekcija") standarda (za Dansku), karakteristike i metodologiju mjerenja izvedbe najvažnijih funkcija, kao i opis dodatnih funkcija sučelja za rad s datotekama u stvarnom vremenu; očekuje se da će u budućim izdanjima standarda ove funkcije biti uključene u normativni dio.

Bočna traka "Sažeci klauzula standarda" daje ideju o tome koje su vrste usluga operacijskog sustava obuhvaćene standardom.

Zaključak

Glavni sadržaj standarda POSIX je semantika funkcija sučelja. Standardizacija semantike nije lak posao sam po sebi (svi znaju koliko je teško postići dogovor čak i za dvije osobe), a poteškoće pogoršava činjenica da se trenutno mnogo ljudi bavi programiranjem. Na primjer, paradigma istodobnosti izražena je izrazima kao što su "proces", "zadatak" i "tijek upravljanja", ali s praktičnog programskog gledišta, "zadatak" u operativnom sustavu IBM OS / 360 i stvarnom vrijeme operacijski sustav VxWorks nije isti. a također. Drugi primjer su semafori. Semafori su binarni, cjelobrojni ("s brojačem") i međusobno isključivanje (koje, usput, programeri međusobno nazivaju "muteksima", spontano pokušavajući izbjeći nesporazume). I cjelobrojni semafori, na primjer, u operativnom sustavu VxWorks, uopće nisu isti kao POSIX semafori.

Autori standarda POSIX, svjesni koliko je teško nagovoriti ljude da napuste svoje navike (što nazivaju "ustaljenom praksom"), izjavljuju da su sastavili koherentan i minimalan sustav funkcija sučelja koje pokriva većinu usluga tradicionalno koje pruža operacijski sustav, detaljno je opisao točnu semantiku ovih funkcija i poziva sve da ih koriste u svom razvoju4.

Čitajući standard, ponekad se stječe dojam da je dio teksta imao samo jednu svrhu: ne ukloniti neke aplikacijske programe ili operacijske sustave iz kategorije koja zadovoljava standard. Takav je cilj doista postavljen i izričito formuliran u Uvodu: standard bi trebao uzeti u obzir što je više moguće prevladavajuću praksu. Međutim, glavni cilj je i dalje osigurati mobilnost aplikacijskih programa.

O autoru

Sergej Romanjuk - viši istraživač u Istraživačkom institutu za sistemska istraživanja, voditelj prevoditeljske grupe POSIX standard. Može se kontaktirati putem e -pošte na: [zaštićena e -pošta]

1 Treba dodati da se rad na standardu odvija već dugi niz godina; identificiraju se novi problemi koji su ili uključeni u jedan od postojećih dijelova, ili formalizirani kao zasebni dio, koji se naknadno može poništiti. To se dogodilo, na primjer, s front-end objektima u stvarnom vremenu, koji su u početku bili deklarirani kao POSIX.4, a kasnije uključeni u POSIX.1.

2 IEEE je organizacija koja je razvila standard POSIX.

3 Ovdje "zadano" znači tiho, a ne zadano; ne govorimo ni o kakvim impliciranim vrijednostima koje su zapravo deklarirane, već o odsustvu referenci uopće.

4 Ruski prijevod standarda bit će objavljen početkom 2000.

Književnost

Međunarodni standard ISO / IEC 9945-1 (ANSI / IEEE Std 1003.1) Drugo izdanje. 1996-07-12. Informacijska tehnologija - Prijenosno sučelje operativnih sustava (POSIX) - 1. dio: Sučelje aplikacijskog programskog sustava (API).

M.I. Belyakov, Yu.I. Rabover, A.L. Fridman. Mobilni operativni sustav. Imenik. Moskva, "Radio i komunikacija", 1991.

ISO / IEC 9899: 1990, Programski jezici- C.

Odjeljak 1	- Uvod
Odjeljak 2	- Terminologija i definicije
Odjeljak 3	- Funkcije za upravljanje procesima (stvaranje, zamjena slike, dovršavanje) i signale (upravljanje maskama, odgovaranje na signale)
Odjeljak 4	- Identifikacija (procesi, korisnici, sustav, terminal), ispitivanje vremena provedenog na izvođenju procesa, ispitivanje varijabli okruženja.
Odjeljak 5	- Upravljanje datotekama i direktorijima
Odjeljak 6	- Ulazne i izlazne funkcije
Odjeljak 7	- Upravljačke funkcije terminala
Odjeljak 8	- Funkcije posuđene iz jezičnog standarda C
Odjeljak 9	- Pristup bazama podataka korisnika i korisničkih skupina
Odjeljak 10	- Formati podataka za arhiviranje i razmjenu (tar i cpio)
Odjeljak 11	- Mogućnosti sinkronizacije: semafori, muteksi i varijable stanja
Odjeljak 12	- Funkcije upravljanja memorijom: prikvačivanje i otkačivanje adresnog prostora procesa, mapiranje datoteka u memoriju, zaštita memorije, zajednička memorija
Odjeljak 13	- Funkcije povezane s procesima planiranja i upravljanjem tijekovima
Odjeljak 14	- Upravljanje satom i odbrojavanjem vremena
Odjeljak 15	- Upravljanje redovima poruka
Odjeljak 16	- Osnovne funkcije vezane uz regulaciju tokova
Odjeljak 17	- Podaci specifični za niti
Odjeljak 18	- Sredstva za uništavanje kontrolnih tokova

Predmet: Operacijski sustavi.
Pitanje: Ne. 8

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

Principi izgradnje OS -a:

1.) Princip modularnosti- modul se općenito podrazumijeva kao funkcionalno cjelovit element sustava, izrađen u skladu s prihvaćenim intermodularnim sučeljima. Prema svojoj definiciji, modul pretpostavlja mogućnost jednostavne zamjene drugim modulom, pod uvjetom da su navedena sučelja dostupna. Podjela sustava na module u velikoj je mjeri određena korištenom metodom projektiranja OS-a (odozdo prema gore ili obrnuto).

Privilegirani moduli, moduli za ponovni pristup i ponovni pristup od posebne su važnosti pri izgradnji OS-a (ponovno ovlaštenje doslovno je ponovno dobivanje prava; poseban izraz za označavanje zdravlja programa; svojstvo programa da se ispravno izvršava s rekurzivni (uzvraćeni) poziv iz prekida).

Najveći učinak korištenjem ovog načela postiže se u slučaju istovremenog proširenja ovog načela na OS, aplikacijske programe i hardver.

2.) Princip funkcionalne selektivnosti- određeni dio važnih modula dodijeljen je OS -u, koji se mora stalno nalaziti u RAM -u radi učinkovitije organizacije računalnog procesa. Ovaj dio naziva se jezgra u OS -u, budući da je osnova sustava. Prilikom formiranja sastava jezgre moraju se uzeti u obzir dva oprečna zahtjeva. S jedne strane, najčešće korišteni moduli sustava trebali bi biti uključeni u jezgru, s druge strane, broj modula trebao bi biti takav da količina memorije koju jezgra zauzima nije prevelika. Osim softverskih modula koji su dio jezgre i koji se trajno nalaze u RAM -u, mogu postojati i mnogi drugi moduli sistemskog softvera koji se nazivaju tranzit. Tranzit softverski moduli učitava se u RAM samo po potrebi i u odsutnosti slobodan prostor mogu se zamijeniti drugim tranzitnim modulima.

3.) Načelo generiranja OS -a: Bit načela sastoji se u organiziranju (odabiru) takve metode za početnu prezentaciju programa upravljanja središnjim sustavom OS -a (jezgra i glavne komponente trajno smještene u RAM -u), što je omogućilo prilagodbu ovog nadzornog dijela sustava na temelju posebne konfiguracije određenog računalnog kompleksa i raspona zadataka koje treba riješiti. Ovaj se postupak rijetko provodi prije dovoljno dugog razdoblja rada OS -a. Proces generiranja provodi se pomoću posebnog programa za generiranje i odgovarajućeg jezika unosa za ovaj program, koji omogućuje opisivanje softverskih mogućnosti sustava i konfiguraciju stroja. Rezultat generacije je Puna verzija OS. Generirana verzija OS -a zbirka je sistemskih skupova modula i podataka.

4.) Princip funkcionalne redundancije: Ovo načelo uzima u obzir mogućnost izvođenja istog posla na različite načine. OS može uključivati ​​nekoliko vrsta monitora (nadzorni moduli koji kontroliraju jednu ili drugu vrstu resursa), različite načine organiziranja komunikacije između računalnih procesa. Prisutnost nekoliko vrsta monitora, nekoliko sustava za upravljanje datotekama omogućuje korisnicima brzo i najadekvatnije prilagođavanje OS -a određenoj konfiguraciji računalnog sustava, kako bi se osiguralo najučinkovitije učitavanje hardvera pri rješavanju određene klase problema, kako bi se postigao maksimum performanse pri rješavanju zadane klase problema.

5.) Princip virtualizacije: izgradnja virtualnih resursa, njihova distribucija i uporaba trenutno se koristi u gotovo svakom OS -u. Ovo načelo omogućuje vam da predstavite strukturu sustava u obliku određenog skupa rasporeda procesa i alokatora resursa (monitora) te koristite jednu centraliziranu shemu raspodjele resursa.

Najprirodnija i najpotpunija manifestacija koncepta virtualnosti je koncept virtualni stroj ... Virtualni stroj koji se daje korisniku reproducira arhitekturu pravog stroja, ali arhitektonski elementi u ovom prikazu izlaze s novim ili poboljšanim karakteristikama, koje u pravilu pojednostavljuju rad sa sustavom. Karakteristike mogu biti proizvoljne, ali najčešće korisnici žele imati svoj "idealan" stroj u smislu arhitektonskih karakteristika, u sljedećem sastavu:

- virtualna memorija praktički neograničenog volumena, ujednačena u smislu logike rada.

- proizvoljan broj virtualnih procesora koji mogu raditi paralelno i međusobno djelovati tijekom rada.

- proizvoljan broj vanjskih virtualnih uređaja koji mogu paralelno ili uzastopno, asinkrono ili sinkrono raditi s memorijom virtualnog stroja s obzirom na rad jednog ili drugog virtualnog procesora koji pokreće rad ovih uređaja.

Jedan od aspekata virtualizacije je organizacija mogućnosti izvođenja u danom OS aplikacijama koje su razvijene za druge OS. Drugim riječima, govorimo o organiziranju nekoliko operativnih okruženja.

6.) Načelo neovisnosti programa od vanjskih uređaja: ovaj se princip sada primjenjuje u velikoj većini operativnih sustava opće namjene. Prvi put je ovo načelo najdosljednije implementirano u UNIX OS. Također je implementiran u većinu modernih PC operativnih sustava. Ovo načelo leži u činjenici da se povezivanje programa sa određenim uređajima ne provodi na razini emitiranja programa, već tijekom razdoblja planiranja njegova izvođenja. Zbog toga nije potrebno ponovno kompajliranje kada se program izvodi s novim uređajem na kojem se nalaze podaci.

7.) Načelo kompatibilnosti: jedan od aspekata kompatibilnosti je sposobnost OS -a da pokreće programe napisane za drugi OS ili za starije verzije ovog OS -a, kao i za drugu hardversku platformu. Pitanja je potrebno odvojiti binarna kompatibilnost i kompatibilnost izvora aplikacije.

Binarna kompatibilnost postiže se kada možete uzeti izvršni program i pokrenuti ga na drugom OS -u. To zahtijeva kompatibilnost na razini procesorskih uputa i kompatibilnost na razini sistemskih poziva, pa čak i na razini knjižničnih poziva, ako su dinamički povezani.

Kompatibilnost izvora zahtijeva odgovarajućeg prevoditelja u softveru sustava, kao i kompatibilnost knjižnice i sistemskih poziva. U tom je slučaju potrebno ponovno kompajlirati postojeće izvorne tekstove u novi izvršni modul.

Mnogo je teže postići binarnu kompatibilnost između procesora na temelju različitih arhitektura. Da bi jedno računalo izvršavalo programe drugog (na primjer, program za osobno računalo, poput IBM računala, poželjno je izvoditi na računalu, poput Apple Macintosha), ovo računalo mora raditi s strojnim uputama koje u početku ne radi razumjeti. U tom slučaju mora se izvršiti procesor 680x0 (ili PowerPC) binarni kod dizajniran za procesor i80x86. Procesor 80x86 ima svoj dekoder instrukcija, registre i unutarnju arhitekturu. Procesor 680x0 ne razumije binarni format 80x86, pa mora odabrati svaku naredbu, dekodirati je kako bi utvrdio je li

što namjerava učiniti, a zatim izvršiti ekvivalentnu potprogram napisanu za 680 × 0.

Jedan od načina osiguravanja kompatibilnosti softvera i korisničkog sučelja je usklađenost sa standardima POSIX, čija vam upotreba omogućuje stvaranje programa u stilu UNIX-a koji se kasnije lako prenose s jednog sustava na drugi.

8.) Načelo otvorenosti i skalabilnosti: Otvoreni operacijski sustav dostupan je za analizu i korisnicima i stručnjacima za sustav koji održavaju računalni sustav. Proširivi (modificirani, razvijeni) OS omogućuje ne samo korištenje generacijskih mogućnosti, već i uvođenje novih modula u njegov sastav, poboljšanje postojećih itd. Drugim riječima, trebalo bi biti moguće jednostavno unositi dopune i izmjene po potrebi bez ugrožavanja integriteta sustava. Pristup klijent-poslužitelj strukturiranju OS-a pomoću mikro-nuklearne tehnologije pruža izvrsne mogućnosti za proširenje. U skladu s ovim pristupom, OS je izgrađen kao skup privilegiranih programa upravljanja i skup neprivilegiranih usluga (poslužitelja). Glavni dio OS -a ostaje nepromijenjen, a istodobno se mogu dodati novi poslužitelji ili poboljšati stari. Ovo se načelo ponekad tumači kao proširivost sustava.

9.) Princip mobilnosti: operativni sustav trebao bi biti relativno lak za nošenje

Povežite se s jedne vrste procesora na drugu vrstu procesora i s hardverske platforme jednog tipa, koja uključuje, uz vrstu procesora i način organiziranja cjelokupnog računalnog hardvera (arhitektura računalnog sustava), na drugu vrstu hardverske platforme. Imajte na umu da je načelo prenosivosti vrlo blizu načelu kompatibilnosti, iako nisu ista stvar. Pisanje prijenosnog OS -a slično je pisanju bilo kojeg prijenosnog koda, ali morate se pridržavati nekih pravila:

- većina OS -a mora biti izvedena na jeziku koji je dostupan na svim sustavima na koje se kasnije planira prenijeti. To, prije svega, znači da OS mora biti napisan na jeziku visoka razina, po mogućnosti standardizirano, na primjer u C. Program koji je napisan u sklopu nije općenito prenosiv.

- važno je minimizirati ili, ako je moguće, isključiti one dijelove koda koji izravno stupaju u interakciju s hardverom. Ovisnost o hardveru može imati mnogo oblika. Neki očiti oblici ovisnosti uključuju izravnu manipulaciju registrima i drugim hardverom. Konačno, ako se hardverski ovisni kôd ne može potpuno isključiti, tada ga treba izolirati u nekoliko dobro lokaliziranih modula. Kôd ovisan o hardveru ne mora se distribuirati po cijelom sustavu. Na primjer, možete sakriti hardverski ovisnu strukturu u programabilnoj apstraktnoj vrsti podataka.

Uvođenje POSIX standarda imalo je za cilj osigurati prenosivost stvorenog softvera.

10.) Računalni sigurnosni princip: Osiguravanje računalne sigurnosti poželjna je značajka svakog višekorisničkog sustava. Sigurnosna pravila definiraju svojstva kao što su zaštita resursa jednog korisnika od drugih i postavljanje kvota resursa kako bi spriječili jednog korisnika da preuzme sve sistemske resurse, poput memorije.

Osiguravanje zaštite informacija od neovlaštenog pristupa obvezna je funkcija mrežnih operativnih sustava.

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

ŠtoPOSIX: sučelje sustava neovisno o platformi za računalno okruženje POSIX (Prijenosno sučelje operativnih sustava za računalna okruženja) standard je IEEE (Institut inženjera elektrotehnike i elektronike) koji opisuje sučelja sustava za otvorene operacijske sustave, uključujući ljuske, pomoćne programe i komplete alata. Osim toga, POSIX standardizirani sigurnosni zadaci, zadaci u stvarnom vremenu, administrativni procesi, mrežne funkcije i obrada transakcija. Standard se temelji na UNIX sustavima, ali se može implementirati i u druge operacijske sustave. POSIX je nastao kao pokušaj diljem svijeta dobro poznata organizacija IEEE promiče prijenos aplikacija u UNIX okruženjima razvijanjem apstraktnog standarda neovisnog o platformi. Na primjer, dobro poznati OS QNX u stvarnom vremenu u skladu je sa specifikacijama ovog standarda.

Ovaj standard detaljno opisuje virtualni memorijski sustav VMS (Virtual Memory System), MPE (Multi-Process Executing) multitasking i Konvergentnu tehnologiju proizvedenu u operacijskom sustavu ... (CTOS). Dakle, POSIX je zapravo skup standarda koji se naziva POSIX.I –POSIX.12. Također treba napomenuti da POSIX.1 pretpostavlja C kao glavni jezik.

Jezik opisa funkcija API -ja.

Dakle, programi napisani u skladu s ovim standardima izvodit će se identično na svim sustavima usklađenim s POSIX-om. Međutim, u nekim slučajevima standard je samo savjetodavne prirode. Neki od standarda opisani su vrlo strogo, dok drugi dio samo površno otkriva osnovne zahtjeve.

Implementacije POSIX API -ja operativnih sustava različite su. Ako je velika većina UNIX sustava u početku u skladu sa specifikacijama IEEE standarda 1003.1-1990, tada WinAPI nije usklađen s POSIX-om. Međutim, kako bi se ovaj standard podržao u operacijskom sustavu MS Windows NT, uveden je poseban modul za podršku POSIX API -ja koji radi na razini privilegija korisničkih procesa.

Ovaj modul omogućuje pretvaranje i prijenos poziva iz korisničkog programa u jezgru sustava i natrag, radeći s jezgrom putem Win API -ja. Druge aplikacije izgrađene pomoću WinAPI -a mogu proslijediti informacije POSIX aplikacijama putem standardnih mehanizama I / O toka (stdin, stdout).

Nema povezanih postova ...