Predmet preučuje standard za vmesnik mobilnega operacijskega sistema (POSIX) ter tehnike in metode za programiranje aplikacij na podlagi tega standarda, ki jih ponazarjajo številni primeri. Dotikajo se vprašanja programiranja večprocesnih sistemov, interakcije aplikacij v okviru porazdeljenih konfiguracij. Zagotavljanje mobilnosti (prenosljivost, prenosljivost) programsko opremo(PO) - naloga izjemnega pomena in kompleksnosti; Dandanes ta okoliščina skoraj ne potrebuje obsežne utemeljitve. Eden od splošno sprejetih načinov za povečanje mobilnosti programske opreme je standardizacija aplikacijskega okolja: zagotovljeni programski vmesniki, pripomočki itd. Na ravni sistemskih storitev takšno okolje opisuje standard POSIX (prenosni vmesnik operacijskega sistema); ime je predlagal slavni specialist, ustanovitelj Fundacije za brezplačno programsko opremo Richard Stallman.

Predmet preučuje njegovo najnovejšo različico v izdaji 2003, ki ji lahko rečemo "trojni standard", in sicer: standard IEEE Std 1003.1, tehnični standard Open Group in, kar je za nas najpomembneje, mednarodni ISO / IEC 9945 Ta tečaj govori o razumevanju tehnik in metod uporabe standardiziranih pripomočkov in funkcij. Cilj ni bil ponoviti standarda in poudariti vse tankosti izvajanja OS, vse možne kode napak itd. Glavna stvar je po našem mnenju začutiti duh standarda, se naučiti uporabljati možnosti, ki so zanj povezane, na mobilni način. Ob predpostavki, da bralec tekoče govori C, nismo upoštevali niti njegove skladnje niti funkcij knjižnice učbenikov. Kar zadeva standardni ukazni jezik in njegovega tolmača, je ta tema podrobno opisana, čeprav mnogi programerji raje uporabljajo druge tolmače. Pomembno mesto - tako po obsegu kot po vlogi - imajo primeri programov. Številne določbe standarda (povezane, recimo, z obravnavanjem napak) niso navedene v glavnem besedilu, ampak v ustreznih primerih. stopnjo ali drugo, ki trdi, da je v skladu s standardom POSIX. Vsekakor pa so možni spregledi. Hvaležni bomo za vse pripombe in predloge v zvezi s tečajem kot celoto in posameznimi primeri programov.

Zgodovina nastanka in trenutno stanje standarda POSIX.

Zagotavljanje mobilnosti (prenosljivosti, prenosljivosti) programske opreme (SW) je naloga izjemnega pomena in kompleksnosti; v našem času ta okoliščina komaj potrebuje obsežno utemeljitev. Eden od splošno sprejetih načinov za povečanje prenosljivosti programske opreme je standardizacija aplikacijskega okolja: zagotovljeni API -ji, pripomočki itd. Na ravni sistemskih storitev je takšno okolje opisano s standardom POSIX (prenosni vmesnik operacijskega sistema); ime je predlagal znani strokovnjak, ustanovitelj Fundacije za brezplačno programsko opremo Richard Stallman.

Naslovna stran.
Izhod.
Predavanje 1. Osnovni pojmi in zamisli standarda POSIX.
Predavanje 2. Jezik lupine.
Predavanje 3. Pripomočki in funkcije, ki služijo konceptu "uporabnika".
Predavanje 4. Organizacija datotečnega sistema.
Predavanje 5. Vnos / izhod datoteke.
Predavanje 6. Orodja za obdelavo strukturiranih podatkov.
Predavanje 7. Procesi.
Predavanje 8. Sredstva medprocesne komunikacije.
Predavanje 9. Skupni terminalski vmesnik.
Predavanje 10. Vprašanje značilnosti gostitelja in njihova uporaba v aplikacijah.
Predavanje 11. Omrežne zmogljivosti.
Predavanje 12. Čas in delo z njim.
Predavanje 13. Jezikovno in kulturno okolje.
Predavanje 14. Sklep.
Bibliografija.

Brezplačen prenos e-knjiga v priročni obliki si oglejte in preberite:
Prenesite knjigo Programiranje v standardu POSIX, 1. del, Galatenko V.A., 2016 - fileskachat.com, hiter in brezplačen prenos.

POSIX in RV OS: poskus sistematizacije

Sergej Zolotarev, Nikolaj Gorbunov

Namen tega članka je poskusiti vnesti nekaj jasnosti v zgodovino razvoja standarda POSIX, ki se uporablja za operacijske sisteme v realnem času (RT OS).

Kot uvod: zakaj je potrebna standardizacija programskega vmesnika?

Ena najpomembnejših značilnosti standarda POSIX je, da opredeljuje "standardiziran programski vmesnik", ki se ga morajo držati razvijalci zapletenih sistemov programske in strojne opreme. Ustvarjalci teh sistemov so prisiljeni soočiti se z zahtevami, kot so omejen čas trženja (zaradi ostre konkurence), zmanjšanje stroškov in pospešitev donosa. Hkrati je levji delež stroškov zaradi upočasnitve razvojnega procesa posledica dejstva, da morajo programerji "znova odkriti kolo", vedno znova izvajati funkcionalnost, ki je že dolgo na voljo. Temu pa bi se lahko izognili:

• ponovna uporaba kode iz preteklih in vzporednih projektov;
• prenos kode iz drugih operacijskih sistemov;
• privabljanje razvijalcev iz drugih projektov (tudi tistih, ki uporabljajo druge operacijske sisteme).

Vse to je mogoče zaradi uporabe OS s standardiziranim API -jem. Še več, če v prvem primeru za organizacijo zadostuje določen notranji standard (kar je še posebej značilno za lastniške operacijske sisteme), potem v drugih dveh primerih le obstajata prisotnost splošno sprejetih standardov - na primer POSIX.

Tako razvijalec, ki uporablja operacijski sistem, združljiv s POSIX, kot platformo za svoje projekte, dobi priložnost, da končno kodo prenese na raven izvorne kode tako iz svojih preteklih ali vzporednih projektov kot iz projektov tretjih oseb. To ne le bistveno skrajša čas razvoja programske opreme, ampak tudi izboljša njeno kakovost, saj preizkušena koda vedno vsebuje manj napak.

Kdo je kdo v razvoju POSIX

Ne bomo začeli s samim standardom POSIX, ampak z urejanjem vloge organizacij, ki sodelujejo pri delu na njem.

Prvi udeleženec je IEEE(Inštitut inženirjev elektrotehnike in elektronike, Inštitut inženirjev elektrotehnike in elektronike), javno neprofitno združenje strokovnjakov. IEEE sega v leto 1884 (uradno - iz leta 1963), združuje 380.000 posameznih članov iz 150 držav, izda tretji del tehnične literature, povezane z uporabo računalnikov, krmiljenja, električne in informacijske tehnologije, pa tudi več kot 100 revij. priljubljen med profesionalci; poleg tega ima društvo več kot 300 večjih konferenc na leto. IEEE je sodeloval pri razvoju več kot 900 obstoječih standardov (www.ieee.ru/ieee.htm). Danes se ta inštitut ukvarja s pripravo, usklajevanjem, odobritvijo, objavo standardov, vendar zaradi svojega formalnega statusa nima pooblastil za sprejemanje takih dokumentov kot mednarodnih ali nacionalnih standardov. Zato bi morali izraz "standard" v razumevanju IEEE raje razumeti kot "specifikacijo", ki je bolj skladna s statusom dokumentov, ki jih sprejema združenje. V skladu z IEEE sodeluje v programih številnih mednarodnih in regionalnih organizacij - IEC, ISO, ITU (Mednarodna zveza za telekomunikacije), ETSI (Evropski inštitut za telekomunikacijske standarde), CENELEC (Evropski odbor za standardizacijo elektrotehnike) in v nacionalnih programi, na primer v programu take organizacije, kot je ANSI.

IEEE vključuje PASC (Portable Application Standards Committee), združenje, ki razvija družino standardov POSIX (www.pasc.org/). PASC je bil prej znan kot Tehnični odbor za operacijske sisteme.

Drugi udeleženec pri delu - ANSI(American National Standards Institute, American National Standards Institute) - zasebna neprofitna organizacija, ki v Združenih državah upravlja in usklajuje dejavnosti standardizacije. Zaposluje le 75 ljudi, ANSI pa ima več kot 1000 članov, podjetij, organizacij, vladnih agencij in institucij (www.ansi.org). ANSI zastopa Združene države v dveh glavnih mednarodnih standardizacijskih organih, ISO in IEC.

Tretji udeleženec - ISO(Mednarodna organizacija za standardizacijo). Ustanovljen je bil leta 1946 z odločbo Odbora za usklajevanje standardov in Generalne skupščine ZN, uradno pa je začel delovati 23. februarja 1947 (www.iso.org). ISO je mreža nacionalnih institutov za standarde iz 146 držav (ena država - ena članica ISO) s centralnim sekretariatom v Ženevi (Švica). Standardi ISO se razvijajo v tehničnih odborih, katerih prvi rezultat je osnutek mednarodnega standarda (DIS), ki po več odobritvah postane končni osnutek mednarodnega standarda (FDIS). Po tem se glasuje o vprašanju odobritve tega dokumenta; če uspe, postane mednarodni standard.

In končno - IEC(Mednarodna elektrotehniška komisija, Mednarodna elektrotehniška komisija - IEC), ustanovljena leta 1906, pripravlja in objavlja mednarodne standarde za vse električne, elektronske in sorodne tehnologije (www.iec.ch/). Od 1. novembra 2004 so bili nacionalni odbori 64 držav aktivni člani te komisije. IEC objavlja tudi priporočila, ki so objavljena v angleškem in francoskem jeziku ter imajo status mednarodnih standardov. Na njihovi podlagi se razvijajo regionalni in nacionalni standardi. Tehnični odbori (TC) so odgovorni za pripravo standardov na različnih področjih dejavnosti IEC, v katerih sodelujejo nacionalni odbori, ki jih zanimajo dejavnosti določenega tehničnega odbora.

IEC je ključna organizacija pri pripravi mednarodnih standardov informacijske tehnologije. Na tem področju obstaja skupni tehnični odbor za informacijsko tehnologijo - JTC 1, ustanovljen leta 1987 v skladu s sporazumom med IEC in ISO. JTC1 ima 17 pododborov, ki nadzorujejo vse, od programske opreme do programskih jezikov, računalniške grafike in urejanja slik, povezovanja opreme in varnostnih praks.

Priprava novih standardov IEC vključuje več stopenj (predhodna, stopnja predloga, pripravljalna faza, stopnja tehničnega odbora, stopnja zahteve, stopnja odobritve, objava). Če naj bi dokument IEC postal le tehnična specifikacija in ne mednarodni standard, se revidirana različica dokumenta pošlje na sedež v objavo. Končni osnutek mednarodnega standarda (FDIS) bo trajal štiri mesece. Če ga odobrijo vsi člani tehničnega odbora, se pošlje v centralni urad za objavo brez odobritve FDIS. Po tem FDIS odide v nacionalne odbore, ki ga morajo odobriti v dveh mesecih. FDIS velja za odobrenega, če je zanj glasovalo več kot dve tretjini nacionalnih odborov, število negativnih glasov pa ne presega 25%. Če dokument ni odobren, se pošlje v revizijo tehničnim in pododborom. Standard je treba objaviti najpozneje dva meseca po odobritvi FDIS.

Pri razvoju in sprejetju standardov POSIX je vključenih več drugih organizacij.

Odprta skupina Je mednarodna organizacija za standardizacijo programske opreme, ki združuje skoraj 200 proizvajalcev in uporabniških skupnosti, ki delujejo na področju informacijske tehnologije (www.opengroup.org/). Odprta skupina je bila ustanovljena leta 1995 z združitvijo dveh predhodnikov: X / Open in Open Software Foundation (OSF). Skupina Open je specializirana za razvoj metodologij certificiranja programske opreme in testiranje skladnosti. Odprta skupina ponuja zlasti certifikate za področja, kot so platforma COE, CORBA, LDAP, Linux Standard Base, okvir za interoperabilnost šol (SIF), prehod S / MIME, enotna specifikacija UNIX, specifikacije brezžičnega aplikacijskega protokola (WAP) in končno POSIX družino standardov (www.opengroup.org/certification/).

Skupina za revizijo skupnih standardov Austina (CSRG)- skupno tehnično delovna skupina ustanovljena leta 2002 s strani ISO, IEC in Open Group za ustvarjanje in vzdrževanje najnovejše različice standard 1003.1, ki bo oblikovan na podlagi ISO / IEC 9945-1-1996, ISO / IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 in enotne specifikacije UNIX (www.opengroup.org / press/ 14nov02.htm).

Nacionalni inštitut za standarde in tehnologijo (NIST)- zvezna agencija v okviru Uprave za tehnologijo Ministrstva za trgovino (www.nist.gov/public_a Affairs/general2.htm), ustanovljena v ZDA leta 1901. Poslanstvo NIST je razvijati in spodbujati standarde in tehnologije za izboljšanje kakovosti izdelkov. NIST vključuje Laboratorij za informacijsko tehnologijo (ITL), katerega eden od rezultatov so Zvezni standardi obdelave informacij (FIPS, www.opengroup.org/testing/fips/general_info.html). NIST / ITL je leta 1991 ponudil začetni niz testov za certificiranje POSIX po FIPS PUB 151-1 1990.

Kaj je POSIX?

Formalno izraz POSIX ki ga je Richard Stallman predlagal kot okrajšavo za P ortable O perating S ystem vmesnik za un IX(prenosni vmesnik operacijskega sistema za Unix). POSIX je bil razvit za operacijske sisteme, podobne UNIX-u (njihove najzgodnejše različice segajo v zgodnja sedemdeseta leta prejšnjega stoletja), s ciljem zagotoviti prenosljivost virov za aplikacije.

Začetni opis vmesnika je bil objavljen leta 1986, ko se je imenoval IEEE-IX (IEEE-jeva različica UNIX-a), vendar se je ime hitro spremenilo in postalo POSIX, že v naslednji objavi (nazaj leta 1986) pa ta nova različica je bil nekaj časa uporabljen POSIX kot sklic (ali sinonim) na skupino sorodnih dokumentov IEEE 1003.1-1988 in dele ISO / IEC 9945 ter kot popoln in odobren mednarodni standard ISO / IEC 9945.1: 1990 POSIX je bil sprejet leta 1990. Specifikacije POSIX opredeljujejo standardni mehanizem za interakcijo med aplikacijskim programom in OS in trenutno vključujejo več kot 30 standardov pod okriljem IEEE, ISO, IEC in ANSI.

POSIX je skozi svojo zgodovino prišel daleč, saj so se imenovanje specifikacij, njihova posebna vsebina, postopki in logistika njihovega preverjanja večkrat spremenili. Od takrat je bilo v okviru različnih mednarodnih organizacij izdanih več izdaj standarda POSIX.

Zgodovina razvoja standarda POSIX

Prva različica specifikacije IEEE Std 1003.1 je bila objavljena leta 1988. Nato so bile kot mednarodni standardi sprejete številne izdaje standarda IEEE Std 1003.1.

Faze razvoja POSIX:

1990 leto

Izdaja, ki je izšla leta 1988, je bila revidirana in je postala podlaga za nadaljnje spremembe in dopolnitve. Odobren je kot mednarodni standard ISO / IEC 9945-1: 1990.

1993 leto

Izšla je izdaja 1003.1b-1993.

1996 leto

Spremembe so bile narejene v IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 in 1003.1i-1995, vendar večina dokumenta ostaja nespremenjena. Leta 1996 je bila revizija standarda IEEE Std 1003.1 odobrena tudi kot mednarodni standard ISO / IEC 9945-1: 1996.

1998 leto

Pojavil se je prvi standard za "real time" - IEEE Std 1003.13-1998. Je razširitev standarda POSIX za vgrajene aplikacije v realnem času.

1999 leto

Odločeno je bilo, da se v zadnjih desetih letih izvedejo prve pomembne spremembe v glavnem besedilu standarda, vključno z združitvijo s standardom 1003.2 (Shell in komunalne storitve), saj so bili takrat ločeni standardi. PASC se je odločil, da bo dokončal spremembe osnovnega besedila po dokončanju standardov IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q in 1003.2b.

2004 r.

Zadnja revizija standarda 1003.1 je bila objavljena 30. aprila in izdana pod okriljem skupine za revizijo skupnih standardov v Austinu. Spremenjen je za izdajo standarda iz leta 2001. Formalno je izdaja iz leta 2004 znana kot IEEE Std 1003.1, izdaja 2004, Tehnične standardne specifikacije odprte skupine, številka 6 in vključuje IEEE Std 1003.1-2001, IEEE Std 1003.1-2001 / Cor 1-2002 in IEEE Std 1003.1-2001 / Cor 2-2004.

Najpomembnejši standardi POSIX za OS RV

Za operacijske sisteme v realnem času je najpomembnejših sedem specifikacij standarda (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), vendar so le tri dobile široko podporo v komercialnih operacijskih sistemih:

• 1003.1a (definicija OS) opredeljuje glavne vmesnike OS, nadzor opravil, signale, funkcije datotečnega sistema in delo z napravami, uporabniškimi skupinami, cevovodi, vmesniki FIFO;
• 1003.1b (razširitve v realnem času) opisuje razširitve v realnem času, kot so signali v realnem času, prednostno razporejanje, časovniki, sinhroni in asinhroni V / I, semaforji, skupni pomnilnik, sporočila. Sprva (pred letom 1993) se je ta standard imenoval POSIX.4.
• 1003.1c (niti) opredeljuje podporne funkcije niti - nadzor niti, atribute niti, mutekse, odpremo. Prvotno označeno kot POSIX.4a.

Poleg teh standardov so za OS RT pomembni naslednji standardi, ki so bili izvedeni v okviru dela na projektu Std 1003.1-2001:

• IEEE 1003.1d-1999. Dodatne razširitve v realnem času. Prvotno označeno kot POSIX.4b;
• IEEE 1003.1j-2000. Izboljšane (napredne) razširitve v realnem času;
• IEEE 1003.1q-2000. Sledenje.

Postopek certificiranja

Da bi bil operacijski sistem skladen s POSIX, mora biti certificiran glede na ustrezen testni paket. Od uvedbe POSIX -a je testni paket doživel formalne in de facto spremembe.

Leta 1991 je NIST razvil testni program POSIX v skladu s FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). Ta preskusna možnost je temeljila na IEEE 1003.3 "Standard za preskusne metode za merjenje skladnosti s POSIX" Osnutek 10., 3. maja 1989. Leta 1993 je NIST dokončal preskusni program POSIX za FIPS 151-1 in začel program za FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 je prilagodil "Informacijska tehnologija - vmesnik prenosnih operacijskih sistemov (POSIX) - 1. del: Vmesnik sistemskega aplikacijskega programa (API)", ki je standard ISO / IEC 9945-1: 1990. Testni paketi za FIPS 151-2 so temeljili na IEEE 2003.1-1992 "Standard za preskusne metode za merjenje skladnosti s POSIX".

NIST razlikuje dve metodologiji certificiranja: samocertificiranje in certificiranje s strani IEEE akreditiranih preskuševalnih laboratorijev (akreditirani preskusni laboratoriji POSIX - APTL). V prvem primeru podjetje samostojno izvaja testiranje, vendar v skladu z načrtom, ki ga je odobril NIST. V drugem primeru testiranje izvaja neodvisen laboratorij z uporabo avtomatskih testnih paketov. Skupaj sta bila akreditirana dva laboratorija APTL: Mindcraft (www.mindcraft.com) in Perennial (www.peren.com).

Leta 1997 je NIST / ITL napovedal svojo namero, da konec tega leta (uradno 31. decembra 1997) preneha s certificiranjem FIPS 151-2, medtem ko je Odprta skupina napovedala, da ga bo prevzela od 1. oktobra istega leta. let certifikacijske storitve v skladu s FIPS 151-2 na podlagi programa NIST / ITL. Iste funkcije je od 1. januarja 1998 prevzelo Združenje standardov IEEE (IEEE-SA) in tudi na podlagi FIPS 151-2.

Leta 2003 sta IEEE-SA in Open Group objavila nov skupni program certificiranja najnovejših različic POSIX, začenši z IEEE 1003.1 ™ 2001. Odprta skupina ima zdaj več testnih paketov, ki pokrivajo IEEE Std 1003.1-1996, IEEE Std 1003.2- 1992, IEEE Std 1003.1-2003 in IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Izdelek velja za POSIX certificiran, če je opravil celoten postopek certificiranja, glede na rezultate preskusov izpolnjuje vse zahteve in je vpisan v uradni register certificiranih izdelkov.

Testni paketi vključujejo:

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm)-niz preskusov skladnosti za sistemske vmesnike IEEE Std 1003.1-1990;
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - niz preskusov skladnosti za IEEE Std 1003.13-1998 Profil PSE54 (večnamenski v realnem času);
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm)-niz preskusov skladnosti za sistemske vmesnike IEEE Std 1003.1-2003 (samo obvezni deli);
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) je niz preskusov skladnosti za IEEE Std 1003.1-2003 (lupina in pripomočki-samo obvezni deli).

Poleg tega je skupina Open razvila merila za standarde POSIX v realnem času in profil vgrajenih standardov POSIX. POSIX Realtime Test Suite (www.opengroup.org/testing/testsuites/realtime.html) vključuje naslednje teste:

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Razširitev v realnem času in IEEE POSIX 1003.1,2003 Edition;
• IEEE Std POSIX 1003.1c-1995 Threads (pthreads) razširitev in IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1d-1999 Dodatna razširitev v realnem času in IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1j-2000 Advanced Realtime Extension in IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1q-2000 Trace in IEEE POSIX 1003.1,2003 Edition ter IEEE POSIX 1003.1,2003 Edition;

Testni paket vgrajenega profila standardov POSIX (www.opengroup.org/testing/testsuites/embedded.html) vključuje naslednje teste:

• IEEE POSIX 1003.1-1990 (testi 5310);
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Razširitev v realnem času (1430 preskusov);
• IEEE Std POSIX 1003.1c-1995 Niti (pthreads) razširitev (1232 preskusov);
• IEEE POSIX 1003.13-1998 Profil 52.

Nekaj ​​o zmedi v terminologiji

V zvezi s skupino standardov POSIX angleški jezik pogosto ne uporablja enega, ampak kar tri izraze. Žal sta si po pomenu podobna in se pogosto prevajata na enak način, kar vnaša nekaj zmede. Ti pogoji so naslednji:

• združljivost (dobesedno "združljivost");
• skladnost (dobesedno - "skladnost");
• skladnost (dobesedno - "doslednost").

Prvi izraz, uporabljen za POSIX, ni uradno opredeljen. Drugi pomeni, da organizacija - proizvajalec programskega izdelka neodvisno izjavlja, da je ta izdelek (v celoti ali delno) v skladu z navedenimi standardi NIST -PCTS. Tretji izraz to pomeni programsko opremo opravila vzpostavljeni preskusni sistem s pomočjo akreditiranega laboratorija ali v okviru odprte skupine in za to obstajajo dokumentirani dokazi (tako imenovana izjava o skladnosti). Nadalje v besedilu članka bodo povsod navedeni originali izrazov, da se odpravi dvoumnost.

Certificiran OS RV

Če se držite strogih pravil, ki zahtevajo, da se podatki o certificiranem RT OS objavijo v uradnem registru in se testiranje izvede na ravni skladnosti, potem trenutno obstajata samo dva certificirana RT OS (podatki so podani v kronološkem vrstnem redu):

LynxOS v.3(izdelek Lynx Real-Time Systems, ki se zdaj imenuje LynuxWorks, Inc., www.lynuxworks.com) je zasnovan za razvoj programske opreme za vgrajene sisteme, ki delujejo v težkem realnem času, proizvajalci originalne opreme in telekomunikacijske opreme, zlasti proizvajalci vgrajenih sistemov za vojaške namene ... Razvoj se lahko izvaja tako na samem ciljnem sistemu (samostojno gostujoč) kot na instrumentalnem računalniku (gostitelju), končna programska oprema je zasnovana za delo na ciljnem sistemu (cilj). LynxOS v.3 je certificirana skladnost POSIX na platformah Intel in PowerPC. Informacije o tem so na voljo na spletnem mestu IEEE na naslovu http://standards.ieee.org/regauth/posix/posix2.html. LynxOS ima certifikat POSIX 1003.1-1996, ki ga je certificiral Mindcraft, laboratorij za testiranje skladnosti POSIX, potrjen s standardom IEEE POSIX, v zbirki testov skladnosti NIST FIPS 151-2. Številka certifikacijskega dokumenta: Referenčna datoteka: IP-2LYX002, Referenčna datoteka: IP-2LYX001.

INTEGRITET v.5(izdelek programske opreme Green Hills, www.ghs.com) je julija 2004 potrjen skladnost s POSIX 1003.1-2003, Sistemski vmesniki za arhitekturo PowerPC (http://get.posixcertified.ieee.org/select_product. tpl). Testni paket VSX-PCTS 2003.

POSIX in operacijski sistem QNX

QNX v.4.20 (razvil ga je QNX Software Systems, www.qnx.com) je skladnost POSIX 1003.1-1988 s certifikatom DataFocus Incorporated za platformo Intel. Testiranje je bilo izvedeno 13. septembra 1993 in izdano 1. novembra 1993. NIST PCTS 151-1 Test Suite, različica 1.1.

QNX Neutrino (različica 6.3) je v skladu z naslednjimi družinskimi standardi 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, ustvarjalec QNX Neutrino, načrtuje tudi skladnost QNX Neutrino z nekaterimi od teh standardov; delo je načrtovano za leto 2005 (www.qnx.com/news/pr_959_1.html).

Literatura

1. Priročnik za uporabo združenja IEEE Standards Association. IEEE, oktober 2004.
2. Kevin M. Obeland. POSIX v programiranju vgrajenih sistemov v realnem času, 2001.
3. Standard IEEE / ANSI 1003.1: Informacijska tehnologija - (POSIX) - 1. del: Sistemska aplikacija: Programski vmesnik (API).
4. Gallmeister, B. O. Programiranje za resnični svet, POSIX.4 Sebastopol, Kalifornija: O'Reilly & Associates, 1995.
5. Nacionalni inštitut za standarde in tehnologijo, PCTS: 151-2, POSIX Test Suite.
6. POSIX: Certificiran s strani IEEE in The Open Group. Potrjena politika. Odprta skupina, 21. oktober 2003, revizija 1.1.

Aleksej Fedorčuk
2005 leto

Ena od značilnosti logične strukture datotečnega sistema operacijskih sistemov družine POSIX je njihova hierarhična ali drevesna organizacija (čeprav je, kot sem rekel, drevo videti nekoliko čudno). Tako kot v vseh vrstah DOS -a ali Windows -a tudi za posamezne medije in njihove particije ni oznake (na primer abecedne ali katere koli druge): vsi so vključeni v enotno strukturo kot podimeniki glavnega imenika. imenovano korenina. Postopek povezovanja datotečni sistemi na neodvisnih fizičnih nosilcih (in njihovih particijah) se do korena drevesnega drevesa imenuje nosilec, podimeniki, ki jih vsebujejo, pa točke pritrditve.

V preteklosti je Unix razvil posebno strukturo imenikov, ki je na splošno zelo podobna družini, vendar se podrobno nekoliko razlikuje. Še zlasti je hierarhija datotek v sistemih BSD skoraj enaka, vendar se razlikuje od tiste v sistemu Linux. In pri slednjem so med različnimi distribucijami ugotovljene pomembne razlike. Vse do dejstva, da je struktura hierarhije datotek ena od značilnosti distribucije.

To stanje otežuje pisanje aplikacij za več platform. Zato obstaja in se aktivno razvija projekt standardizacije hierarhije datotek - FHS (Filesystem Hierarchy Standard).

FHS je bil prvotno namenjen racionalizaciji imeniške strukture številnih distribucij Linuxa. Kasneje so ga prilagodili drugim Unixu podobni sistemi(vključno s klanom BSD). In zdaj so aktivna (vendar ne zelo uspešna) prizadevanja, da bi postala standard za sisteme POSIX, ne le po imenu, ampak tudi v resnici.

Standard FHS temelji na dveh temeljnih načelih - jasnem ločevanju v hierarhiji datotek v imenih, ki so v skupni rabi in v skupni rabi, na eni strani ter nespremenljivi in ​​spremenljivi na drugi.

Kontrast med imeniki v skupni rabi in imeniki v skupni rabi je posledica lastne omrežne narave Unixa. To pomeni, da bi morali biti podatki, povezani z lokalnim računalnikom (na primer konfiguracijske datoteke za njegove naprave), ločeni v imenikih, ki so ločeni od tistih, katerih vsebina je na voljo na drugih računalnikih v omrežju, lokalnih ali globalnih (primer, ki ni samo uporabniški podatke, ampak tudi programe) ...

Bistvo nasprotja med nespremenljivimi in spremenljivimi imeniki je enostavno razložiti s primerom. Torej bi morali biti isti splošni uporabniški programi po svoji naravi nespremenljivi (bolje rečeno, na voljo za spreminjanje le skrbniku sistema, ne pa tudi samemu uporabniku, ki jih uporablja pri svojem delu). Hkrati ti programi med svojim delom ne ustvarjajo samo podatkovnih datotek, recimo besedil ali slik (njihova spremenljiva narava je jasna brez komentarjev), temveč vse vrste informacij o storitvah, kot so dnevniške datoteke, začasne datoteke in podobno) . Ki jih je treba razvrstiti v imenike, ločene od dejanskih izvršljivih programskih datotek, potrebnih za njihovo izvajanje, knjižnic, konfiguracijskih datotek itd.

Kljub temu pa FHS kljub aktivni promociji v številnih distribucijah Linuxa med najpogostejšimi ni pridobil statusa pravega standarda. Obstaja kar nekaj distribucij Linuxa, ki ne uporabljajo nekaterih njegovih določb. In le delno korelira s tradicionalno datotečno hierarhijo sistemov BSD.

Razlog je v tem, da FHS prezre še eno nasprotovanje, ki je za uporabnika zelo pomembno: nasprotovanje zlahka obnovljivih delov datotečnega sistema in tistih njegovih komponent, ki jih je težko obnoviti ali jih sploh ni mogoče obnoviti.

Prvega, nenavadno, lahko pripišemo samemu osnovnemu sistemu: navsezadnje ponovna namestitev z distribucijskega medija v primeru usodne nesreče ni tako težka. Težko obnovljivi deli datotečnega sistema očitno vključujejo uporabniške podatke: tudi če so redno varnostno kopirani (in koliko uporabnikov je tako previdno?), Bo njihova uporaba iz arhivov vzela veliko časa (in skoraj neizogibno) povzročajo nekatere izgube).

Poleg tega bi v sistemih BSD in izvornih distribucijah Linuxa vse, kar je povezano z upravljanjem paketov, uvrstil med težko obnovljive imenike-drevo vrat FreeBSD ali pkgsrc v NetBSD (in sisteme, ki so si ga izposodili), njihove kolege v distribucijah Linuxa, dejanske vire prenesenih programov in izvorno kodo sistema. Kajti tudi če je vse to v distribucijskem kompletu, te komponente datotečnega sistema uporabnik praviloma posodablja s sinhronizacijo prek omrežja s strežniki projekta (sicer je njihova uporaba nesmiselna). Njihova izguba bo povzročila tako začasne (zlasti z modemsko povezavo) kot finančne (le redki ljudje so srečni lastniki brezplačnega dostopa do interneta) izgube.

Strogo spoštovanje koncepta ločevanja skupnih in ne-skupnih, nespremenljivih in nespremenljivih imenikov, ki jih je mogoče obnoviti in jih ni mogoče obnoviti, v okviru ene drevesne hierarhije datotek fizično ločuje njene posamezne veje-torej v obliki neodvisnih datotečnih sistemov na ločenih napravah (diski, odseki diskov, rezine, particije itd.). Razlogov za to je veliko - tako povečanje zmogljivosti kot povečanje zanesljivosti in zgolj pomisleki na udobje - vendar o njih zdaj ne bomo govorili. Ker v ta trenutek za nas je pomembno, da morajo biti te veje datotečnega drevesa vključene v skupni datotečni sistem.

Tipičen nabor sistemskega imenika POSIX

Pravzaprav je za delovanje nujno potreben le en datotečni sistem - tisti, ki je nameščen v korenskem imeniku datotečnega drevesa (nekakšen analog svetovnega drevesa Yggdrassil). Korenski imenik in njegove nepogrešljive veje morajo sestavljati en datotečni sistem, ki se nahaja na enem mediju - disku, particiji diska, matriki RAID programske ali strojne opreme ali logični nosilec v razumevanju LVM. Vsebovati mora vse potrebne komponente za zagon sistema in v idealnem primeru nič več.

S sestavo si lahko ogledate sestavo korenskega imenika

$ ls -1 /

ki bo v katerem koli sistemu POSIX prikazal nekaj minimalnega džentlmenskega nabora imenikov:

Bin / boot / etc / root / sbin /

V njih se zbirajo vse datoteke, brez katerih sistem ne more obstajati. Drugi imeniki so nekaj takega:

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

A) niso potrebni (vsaj v teoriji - brez njih je praktično težko), b) niso vsi prisotni v vseh sistemih in distribucijah, in c) vsak od njih je lahko (in pogosto je - če naredite vse po svojem mnenju) točka pritrditve lastne veje drevesa datotek.

Poleg tega sta v korenu datotečnega sistema operacijskih sistemov, združljivih s POSIX, v večini primerov še dva podimenika:

Dev / proc /

Običajno so to točke pritrditve navideznih datotečnih sistemov - naprav in procesov (čeprav, če se datotečni sistem naprav ne uporablja, mora biti imenik / dev sestavni del korenskega datotečnega sistema. Nazadnje, v sistemih Linux kot praviloma je koren datotečnega drevesa tudi imenik / lib za glavne sistemske knjižnice, pri udevu pa je neizogiben imenik / sys tudi tam, kjer je nameščen navidezni datotečni sistem sysfs.

Korenski datotečni sistem

Korenski datotečni sistem ni v skupni rabi (torej ni namenjen skupni rabi različnih strojev v omrežju) in je nespremenljiv (to pomeni, da ga lahko spreminja le skrbnik sistema, ne pa tudi uporabniški programi in poleg tega ne uporabniki). Poleg tega je zelo odsvetovano ustvarjanje podimenikov v njem, ki presega tiste, ki jih določa standard (in naveden zgoraj).

Polnjenje korenskega datotečnega sistema je izbrano tako, da se lahko stroj zažene in ohrani minimalno funkcionalnost tudi med zagonom v sili (ali v načinu za enega uporabnika), ko vsi drugi datotečni sistemi niso nameščeni (in v skladu s tem njegove veje, kot je npr. / usr ali / var morda ni na voljo.

V skladu s tem zagon stroja zagotavljajo imeniške datoteke / boot in / itd. Prva vsebuje jedro sistema - izvedljivo datoteko "posebnega namena" - in vse, kar je potrebno za njeno nalaganje - v Linuxu, na primer sistemski zemljevid (/etc/System.map), in v jedru za nalaganje FreeBSD modulov. Vendar se včasih jedro nahaja neposredno v korenu datotečnega sistema, nato pa je imenik / boot morda popolnoma odsoten in imenik / modules je lahko rezerviran za module jedra.

Imenik / etc je za sistemske konfiguracijske datoteke, ki določajo pogoje za njegovo nalaganje. Njegova vsebina je zelo odvisna od sistema (in v Linuxu - tudi od distribucijskega kompleta), zato ga tukaj ne bom upošteval - na to temo se bom moral vrniti več kot enkrat.

Najmanjšo potrebno funkcionalnost zagotavlja vsebina imenikov / bin in / sbin - vsebujejo izvedljive datoteke najpomembnejših uporabniških in sistemskih programov, ki vam bodo omogočili izvajanje kompleksa ukrepov za popravilo in reševanje ter po okvari avto pripelji nazaj v človeško podobo.

Razdelitev sistemskih in uporabniških programov na korenske podimenike je precej poljubna. Noben od teh ukazov v resnici ni namenjen reševanju težav uporabnikov. Samo imenik / bin vsebuje skrbniške ukaze, do katerih občasen dostop (ali do njih) lahko dostopa navaden uporabnik, imenik sbin pa je namenjen ukazom, za katere uporabnik ne bi smel vedeti. In ki jih v večini primerov zaradi pomanjkanja ustreznih pooblastil (na primer zahtevanih pravic dostopa do datotek naprav) še vedno ne bo mogel uporabiti.

Za zagon programov POSIX (vključno s tistimi, ki so zbrani v imenikih / bin in sbin) praviloma potrebujete dostop do funkcij sistemskih knjižnic (predvsem glavne knjižnice glibc). Tako je (skoraj) nepogrešljiva komponenta korenskega imenika podimenik / lib, v katerega so zbrani.

V Linuxu imenik / lib služi drugemu pomembnemu namenu - njegov podimenik ( / lib / modules) vsebuje naložljive module jedra (na FreeBSD je njihovo mesto / boot / kernel).

V FreeBSD -ju imenika / lib ni v korenskem datotečnem sistemu - ustrezne komponente se nahajajo tukaj v / usr / lib (glej spodaj). To je zato, ker je FreeBSD v preteklosti zgradil velike sistemske programe, tako da so knjižnične funkcije, ki jih potrebujejo, vdelane v njihove izvedljive datoteke (imenovane statično povezovanje, o katerih bomo razpravljali v 14. poglavju). V FreeBSD -ju so programi pete veje iz imenikov / bin in / sbin povezani dinamično, torej v odsotnosti imenika / usr (in v Free je skoraj vedno ločena veja datotečnega sistema) ne delujejo. Če želite to nadomestiti, obstaja imenik / restore, ki presega standarde in vsebuje iste programe, vendar statično povezane (kot pove ime imena, je edini namen njegove vsebine reševalne operacije).

Končno / root. To je običajen domači imenik istoimenskega uporabnika, torej skrbnika sistema. Ker ne opravlja nobenega praktičnega dela (ali pa ga vsaj ne bi smel opravljati), je njegova vsebina samo lastne konfiguracijske datoteke uporabnika (ukazna lupina uporabnika, priljubljeni urejevalnik itd.).

Podružnica / usr

V preteklosti je bil imenik / usr namenjen uporabniškim programom in podatkom. Te funkcije so zdaj razdeljene med / usr / local in / home (čeprav je slednja zdaj privzeto simbolična povezava do / usr / home v FreeBSD). Imenik / usr - ni spremenljiv, vendar je v skupni rabi - služi kot skladišče za večino aplikacijskih programov in vse, kar je z njimi povezano - izvorno kodo, konfiguracijske datoteke, knjižnice v skupni rabi, dokumentacijo in podobno.

Sestava imenika / usr se med sistemi BSD in Linux močno razlikuje. V prvem vsebuje le sestavne dele operacijskega sistema (tistega, ki ga v FreeBSD združuje koncept distribucij). Aplikacije, nameščene iz vrat ali paketov, imajo svoje mesto v podimeniku / usr / local, ki lahko predstavlja ločeno vejo datotečnega drevesa.

V Linuxu imenik / usr služi kot skladišče za vse programe (in njihove komponente), vključene v distribucijski komplet. Podimenik / usr / local je običajno namenjen programom, ki so neodvisno sestavljeni iz vira.

Vsekakor je običajna sestava imenika / usr naslednja (kot poroča ukaz ls -1):

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

Kot je bilo že omenjeno, je podimenik / usr / local ločena veja datotečnega drevesa, zato ga bomo obravnavali ločeno. Namen drugih imenikov je naslednji:

• / usr / bin in / usr / sbin so namenjeni izvršljivim datotekam uporabniških in sistemskih programov (tu je meja med njimi še bolj poljubna kot v primeru korenskega imenika), katerih namen presega zagotavljanje osnovnega delovanja sistem;
• / usr / etc je za posamezne konfiguracijske datoteke aplikacij;
• / usr / include vsebuje tako imenovane datoteke z glavo, ki so potrebne za povezovanje izvršljive datoteke s knjižničnimi komponentami;
• / usr / lib in / usr / libexec sta imenika za knjižnice v skupni rabi, od katerih so odvisne uporabniške aplikacije;
• / usr / share - skladišče najrazličnejših, tako imenovanih. arhitekturno neodvisne komponente: tukaj si lahko ogledate dokumentacijo v različnih oblikah in primere konfiguracijskih datotek ter podatke, ki jih uporabljajo programi za upravljanje konzol (pisave, postavitve tipkovnice), ter opis časovnih pasov;
• / usr / src - imenik izvorne kode; v Linuxu je tukaj običajno postavljena samo izvorna koda jedra (jedra) sistema, v klonih BSD - celoten nabor izvornih kod kompleksa, ki se v FreeBSD -ju imenuje Distribucije; praviloma je nezaželeno, da se viri samosestavljenih programov postavljajo sem;
• / usr / X11R6 - imenik za komponente okenskega sistema X - izvedljive datoteke ( / usr / X11R6 / bin), knjižnice ( / usr / X11R6 / lib), glave ( / usr / X11R6 / include), dokumentacija ( / usr / X11R6 / moški); Datoteke aplikacij X ne smete postavljati tukaj (razen morda za upravitelje oken) - njihovo mesto je v / usr, / usr / local ali / opt, odvisno od sistema.

Poleg tega lahko imenik / usr vsebuje podimenike / usr / var in / usr / tmp - običajno simbolične povezave do ustreznih vej korenskega imenika. V nekaterih distribucijah Linuxa je glavna sistemska dokumentacija, strani man (v podimeniku / usr / man), postavljena neposredno v / usr.

Nazadnje, v sistemih BSD in nekaterih izvornih distribucijah Linuxa (na primer Gentoo) imenik / usr vsebuje podimenik za sistem za upravljanje paketov - vrata FreeBSD in OpenBSD ( / usr / vrata), njihova enakovredna v drugih sistemih ( / usr / portage v Gentooju). Čeprav z vidika spoštovanja črke in duha standarda FHS (sam ne omenja niti besede o vratih in podobnih sistemih), bi bil zanje bolj logično mesto imenik / var (glej spodaj) - in prav to se počne v distribucijah, kot sta CRUX in Archlinux.

Podružnica / usr / lokalna

Kot smo že omenili, je / usr / local veja v Linuxu namenjena samoprevajanim programom iz virov (ni vključenih v ta distribucijski komplet). Na FreeBSD pa služi kot skladišče za večino uporabniških aplikacij - skoraj vse zunaj Distribucij in nameščeno iz paketov ali vrat. Skladno s tem struktura imenikov kot celota sledi strukturi veje / usr (z razumljivimi izjemami):

Smetnjak / etc / include / lib / man / sbin / share /

Vsebina podimenikov je prav tako podobna: izvedljive datoteke programa ( / usr / local / bin in / usr / local / sbin), njihove konfiguracije ( / usr / local / itd), knjižnice, s katerimi so povezane, in njihove datoteke z glavo ( / usr / local / lib in / usr / local / include), strani strani ( / usr / local / man) in vse vrste arhitekturno neodvisnih stvari ( / usr / local / share), vključno z dokumentacijo v drugih oblikah.

/ Opt veja

Imenik / opt zagotavlja standard FHS, dejansko pa se ne uporablja v vseh distribucijah Linuxa, v sistemih BSD pa je popolnoma odsoten. Kljub temu je vedno več programov napisanih s pričakovanjem privzete namestitve vanj.

V preteklosti je bil imenik / opt v Linuxu uporabljen za komercialne aplikacije in vse vrste neproste programske opreme. Dandanes je njegov namen gostiti velike samostojne programske sisteme, kot so knjižnica Qt, KDE z vsemi komponentami in aplikacijami, OpenOffice.org in podobno. Struktura imenika mora biti / opt / pkg_name. Tako izgleda v mojem sistemu (Archlinux):

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

Vsak od podimenikov ima svojo notranjo strukturo:

$ 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ščiteno po e -pošti] deliti / [zaščiteno po e -pošti] THIRDPARTYLICENSEREADME.html uporabnik / / opt / qt: bin / doc / include / lib / mkspecs / beležke / vtičniki / predloge / prevodi /

Namen podimenikov znotraj / opt / pkg_name je enostavno uganiti po analogiji z / usr in / usr / local. / Opt / kde / bin je na primer za izvedljive datoteke sistema KDE in njegovih aplikacij, / opt / kde / etc je za njegove konfiguracijske datoteke, / opt / kde / include je za datoteke z glavo, / opt / kde / lib je za knjižnice in / opt / kde / share - za datoteke v skupni rabi, vključno z dokumentacijo. V KDE ni dokumentacije v formatu man, če je, potem (tako kot v primeru Gnome - nisem ga namestil, to so potegnili Gimp in podobne aplikacije Gtk) si lahko ogledate / opt / pkg_name / podimenik man.

Vidite lahko, da imeniška struktura / opt odstopa od zgodovinsko uveljavljene (in notranje utemeljene tradicije POSIX združevanja podobnih komponent v imenike - izvedljive datoteke, knjižnice itd.) In z velikim številom nameščenih programov povzroča določene težave : ali morate preobremeniti spremenljivko $ PATH, ki omogoča hiter dostop do ukazov (o tem bo govora v 12. poglavju), ali pa ustvarite poseben imenik / opt / bin in vstavite simbolične povezave do izvršljivih programskih binarnih datotek. Zato so v nekaterih V distribucijah Linuxa (na primer v CRUX -u) se / opt načeloma ne uporablja. Tako kot v vseh sistemih BSD. Možno je, da je tako bolje ...

/ Podružnica Var

Kot pove že ime, je imenik / var namenjen shranjevanju spremenljivih datotek, ki so nastale med običajnim življenjem različnih programov - predpomnilnikov programske opreme (na primer brskalnika), datotek dnevnikov, tiskarskega vmesnika in poštnih sistemov. nabiralnike, opisi tekočih procesov itd. Zlasti v imenik / var so postavljeni tako imenovani dumpi - posnetki stanja RAM -a, ustvarjeni med zaustavitvijo v sili, da bi ugotovili razloge za to. Posebnost vseh teh komponent je njihova spremenljiva narava med delovno sejo in dejstvo, da jih je kljub temu treba ohraniti pri ponovnem zagonu sistema.

Notranja struktura / var se od sistema do sistema zelo razlikuje, zato se ne bom ukvarjal s podrobnostmi o njeni strukturi. Ugotovil bom le, da je ta imenik logično mesto za postavitev komponent vseh vrst vrat podobnih sistemov za upravljanje paketov, kot je to storjeno na primer v distribuciji Archlinux, kjer je podimenik / var / abs (abs - Archlinux Building System ) je rezervirano zanj.

Imenik / mnt

Imenik / mnt je zasnovan za namestitev začasno uporabljenih datotečnih sistemov, običajno na odstranljivi mediji... V vsem uveljavljenem sistemu je običajno prazen in njegova struktura na noben način ni urejena. Uporabnik lahko v njem ustvari podimenike za določene vrste medijev. V mojem sistemu so to na primer / mnt / cd, / mnt / dvd, / mnt / usb in / mnt / hd - za CD -je, DVD -je, bliskovne pogone in odstranljive trde diske.

V FreeBSD -ju so privzeti imeniki za namestitev CD -jev in disketnih diskov / cdrom in / disketa neposredno v korenskem imeniku. Kar se ne ujema povsem s standardom, vendar je na svoj način logično - točke pritrditve naprav, ki obstajajo (na primer CD -ROM) ali do nedavnega obstajale (disketni pogon) v katerem koli računalniku, so sprejete v korenu.

/ Domača podružnica

Imenik / home je namenjen gostovanju domačih imenikov uporabnikov. Njegova vsebina ni kakor koli urejena, običajno pa izgleda kot /home/(username1,...,username#). V velikih sistemih z velikim številom uporabnikov pa je mogoče njihove domače imenike združiti skupaj.

Imenik / home lahko vsebuje domače imenike ne le resničnih uporabnikov, ampak tudi nekaterih virtualnih uporabnikov. Če se stroj uporablja kot spletni ali ftp strežnik, boste videli podimenike, kot sta / home / www ali / home / ftp.

Podružnica / tmp

Ostaja samo govoriti o imeniku za shranjevanje začasnih datotek - / tmp. Tako kot komponente / var jih tudi v običajnem življenju ustvarjajo različni programi. Za razliko od / var, komponent / tmp ni pričakovati shranjevanja zunaj trenutne seje. Poleg tega vsi vodniki za sistemsko administracijo priporočajo redno (na primer pri ponovnem zagonu stroja) ali občasno brisanje tega imenika. Zato je priporočljivo, da kot / tmp datotečne sisteme namestite v RAM - tmpfs (v Linuxu) ali mfs (v FreeBSD). Poleg dejstva, da to zagotavlja brisanje njegove vsebine ob ponovnem zagonu, prispeva tudi k zmogljivosti, na primer pri sestavljanju programov, katerih začasni izdelki niso zapisani na disk, ampak so postavljeni v navidezni imenik, kot je / tmp / obj.

V mnogih sistemih boste videli imenike, kot sta / usr / tmp in / var / tmp. Običajno so to simbolične povezave do / tmp.

Strategija particioniranja datotečnega sistema

Na koncu pogovora o hierarhiji datotek je treba poudariti, da samo imeniki, navedeni v odstavku Korenski datotečni sistem... Vsi drugi imeniki - / usr, / opt, / var, / tmp in seveda / home lahko predstavljajo točke pritrditve neodvisnih datotečnih sistemov na ločenih fizičnih medijih ali njihovih particijah.

Poleg tega v lokalno omrežje ti imeniki se lahko nahajajo tudi na različnih strojih. Na primer, en računalnik, ki deluje kot strežnik aplikacij, lahko vsebuje imenike / usr in / opt v omrežju, drugi datotečni strežnik, ki lahko vsebuje vse domače imenike uporabnikov itd.

Ostaja samo odločiti, katere datotečne sisteme je priporočljivo izolirati iz skupnega datotečnega drevesa in zakaj to storiti. Odgovor na ta vprašanja je zelo odvisen od uporabljenega operacijskega sistema, v primeru Linuxa pa tudi od njegove distribucije. Kljub temu je mogoče orisati splošna načela ločevanja datotečnih sistemov. Zakaj bi se morali spomniti opozicije na eni strani nespremenljivih in spremenljivih imenikov, na drugi strani zlahka obnovljivih, težko obnovljivih in praktično nepopravljivih podatkov. Naredimo ta poskus v zvezi z uporabniškim namizjem - v primeru strežnika bodo izračuni bistveno drugačni.

Očitno bi moral biti korenski datotečni sistem v imenikih / bin, / boot, / etc, / root, / sbin, ki vsebuje enostavno obnovljive iz distribucijskega medija in praktično nespremenjene podatke, nameščen na ločeni particiji diska. V Linuxu je treba dodati tudi imenik / lib. Po drugi strani pa je pri uporabi GRUB kot zagonskega nalagalnika (ne glede na operacijski sistem) priporočljivo premakniti imenik / boot na ločeno particijo.

V starih virih o Linuxu lahko preberete o še enem razlogu za dodelitev particije za imenik / boot in na samem začetku diska: zaradi nezmožnosti nalaganja jedra z Lilom iz številke valja, ki je večja od 1023. V sodobne različice zagonskih nalagalnikov, teh omejitev ni. Če pa ustvarjate particijo za / boot, je smiselno, da je prva na disku, swap particijo pa postavite neposredno za njo: s tem boste pri izvajanju zamenjave hitrosti dodali pet kopejk.

In tudi s področja zgodovine: zahteva, da so korenske in zagonske particije vsekakor primarne, je bila že zdavnaj odpravljena. Ti datotečni sistemi se lahko prilegajo logičnim particijam v razširjeni particiji.

Prav tako je jasno, da je treba spremenljive veje datotečnega sistema - / var in / tmp - premakniti izven korenske particije. Poleg tega je slednje, kot je bilo že večkrat že povedano, na splošno priporočljivo postaviti v datotečni sistem v RAM (tmpfs ali mfs). Če imenik / var vsebuje podimenike za vrata podobne sisteme za upravljanje paketov, kot so / var / abs, / var / cache / pacman / src in / var / cache / pacman / pkg v Archlinuxu, morajo oblikovati tudi svojo datoteko sistemov.

Zdaj imenik / usr, ki vsebuje komponente osnovnega sistema (kot v BSD) ali večino uporabniških aplikacij (kot v večini distribucij Linuxa). Vsebuje podatke, ki jih je mogoče zlahka obnoviti in bi morali biti z dobrim razlogom praktično nespremenljivi, zato si seveda zasluži, da jih izpostavimo na neodvisnem razdelku. Poleg tega je priporočljivo iz njegove sestave na eni strani izolirati podimenike / usr / X11R6 in / usr / local, na drugi strani pa podimenike za sisteme za upravljanje paketov, podobnih pristaniščem: / usr / vrata, / usr / pkgsrc in / usr / pkg v sistemih BSD., / usr / portages v sistemu Gentoo Linux itd. Poleg tega je treba podimenike za umeščanje virov, naloženih iz omrežja pri gradnji vrat, ločiti od slednjih - / usr / port / distfiles, / usr / pkgsrc / disfiles, / usr / portages / distfiles in podobno.

V sistemih BSD je poleg tega smiselno iz imenika / usr ločiti podimenike / usr / src in / usr / obj, ki vsebujejo vire osnovnih komponent (vključno z jedrom) in njihove vmesne izdelke pri sestavljanju, ki so ustvarjajo postopki make buildworld in make buildkernel. ...

Nazadnje je treba imenik / home, ki vsebuje nestanovitne in pogosto nepopravljive podatke, odstraniti iz korena hierarhije datotek. Vedno ga poskušam postaviti na ločeno rezino (v BSD) ali na primarno particijo (v Linuxu).

Predlagana shema razdelitve datotečnega sistema se lahko zdi preveč zapletena. Zagotavlja pa izolacijo zlahka obnovljivih, težko obnovljivih in neobnovljivih podatkov, kar olajša ponovno namestitev sistema v nujnih primerih in celo selitev iz sistema v sistem.

Njegov dodaten plus je, da lahko za posamezne veje datotečnega drevesa glede na naravo podatkov, ki se na njem nahajajo, v Linuxu izberete fizično optimalen datotečni sistem. Na primer, za particijo pod / boot nima smisla uporabljati nič drugega kot Ext2fs. Na splošno je priporočljivo, da korensko particijo formatirate z varnim in hkrati najbolj združljivim Ext3fs. Za imenike z velikim številom majhnih datotek, kot so / var / abs v Archlinuxu, / usr / portages v Gentooju, je priporočljivo uporabiti ReiserFS: navsezadnje je spretno ravnanje z majhnimi datotekami njegov profil. In v imeniku / home, kjer se lahko pojavijo ogromne večpredstavnostne datoteke (in ki so običajno same po sebi zelo velike), lahko na sodišče pride XFS (čeprav je, kot kažejo meritve, ReiserFS tukaj videti precej spodobno). Takšni ukrepi lahko izboljšajo tako zanesljivost shranjevanja podatkov kot hitrost delovanja datotek.

Uporabniki operacijskih sistemov BSD so brez možnosti vezani na datotečne sisteme tipa FFS. Imajo pa tudi manevrski prostor. Prvič, s spreminjanjem velikosti bloka in fragmenta posameznih datotečnih sistemov, kar prispeva bodisi k izvajanju operacij na disku bodisi k prihranku prostora na disku. In drugič, nekatere veje datotečnega drevesa (na primer / tmp ali / usr / obj, v nasprotju s priporočili, je mogoče neustrašno namestiti v povsem asinhronem načinu in s tem pridobiti odstotek ali drugo zmogljivost.

O standardih na splošno

Med programerji obstaja mnenje, da standardi pri programiranju sploh niso potrebni, ker:

(1) sprva so brez pomena, saj njihovi avtorji ne pišejo računalniških programov;

(2) ovirajo pobudo programerjev;

(3) programerji se bodo vedno strinjali brez standardov.

Morda na to mnenje ne bi smeli biti pozorni, če ne v dveh okoliščinah:

(1) izražajo ga praktiki, torej ravno tisti, ki "izdajajo programsko opremo";

(2) Zgornje sklepanje je avtor tega članka odkril v eni od publikacij na internetu, namenjenih standardu za programski jezik C, iz katere je postalo jasno, da je takšno mnenje razširjeno "v mednarodnem merilu" in ne le med arogantnimi ruskimi "super programerji".

Beseda "standard" je običajno povezana z nečim materialnim (standardne dimenzije, standardna električna napetost itd.), Medtem ko je računalniški program neoprijemljiv predmet ("nova nematerialna") in so morda standardi v neopredmeteni sferi res nesmiselni?

Obstaja pa zanikajoč primer. Niz črkovalnih pravil ruskega jezika je v bistvu standard, čeprav ga organi za standardizacijo ne odobrijo. Poleg pravil (ali, če želite, zahtev) črkovanja obstajajo še skladenjska pravila in, kar je najpomembneje, semantika. Slednje dobro ponazarja »otročje« vprašanje: zakaj se mačka imenuje mačka? Na to vprašanje obstaja natančen odgovor: ker so se naši predniki tako strinjali; predniki Britancev so se strinjali, da bodo isto zveri imenovali mačka, predniki Nemcev - mucka itd. Na splošno je pomen ali semantika ali pravila razlage katere koli besede ali kombinacije besed stvar dogovora.

Namen in "super naloga" standarda POSIX

Kot že ime pove, je POSIX (prenosni vmesnik operacijskega sistema) standard za vmesnik (vmesnik) med operacijskim sistemom in aplikacijskim programom. Dnevi, ko so programerji pisali programe za "goli" stroj (izvajali lastne pakete vhodnih / izhodnih programov, trigonometrične funkcije itd.), So minili za vedno. Besedilo POSIX večkrat poudarja, da standard ne nalaga nobenih zahtev glede izvedbenih podrobnosti operacijskega sistema; lahko ga obravnavamo kot sklop sporazumov med programerji aplikacij in razvijalci operacijskih sistemov. Tako (spet v nasprotju s precej razširjenim mnenjem) POSIX ne zanima le razvijalcev operacijskih sistemov, ampak predvsem veliko večjo kategorijo programerjev.

Potreba po tovrstnem standardu je bila prepoznana že v osemdesetih letih prejšnjega stoletja, ko so postali razširjeni operacijski sistemi UNIX. Izkazalo se je, da čeprav je bil ta sistem zasnovan kot enoten sistem, so razlike med njegovimi posebnimi izvedbami privedle do dejstva, da aplikacijskih programov, napisanih za en sistem, ni bilo mogoče vedno izvajati v drugem. Prav ta problem, znan kot problem prenosljivosti programske opreme, namerava rešiti POSIX. Prva izdaja standarda je izšla leta 1988 (obstaja prevod, glej), v katerem je bila vsa raznolikost vprašanj, povezanih s prenosljivostjo programa, razdeljena na dva dela: (1) vmesnik aplikacijskega programa, (2) tolmač ukazov in pripomočki (uporabniški vmesnik); ti deli se imenujejo POSIX.1 oziroma POSIX.2.

Naj pojasnimo, da bomo v tem članku govorili le o standardu za vmesnik aplikacijskega programa, POSIX.1, katerega druga (in zadnja do danes) izdaja je bila odobrena 12. julija 1996.

V informativnem delu standarda je tudi poudarjeno, da POSIX ni opis vmesnika nekega "idealnega" operacijskega sistema, ampak je rezultat posploševanja in sistematizacije izkušenj, pridobljenih pri razvoju operacijskih sistemov UNIX. Prav tako POSIX ne more služiti kot vodilo oz študijski vodnik o operacijskih sistemih, čeprav informativni del vsebuje priporočila za programerje in fragmente programov.

Standard neposredno določa, da ni mogoče ustvariti polnopravnega operacijskega sistema, ki bi se osredotočil izključno na funkcije vmesnika, opisane v njem. (Zlasti POSIX.1 ne obravnava vprašanj, kot so omrežje in s tem povezane vmesniške funkcije ali grafični vmesnik.) Vendar so finančni stroški, povezani z nepremičnostjo programov in posledična potreba po poenotenju vmesnikov, tako veliki, da jih večina prodajalcev raje vsaj nekaj standarda, kot da ga nimam. Zaradi tega se mnogi razvijalci programske opreme osredotočajo na POSIX. To omogoča, če ne popolnoma odpraviti nepremičnost programov, potem pa vsaj znatno zmanjšati nepremični del programa.

O semantiki

Kot smo že omenili, je POSIX mogoče razumeti kot sklop sporazumov med razvijalcem operacijskega sistema in programerjem aplikacij. "Sporazum" pomeni najprej isto razlago (semantiko) besed in izrazov. Spodaj so primeri, ki ponazarjajo težave pri doseganju "sporazuma".

Kako prevesti pomen v prevodu

Najprej je treba spomniti, da je standard POSIX napisan v angleščini, kar po svoji naravi povzroča dvoumnost (na primer ista beseda je lahko samostalnik, pridevnik in glagol), »pomenske pasti« pa čakajo na skoraj vsako stran. Dobra ponazoritev tega je primer iz fikcije. Eno najbolj znanih del Oscarja Wildeja, ki je to funkcijo briljantno uporabil angleškega jezika, - Pomen resnosti - v ruskem jeziku znan kot "Pomen resnosti". ampak Angleško ime ima drugi pomen: Earnest (resen) je ime enega od likov, ime pa bi lahko prevedli drugače: "Kako pomembno je biti Ernst." Obstaja ruski priimek Serebryany in če bi obstajal priimek Serious, bi bil prevod popolnoma natančen s prenosom obeh pomenov.

Podobno je pri samem imenu standarda: vmesnik prenosnega operacijskega sistema. Pridevnik Prenosni (mobilni) se nanaša tako na operacijski sistem kot na aplikacijski program, vendar ga v ruskem jeziku ni mogoče izraziti tako kratko, lahko ga prevedemo kot »vmesnik mobilnega operacijskega sistema« ali »vmesnik operacijskega sistema, ki zagotavlja mobilnost aplikacijskih programov «. Druga možnost bolje odraža namere razvijalcev standarda, hkrati pa se izgubi prvi pomen (med prevodom se je ohranila bolj znana prva možnost).

Semantika besede "standard"

Pred glavnim besedilom standarda je preambula, ki pojasnjuje pomen besed IEEE Standards2. Iz teh razlag izhaja, da obstajajo vsaj tri pomenske razlike od izraza GOST v ruskem jeziku:

(1) Intuitivno velja, da ima GOST veljavo zakona, katerega kršitev se preganja; POSIX je niz zahtev, katerih spoštovanje je povsem prostovoljno.

(2) GOST velja do preklica (mnogi so verjetno slišali izraz »GOST ni bil preklican«); preambula POSIX pravi, da če standard ni bil revidiran 5 let, to pomeni, da bodo vprašanja, obravnavana v njem, verjetno izgubila pomen, zato ga je mogoče samodejno razveljaviti;

(3) GOST je anonimen; uvodni del POSIX vsebuje seznam tistih, ki so sodelovali pri razvoju tega standarda, prav tako pa naslov, na katerega je mogoče poslati zahteve za razlago; navaja tudi, da je za odgovor na vsako zahtevo potreben postopek odobritve (z drugimi besedami, avtorji standarda se med seboj dogovorijo, preden dajo odgovor).

Tako prevod celo tako znane besede, kot je Standard, z besedo »standard« zahteva komentarje.

Semantika besed "naj", "ni določeno", "ni opredeljeno", "opredeljeno z izvedbo"

Oddelek 2 standarda se imenuje terminologija in splošne zahteve. Vsebuje opredelitve ne le posebnih izrazov (na primer »proces« ali »semafor«), ampak tudi takšne na videz samoumevne besede, kot sta »naj« ali »lahko«. Ker je POSIX.1 standard vmesnika, njegove zahteve veljajo tako za operacijski sistem kot za aplikacijski program. Izrecna zahteva je izražena z besedo "will", na primer: "Če je uspešna, mora funkcija link () vrniti ničlo." V tem primeru govorimo o zahtevi za operacijski sistem: funkcijo link () je treba implementirati, tako da ob uspehu vrne nič.

Izraza "ni določeno" in "ni opredeljeno" izražata isto idejo, da standard dopušča svobodo izbire, vendar je pomen teh izrazov drugačen. Izraz "ni določeno" pomeni, da govorimo o nekaterih pravilnih (dejanja, konstrukcije programov itd.), Izraz "nedoločeno" - o napačnih (napačnih). Informativni del standarda vsebuje naslednjo razlago.

Izraz "nedoločeno" pomeni, da se domneva, da so znane različne možnosti (izidi, rezultati klica funkcije itd.), Standard pa dopušča katero koli od njih; pri določeni izvedbi operacijskega sistema je mogoče izbrati katerega koli, za tak sistem pa velja, da je v skladu s standardom. Aplikacijski program (strogo v skladu s standardom) mora biti napisan tako, da pravilno deluje v kateri koli različici; kot tak izraz implicitno izraža zahtevo po aplikacijskem programu.

Navedimo primer: »Funkcija readdir () bi morala vrniti kazalec na strukturo, ki se nanaša na naslednji element imenika. Ali standard kataloga vrne postavke kataloga z imenom "point" in "point-to-point", ne določa. " V tem primeru so možni štirje rezultati in zahteva za prijavo je, da mora biti zasnovana za katerega koli od njih.

Še en primer: »Če se funkcija sigwait (), ki naroči, da čaka na signal z določeno številko, pokliče v več krmilnih niti, potem, ko signal prispe v največ eno od njih, se mora vrniti sigwait (). V kakšnem nadzornem toku se bo to zgodilo, standard ne določa. " V tem primeru je lahko veliko več možnih izidov, vendar so vsi znani in zahteva za prijavo je, da mora za vsak izid delovati pravilno.

Izraz "ni opredeljen" pomeni, da celo številni rezultati niso znani, možen je vsak izid, celo katastrofalen (na primer zrušitev sistema, izguba podatkov itd.). V bistvu ta izraz implicitno izraža zahtevo, da aplikacija ne uporablja ustreznih podatkov ali konstruktov. Na primer: "Če se argument dirp v readdir () ne nanaša na trenutno odprt imenik, je rezultat nedefiniran."

Ta primer zahteva, da aplikacija za argument funkcije readdir () nadomesti samo referenco odprtega imenika; kršitev te zahteve lahko povzroči katastrofalne posledice, odgovornost za to pa nosi programer aplikacije.

Tu je še en primer: »Če je uspešna, mora funkcija read () vrniti celo število, ki predstavlja število dejansko prebranih bajtov. V nasprotnem primeru mora funkcija dodeliti kodo napake errno in vrniti -1, vsebina vmesnega pomnilnika, na katero kaže buf, pa ni določena. "

Standard prepoveduje uporabo podatkov iz medpomnilnika v aplikacijskem programu v primeru napake v funkciji read (), posledice kršitve te zahteve pa so dodeljene programerju aplikacij.

Pomen izraza "izvedbeno opredeljen" se razlikuje od intuitivnega. Očitno je, da v določenem operacijskem sistemu ne more biti "nedoločenega" ali "nedefiniranega" rezultata, nekaj posebnega rezultata bo nedvomno pridobljeno. Izraz "opredeljeno z izvedbo" izraža zahtevo standarda po dokumentaciji operacijskega sistema: rezultat ne sme biti le podan (razvijalci operacijskega sistema bodo to morali storiti), ampak tudi izrecno odražati v sistemski dokumentaciji.

Privzeta semantika

Noben regulativni dokument ne more zajeti vse vrste primerov, ki se lahko pojavijo v praksi, zato o nečem neizogibno molči3. Na primer, opis funkcije lahko pove, da lahko njen argument sprejme vrednosti iz določenega območja, vendar ni nič povedano o tem, kakšen bo rezultat, če argument ne spada v to območje. Očitno je za izogibanje nesporazumom potrebna enotna privzeta semantika. V informativnem delu standarda je zanimiv stavek: "splošno sprejeta semantika privzete vrednosti je prepovedana." Ta izjava je v nasprotju z znanim sloganom izpred desetih let "dovoljeno je vse, kar ni izrecno prepovedano". Očitno je v mislih državljanov tako zakoreninjeno, da se mnogi, tudi programerji, ne strinjajo s citirano izjavo standarda. Medtem, če uporaba katerega koli konstrukta ni izrecno dovoljena in ne izhaja iz opisa, se vsak programer, ki se ukvarja s prakso, zaveda, da je uporaba tvegana, in če ne deluje, mu ne pride na misel, da bi zahteval.

Procesi in tokovi nadzora

Oba izraza izražata idejo o vzporedni izvedbi. Operacijski sistem UNIX je bil prvotno zasnovan kot več uporabnik, programi, ki jih zaženejo različni uporabniki, pa morajo biti med seboj varno izolirani, da ne bi pomotoma izkrivili "tujih" podatkov. To izolacijo zagotavlja dejstvo, da se uporabniški program izvaja v procesu, ki se razvija v svojem navideznem naslovnem prostoru. Tudi če program vsebuje globalne podatke, bodo ob zagonu v različnih procesih samodejno "ločeni" v različne naslovne prostore.

Vendar procesni mehanizem ni povsem zadovoljiv pri načrtovanju nalog v realnem času. Aplikacijo v realnem času (ki deluje v imenu istega uporabnika) je pogosto mogoče naravno predstaviti kot sočasno izvajanje delov, imenovanih "niti". Njihova najpomembnejša razlika od procesov je, da se vsi nadzorni tokovi razvijajo v enem samem naslovnem prostoru; to omogoča hiter dostop do globalnih podatkov, hkrati pa obstaja nevarnost nenamernega izkrivljanja, in da se to prepreči, je treba upoštevati nekaj programske discipline. Ustrezna priporočila so v informativnem delu standarda.

Poudariti je treba, da se zamisel o večnitnosti izvaja v številnih operacijskih sistemih v realnem času in izvaja na različne načine v smislu, da ima vsaka krmilna nit drugačen nabor atributov in vmesniških funkcij; včasih se namesto niti uporablja izraz opravilo. Da bi se izognili zmedi, standard poudarja, da obravnava izključno niti POSIX, imena ustreznih vmesniških funkcij pa imajo predpono pthread_ (na primer pthread_create (), pthread_join () itd.).

Skladnost s standardom. Semantika besede "ujemanje"

Intuitivno velja, da če sta dva predmeta izdelana v skladu z istim standardom, potem zagotovljeno, da se "parita" med seboj in bosta delovala skupaj v parih; prav to je namen uvedbe standarda vmesnika (vmesnika). Ker je POSIX vmesniški standard, lahko govorimo o skladnosti s standardom tako operacijskega sistema kot aplikacijskega programa.

Standard POSIX.1 vsebuje več sto (če ne tisoče) zahtev; šteje se za samoumevnega, da če vsaj eden od njiju ni izpolnjen, potem sistem (ali aplikacijski program) ni v skladu s standardom. Hkrati je bilo do danes napisanih toliko operacijskih sistemov in aplikacij razreda UNIX, da je komaj smiselno zahtevati popolno skladnost v navedenem smislu. Težave pri razvoju tovrstnih mednarodnih standardov se povečujejo zaradi obstoja različnih nacionalnih jezikov. Tudi če pozabimo na aplikacijske programe, namenjene obdelavi besedil v nacionalnih jezikih, mora skoraj vsak aplikacijski program izdati nekakšna diagnostična sporočila in / ali zaznati besedila, ki jih vnese operater.

• stroga skladnost s standardom POSIX.1;
• skladnost z mednarodno različico POSIX.1;
• skladnost z nacionalno različico POSIX.1;
• Skladnost POSIX.1 z razširitvami.

Drugič, številne vmesniške možnosti so neobvezne; Standard zahteva, da se neobvezne vmesniške funkcije obnašajo, kot jih predpisuje standard, ali vedno vrnejo posebno kodo napake, ENOSYS (kar pomeni, da funkcija ni izvedena). Možnosti so razdeljene v več skupin, od katerih vsaka ustreza določeni konfiguracijski konstanti, ki je deklarirana (z stavkom #define) v ustrezni datoteki z glavo; to omogoča, da ugotovimo, ali je bila funkcija izvedena v fazi zbiranja.

Opisane metode doseganja mobilnosti avtorji POSIX -a niso izumili, ampak se je že dolgo uporabljala v praksi; v mnogih operacijskih sistemih se konfiguracijske konstante uporabljajo za identifikacijo samega sistema ali njegove različice. In tukaj standard ne ponuja ničesar bistveno novega, ampak le sistematizira obstoječo prakso.

Predmeti standardizacije in struktura standarda

Skratka, standardizacijski objekti POSIX.1 so imena in semantika. Natančneje, govorimo o naslednjem.

• Imena vmesniških funkcij. 357 funkcij je standardiziranih, 107 funkcij je vzetih iz standardnih knjižnic C (matematična, obdelava nizov, vhod / izhod itd.); te funkcije veljajo za del standarda POSIX.1, vendar so Celoten opis ki jih vsebuje standard za programski jezik C.
• Imena sistemskih podatkovnih tipov. Ta imena imajo pripone s _t.
• Imena naslovnih datotek in najmanjša sestava teh datotek.
• Sistemska imena globalnih spremenljivk (na primer errno).
• Simbolična imena kod napak, ki jih je mogoče nastaviti med izvajanjem funkcije. Ta imena se začnejo s črko E (EPERM, ENOTEMPTY itd.).
• Imena konstantnih konfiguracij. Ta imena imajo predpono _POSIX_.
• Simbolična imena številk signalov; ta imena imajo predpono SIG. Poleg 20 "tradicionalnih" signalov (SIGABRT, SIGALRM itd.) So standardizirani signali v realnem času, katerih število mora zavzeti določeno neprekinjeno območje od SIGRTMIN do vključno SIGRTMAX, ki vsebuje najmanj številke RTSIG_MAX.
• Simbolična imena, ki ustrezajo vrednostim posameznih argumentov nekaterih funkcij (na primer argument cmd funkcije fcntl () lahko sprejmejo vrednosti F_DUPFD, F_GETFD, F_GETLK itd.).
• Imena makrov, konstant, bitnih zastavic, spremenljivk okolja.

Na splošno je standard sestavljen iz dveh velikih delov približno enake prostornine. Prva polovica - normativni del - vsebuje zahteve in priporočila standarda (18 razdelkov), druga - informativni del - vsebuje dodatke, ki vsebujejo seznam referenc, komentarje in pojasnila k normativnemu delu, sestavo glave datoteke, primer profila ("projekcija") standarda (za Dansko), značilnosti in metodologijo za merjenje uspešnosti najpomembnejših funkcij, pa tudi opis dodatnih vmesniških funkcij za delo z datotekami v realnem času; pričakuje se, da bodo v prihodnjih izdajah standarda te funkcije vključene v normativni del.

Stranska vrstica »Povzetki določb standarda« daje predstavo o tem, katere vrste storitev operacijskega sistema zajema standard.

Zaključek

Glavna vsebina standarda POSIX je semantika vmesniških funkcij. Standardizacija semantike sama po sebi ni enostaven posel (vsi vedo, kako težko se je sporazumeti tudi za dve osebi), težave pa povečuje dejstvo, da je v programiranje trenutno vključenih veliko ljudi. Na primer, paradigma sočasnosti je izražena z izrazi, kot so "proces", "naloga" in "tok nadzora", vendar s praktičnega programskega vidika "naloga" v operacijskem sistemu IBM OS / 360 in dejanski -časovni operacijski sistem VxWorks ni enak. in tudi. Drug primer so semaforji. Semaforji so binarni, celoštevilski ("s števcem") in medsebojna izključitev (ki jo mimogrede programerji med seboj imenujejo "muteksi", ki se spontano poskušajo izogniti nesporazumom). Celoštevilčni semaforji, na primer v operacijskem sistemu VxWorks, sploh niso enaki semaforjem POSIX.

Avtorji standarda POSIX, ki se dobro zavedajo, kako težko je ljudi opustiti svoje navade (ki jim pravijo "ustaljena praksa"), izjavljajo, da so sestavili skladen in minimalen sistem vmesniških funkcij, ki pokrivajo večino storitev tradicionalno ki jih ponuja operacijski sistem, podrobno opisuje natančno semantiko teh funkcij in vabi vse, naj jih uporabijo pri svojem razvoju4.

Ob branju standarda se včasih pojavi vtis, da so nekateri izrazi imeli en sam namen: ne odstraniti nekaterih aplikacijskih programov ali operacijskih sistemov iz kategorije, ki izpolnjuje standard. Takšen cilj je bil res postavljen in izrecno formuliran v uvodu: standard mora čim bolj upoštevati prevladujočo prakso. Vendar je glavni cilj še vedno zagotoviti mobilnost aplikativnih programov.

O avtorju

Sergej Romanjuk - višji raziskovalec na Raziskovalnem inštitutu za sistemske raziskave, vodja prevajalne skupine standardnih POSIX. Z njim se lahko obrnete po e -pošti na: [zaščiteno po e -pošti]

1 Dodati je treba, da delo na standardu poteka že vrsto let; so odkrita nova vprašanja in so bodisi vključena v enega od obstoječih delov ali pa so formalizirana kot ločen del, ki ga je mogoče pozneje preklicati. To se je na primer zgodilo z napravami v realnem času, ki so bile najprej deklarirane kot POSIX.4, kasneje pa vključene v POSIX.1.

2 IEEE je organizacija, ki je razvila standard POSIX.

3 Tukaj "privzeto" pomeni tiho in ne privzeto; ne govorimo o nobenih implicitnih vrednostih, ki so dejansko deklarirane, ampak o odsotnosti sklicevanja sploh.

4 Ruski prevod standarda bo objavljen v začetku leta 2000.

Literatura

Mednarodni standard ISO / IEC 9945-1 (ANSI / IEEE Std 1003.1) Druga izdaja. 1996-07-12. Informacijska tehnologija - Vmesnik za prenosni operacijski sistem (POSIX) - 1. del: Vmesnik sistemskega aplikacijskega programa (API).

M. I. Belyakov, Yu.I. Rabover, A. L. Fridman. Mobilni operacijski sistem. Imenik. Moskva, "Radio in komunikacije", 1991.

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

Oddelek 1	- Uvod
Oddelek 2	- Terminologija in definicije
Oddelek 3	- Funkcije za upravljanje procesov (ustvarjanje, zamenjava slike, dokončanje) in signalov (upravljanje mask, odzivanje na signale)
Oddelek 4	- Identifikacija (procesi, uporabniki, sistem, terminal), anketiranje časa, porabljenega za izvedbo procesa, anketiranje spremenljivk okolja.
Oddelek 5	- Upravljanje datotek in imenikov
Oddelek 6	- Vhodne in izhodne funkcije
Oddelek 7	- Krmilne funkcije terminala
Oddelek 8	- Funkcije, izposojene iz jezikovnega standarda C
Oddelek 9	- Dostop do baz podatkov uporabnikov in skupin uporabnikov
Oddelek 10	- Oblike podatkov za arhiviranje in izmenjavo (tar in cpio)
Oddelek 11	- Sinhronizacijske zmogljivosti: semaforji, muteksi in spremenljivke stanja
Oddelek 12	- Funkcije upravljanja pomnilnika: pripenjanje in odpenjanje naslovnega prostora procesa, preslikava datotek v pomnilnik, zaščita pomnilnika, skupni pomnilnik
Oddelek 13	- Funkcije, povezane s procesi načrtovanja in nadzornimi tokovi
Oddelek 14	- Upravljanje ure in časovnika
Oddelek 15	- Upravljanje čakalnih vrst sporočil
Oddelek 16	- Osnovne funkcije, povezane s krmilnimi tokovi
Oddelek 17	- Podatki, specifični za nit
Oddelek 18	- Sredstva za uničenje krmilnih tokov

Zadeva: Operacijski sistemi.
Vprašanje: Ne

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

Načela izdelave OS:

1.) Načelo modularnosti- modul se na splošno razume kot funkcionalno dokončan element sistema, izdelan v skladu s sprejetimi intermodularnimi vmesniki. Po svoji definiciji modul prevzema možnost, da ga enostavno zamenja z drugim, pod pogojem, da so na voljo navedeni vmesniki. Delitev sistema na module v veliki meri določa uporabljena metoda oblikovanja OS (od spodaj navzgor ali obratno).

Privilegirani moduli, moduli za ponovni vstop in ponovni vstop so še posebej pomembni pri izgradnji operacijskega sistema (ponovna pridobitev pravic je dobesedna ponovna pridobitev pravic; poseben izraz za označevanje zdravja programa; lastnost programa, da se pravilno izvede, ko pride do rekurzivnega (vrnjenega) klica zaradi prekinitve).

Največji učinek uporabe tega načela je mogoče doseči v primeru hkratne razširitve tega načela na OS, aplikacijske programe in strojno opremo.

2.) Načelo funkcionalne selektivnosti- določen del pomembnih modulov je dodeljen v OS, ki ga je treba za učinkovitejšo organizacijo računalniškega procesa nenehno locirati v RAM -u. Ta del se v operacijskem sistemu imenuje jedro, saj je osnova sistema. Pri oblikovanju sestave jedra je treba upoštevati dve nasprotujoči si zahtevi. Po eni strani bi morali biti v jedro vključeni najpogosteje uporabljeni sistemski moduli, po drugi strani pa mora biti število modulov takšno, da količina pomnilnika, ki ga jedro zaseda, ni prevelika. Poleg programskih modulov, ki so del jedra in so trajno nameščeni v RAM -u, lahko obstaja še veliko drugih modulov sistemske programske opreme, ki se imenujejo tranzit. Tranzit programski moduli naloži v RAM samo, kadar je to potrebno in v odsotnosti prostega prostora jih je mogoče zamenjati z drugimi tranzitnimi moduli.

3.) Načelo generiranja OS: Bistvo načela je v organizaciji (izbiri) takšne metode za začetno predstavitev programa za nadzor centralnega sistema OS (jedro in glavne komponente, ki so stalno v RAM -u), kar je omogočilo prilagoditev tega nadzornega dela sistema na podlagi posebne konfiguracije določenega računalniškega kompleksa in vrste nalog, ki jih je treba rešiti. Ta postopek se redko izvaja pred dovolj dolgim ​​obdobjem delovanja OS. Proces generiranja se izvede s posebnim programom generatorja in ustreznim jezikom vnosa za ta program, ki omogoča opis programskih zmogljivosti sistema in konfiguracijo stroja. Rezultat generacije je polna izvedba OS. Ustvarjena različica OS je zbirka sistemskih naborov modulov in podatkov.

4.) Načelo funkcionalne redundance: To načelo upošteva možnost izvajanja istega dela na različne načine. OS lahko vključuje več vrst monitorjev (nadzorni moduli, ki nadzorujejo eno ali drugo vrsto vira), različne načine organiziranja komunikacije med računalniškimi procesi. Prisotnost več vrst monitorjev, več sistemov za upravljanje datotek omogoča uporabnikom, da hitro in najustrezneje prilagodijo OS določeni konfiguraciji računalniškega sistema, da zagotovijo najučinkovitejše nalaganje strojne opreme pri reševanju določenega razreda težav, da dosežejo največ uspešnosti pri reševanju danega razreda težav.

5.) Načelo virtualizacije: konstrukcija virtualnih virov, njihova distribucija in uporaba se trenutno uporablja v skoraj vseh OS. To načelo vam omogoča, da predstavite strukturo sistema v obliki posebnega niza načrtovalcev procesov in razdeljevalcev sredstev (monitorjev) ter uporabite eno samo centralizirano shemo dodeljevanja virov.

Najbolj naravna in popolna manifestacija koncepta virtualnosti je koncept navidezni stroj ... Navidezni stroj, ki je na voljo uporabniku, reproducira arhitekturo pravega stroja, vendar arhitekturni elementi v tej predstavitvi izhajajo z novimi ali izboljšanimi lastnostmi, ki praviloma poenostavljajo delo s sistemom. Značilnosti so lahko poljubne, vendar najpogosteje uporabniki želijo imeti svoj "idealen" stroj glede na arhitekturne značilnosti, v naslednji sestavi:

- virtualni pomnilnik praktično neomejene prostornine, enoten glede na logiko delovanja.

- poljubno število virtualnih procesorjev, ki lahko delujejo vzporedno in med delom delujejo.

- poljubno število zunanjih navideznih naprav, ki lahko delujejo s pomnilnikom navideznega stroja vzporedno ali zaporedno, asinhrono ali sinhrono glede na delovanje enega ali drugega navideznega procesorja, ki sproži delovanje teh naprav.

Eden od vidikov virtualizacije je organizacija možnosti izvajanja v danem OS aplikacij, ki so bile razvite za druge OS. Z drugimi besedami, govorimo o organizaciji več operacijskih okolij.

6.) Načelo neodvisnosti programov od zunanjih naprav: to načelo se zdaj uporablja v veliki večini splošnih operacijskih sistemov. Prvič je bilo to načelo najbolj dosledno implementirano v operacijskem sistemu UNIX. Uporablja se tudi v večini sodobnih operacijskih sistemov za osebne računalnike. To načelo leži v dejstvu, da se povezava programov s posebnimi napravami ne izvaja na ravni oddajanja programa, ampak v obdobju načrtovanja njegove izvedbe. Posledično ponovna kompilacija ni potrebna, ko se program izvaja z novo napravo, na kateri so podatki.

7.) Načelo združljivosti: eden od vidikov združljivosti je zmožnost operacijskega sistema, da izvaja programe, napisane za druge OS ali za starejše različice tega operacijskega sistema, pa tudi za drugo strojno platformo. Vprašanja je treba ločiti binarna združljivost in združljivost vira aplikacije.

Binarna združljivost je dosežena, ko lahko vzamete izvršljiv program in ga zaženete v drugem operacijskem sistemu. To zahteva združljivost na ravni procesorskih navodil in združljivost na ravni sistemskih klicev in celo na ravni knjižničnih klicev, če so dinamično povezani.

Za združljivost vira je potreben ustrezen prevajalec v sistemski programski opremi ter knjižnica in sistemski klici. V tem primeru je treba obstoječa izvorna besedila ponovno prevesti v nov izvedljiv modul.

Binarno združljivost med procesorji, ki temeljijo na različnih arhitekturah, je veliko težje doseči. Če želite, da en računalnik izvaja programe drugega (na primer program za osebni računalnik, kot je IBM -ov računalnik, je zaželeno, da se izvaja v računalniku, kot je Apple Macintosh), mora ta računalnik delovati s strojnimi navodili, ki jih sprva ne izvaja razumeti. V tem primeru se mora izvesti procesor 680x0 (ali PowerPC) binarna koda zasnovan za procesor i80x86. Procesor 80x86 ima lasten dekodirnik navodil, registre in notranjo arhitekturo. Procesor 680x0 ne razume binarnega zapisa 80x86, zato mora izbrati vsak ukaz, ga dekodirati, da ugotovi, ali

kaj namerava storiti, nato pa izvedite enakovredno podprogram, napisan za 680 × 0.

Eno od sredstev za zagotavljanje združljivosti programske opreme in uporabniških vmesnikov je skladnost s standardi POSIX, katerih uporaba omogoča ustvarjanje programov v slogu UNIX, ki jih je kasneje mogoče enostavno prenašati iz enega sistema v drugega.

8.) Načelo odprtosti in razširljivosti: Odprti operacijski sistem je na voljo za analizo tako uporabnikom kot sistemskim strokovnjakom, ki vzdržujejo računalniški sistem. Razširljiv (spremenljiv, razvit) OS omogoča ne le uporabo generacijskih zmogljivosti, temveč tudi uvajanje novih modulov v njegovo sestavo, izboljšanje obstoječih itd. Z drugimi besedami, omogočiti bi bilo treba enostavno dodajanje in spreminjanje, ne da bi pri tem ogrozili integriteto sistema. Pristop odjemalec-strežnik pri strukturiranju operacijskega sistema z uporabo mikrojedrske tehnologije ponuja odlične možnosti za širitev. V skladu s tem pristopom je OS zgrajen kot niz privilegiranih nadzornih programov in niz neprivilegiranih storitev (strežnikov). Glavni del OS ostaja nespremenjen, hkrati pa je mogoče dodati nove strežnike ali izboljšati stare. To načelo se včasih razlaga kot razširljivost sistema.

9.) Načelo mobilnosti: operacijski sistem mora biti relativno enostaven za prenos

za povezavo z ene vrste procesorja na drugo vrsto procesorja in s strojne platforme ene vrste, ki skupaj z vrsto procesorja in načinom organizacije vse računalniške strojne opreme (arhitektura računalniškega sistema) vključuje drugo vrsto strojne platforme . Upoštevajte, da je načelo prenosljivosti zelo blizu načelu združljivosti, čeprav to ni isto. Pisanje prenosnega OS je podobno pisanju katere koli prenosne kode, vendar morate nekaj upoštevati pravila:

- večina operacijskega sistema mora biti izvedena v jeziku, ki je na voljo v vseh sistemih, v katere se načrtuje prenos v prihodnosti. To v prvi vrsti pomeni, da mora biti OS napisan v jeziku visoka stopnja, po možnosti standardizirano, na primer v C. Program, ki je napisan v sklopu, običajno ni prenosljiv.

- pomembno je zmanjšati ali, če je mogoče, izključiti tiste dele kode, ki neposredno vplivajo na strojno opremo. Odvisnost od strojne opreme ima lahko različne oblike. Nekatere očitne oblike odvisnosti vključujejo neposredno manipulacijo registrov in druge strojne opreme. Nazadnje, če strojno odvisne kode ni mogoče popolnoma izključiti, jo je treba izolirati v več dobro lokaliziranih modulov. Kode, odvisne od strojne opreme, ni treba distribuirati po sistemu. Na primer, lahko v programirljivem abstraktnem podatkovnem tipu skrijete strojno odvisno strukturo.

Cilj uvedbe standardov POSIX je bil zagotoviti prenosljivost ustvarjene programske opreme.

10.) Računalniško varnostno načelo: Zagotavljanje računalniške varnosti je zaželena lastnost vsakega sistema z več uporabniki. Varnostna pravila opredeljujejo lastnosti, kot so zaščita virov enega uporabnika pred drugimi in določanje kvot virov, da bi preprečili, da bi en uporabnik prevzel vse sistemske vire, na primer pomnilnik.

Zagotavljanje zaščite informacij pred nepooblaščenim dostopom je obvezna funkcija omrežnih operacijskih sistemov.

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

KajPOSIX: sistemski vmesnik, neodvisen od platforme za računalniško okolje POSIX (prenosni vmesnik operacijskega sistema za računalniška okolja) je standard IEEE (Inštitut inženirjev elektrotehnike in elektronike), ki opisuje sistemske vmesnike za odprte operacijske sisteme, vključno z lupinami, pripomočki in kompleti orodij. Poleg tega so standardizirane varnostne naloge POSIX, naloge v realnem času, administrativni procesi, omrežne funkcije in obdelava transakcij. Standard temelji na sistemih UNIX, vendar ga je mogoče implementirati tudi v druge operacijske sisteme. POSIX je nastal kot poskus po vsem svetu znana organizacija IEEE spodbuja prenosljivost aplikacij v okoljih UNIX z razvojem abstraktnega standarda, neodvisnega od platforme. Na primer, dobro znani OS QNX v realnem času ustreza specifikacijam tega standarda.

Ta standard podrobno opisuje sistem navideznega pomnilnika VMS (navidezni pomnilniški sistem), večopravilnost MPE (večprocesno izvajanje) in konvergentno tehnologijo, proizvedeno v operacijskem sistemu ... (CTOS). Tako je POSIX pravzaprav niz standardov, imenovanih POSIX.I –POSIX.12. Prav tako je treba opozoriti, da POSIX.1 prevzame C kot glavni jezik.

Jezik opisa funkcij sistema API.

Tako se bodo programi, napisani v skladu s temi standardi, izvajali enako na vseh sistemih, skladnih s POSIX. Vendar je v nekaterih primerih standard le svetovalne narave. Nekateri standardi so opisani zelo strogo, drugi del pa le površno razkriva osnovne zahteve.

Izvedbe operacijskega sistema API POSIX so različne. Če velika večina sistemov UNIX sprva ustreza specifikacijam standarda IEEE 1003.1-1990, potem WinAPI ni skladen s POSIX. Za podporo tega standarda v operacijskem sistemu MS Windows NT je bil uveden poseben podporni modul POSIX API, ki deluje na ravni privilegijev uporabniških procesov.

Ta modul omogoča pretvorbo in prenos klicev iz uporabniškega programa v sistemsko jedro in nazaj, pri čemer deluje z jedrom prek API -ja Win. Druge aplikacije, zgrajene z WinAPI, lahko posredujejo informacije aplikacijam POSIX prek standardnih mehanizmov V / I toka (stdin, stdout).

Ni povezanih objav ...