Kurs omawia standard interfejsu mobilnego systemu operacyjnego (POSIX), a także techniki i metody programowania aplikacji opartych na tym standardzie, zilustrowane licznymi przykładami. Poruszone zostały zagadnienia programowania systemów wieloprocesowych, współdziałania aplikacji w ramach konfiguracji rozproszonych. Zapewnienie mobilności (przenośność, przenośność) oprogramowanie(PO) jest zadaniem o wyjątkowej wadze i złożoności; W dzisiejszych czasach ta okoliczność nie wymaga obszernego uzasadnienia.Jednym z powszechnie akceptowanych sposobów zwiększenia mobilności oprogramowania jest standaryzacja środowiska aplikacji: dostarczonych interfejsów oprogramowania, narzędzi itp. Na poziomie usług systemowych takie środowisko opisuje standard POSIX (Portable Operating System Interface); nazwę zasugerował znany specjalista, założyciel Fundacji Wolnego Oprogramowania Richard Stallman.

Kurs omawia jego najnowocześniejszą wersję w edycji z 2003 roku, którą można nazwać „potrójnym standardem”, a mianowicie: standard IEEE Std 1003.1, standard techniczny Open Group oraz, co dla nas najważniejsze, międzynarodowy ISO/IEC 9945 standard tego kursu dotyczy zrozumienia technik i metod korzystania ze znormalizowanych narzędzi i funkcji. Celem nie było powtarzanie standardu, podkreślanie wszystkich subtelności implementacji systemu operacyjnego, wszystkich możliwych kodów błędów itp. Najważniejsze, naszym zdaniem, to poczuć ducha standardu, nauczyć się korzystać z tkwiących w nim możliwości w sposób mobilny. Zakładając, że czytelnik biegle posługuje się językiem C, nie rozważaliśmy ani jego składni, ani funkcji bibliotecznych podręczników. Jeśli chodzi o standardowy język poleceń i jego interpreter, ten temat jest szczegółowo opisany, chociaż wielu praktykujących programistów woli używać innych interpreterów. Istotne miejsce – zarówno pod względem wielkości, jak i roli – zajmują przykłady programów. Wiele zapisów normy (związanych np. z obsługą sytuacji błędów) znajduje się nie w tekście głównym, ale w odpowiednich przykładach, które w miarę możliwości zostały skompilowane i wykonane na kilku platformach sprzętowych i programowych, na jednej. stopień lub inny twierdzący, że jest zgodny ze standardem POSIX. Jednak z pewnością możliwe są przeoczenia. Będziemy wdzięczni za wszelkie uwagi i sugestie dotyczące zarówno całego kursu, jak i poszczególnych przykładów programów.

Historia powstania i aktualny stan standardu POSIX.

Zapewnienie mobilności (przenośności, przenośności) oprogramowania (SW) jest zadaniem o wyjątkowej wadze i złożoności; w naszych czasach ta okoliczność nie wymaga obszernego uzasadnienia. Jednym z ogólnie akceptowanych sposobów zwiększenia przenośności oprogramowania jest standaryzacja środowiska aplikacji: dostarczonych interfejsów API, narzędzi itp. Na poziomie usług systemowych takie środowisko opisuje standard POSIX (Portable Operating System Interface); nazwa została zasugerowana przez znanego eksperta, założyciela Free Software Foundation, Richarda Stallmana.

Strona tytułowa.
Wyjście.
Wykład 1. Podstawowe pojęcia i idee standardu POSIX.
Wykład 2. Język powłoki.
Wykład 3. Narzędzia i funkcje służące pojęciu „użytkownika”.
Wykład 4. Organizacja systemu plików.
Wykład 5. Wejście/wyjście pliku.
Wykład 6. Narzędzia przetwarzania danych strukturalnych.
Wykład 7. Procesy.
Wykład 8. Sposoby komunikacji międzyprocesowej.
Wykład 9. Wspólny interfejs terminala.
Wykład 10. Badanie charakterystyk hostów i ich wykorzystanie w aplikacjach.
Wykład 11. Obiekty sieciowe.
Wykład 12. Czas i praca z nim.
Wykład 13. Środowisko językowe i kulturowe.
Wykład 14. Podsumowanie.
Bibliografia.

Darmowe pobieranie e-book w wygodnym formacie obejrzyj i przeczytaj:
Pobierz książkę Programowanie w standardzie POSIX, część 1, Galatenko V.A., 2016 - fileskachat.com, szybkie i bezpłatne pobieranie.

POSIX i RV OS: próba systematyzacji

Sergey Zolotarev, Nikolay Gorbunov

Celem tego artykułu jest próba wyjaśnienia historii rozwoju standardu POSIX w zastosowaniu do systemów operacyjnych czasu rzeczywistego (RT OS).

Na wstępie: dlaczego potrzebna jest standaryzacja interfejsu programistycznego?

Jedną z najważniejszych cech standardu POSIX jest to, że definiuje on „znormalizowany interfejs programistyczny”, którego muszą przestrzegać twórcy złożonych systemów oprogramowania i sprzętu. Twórcy tych systemów zmuszeni są stawić czoła takim wymogom, jak krótki czas wprowadzenia produktu na rynek (ze względu na ostrą konkurencję), minimalizację kosztów i przyspieszenie zwrotu z inwestycji. Jednocześnie lwia część kosztów spowodowana spowolnieniem procesu rozwoju związana jest z tym, że programiści muszą „wymyślać koło na nowo”, wciąż na nowo wdrażając dostępną od dawna funkcjonalność. Ale można było tego uniknąć poprzez:

• ponowne wykorzystanie kodu z poprzednich i równoległych projektów;
• przenoszenie kodu z innych systemów operacyjnych;
• pozyskiwanie programistów z innych projektów (w tym z wykorzystaniem innych systemów operacyjnych).

Wszystko to jest możliwe dzięki wykorzystaniu systemu operacyjnego ze znormalizowanym API. Co więcej, jeśli w pierwszym przypadku wystarczy, aby organizacja posiadała pewien wewnętrzny standard (co jest szczególnie typowe dla zastrzeżonych systemów operacyjnych), to w dwóch drugich przypadkach wystarczy obecność ogólnie przyjętych standardów - na przykład POSIX.

W ten sposób, używając systemu operacyjnego zgodnego z POSIX jako platformy dla swoich projektów, programista uzyskuje możliwość przeniesienia gotowego kodu na poziomie tekstu źródłowego zarówno ze swoich wcześniejszych lub równoległych projektów, jak i projektów stron trzecich. To nie tylko znacząco skraca czas tworzenia oprogramowania, ale także poprawia jego jakość, ponieważ testowany kod zawsze zawiera mniej błędów.

Kto jest kim w rozwoju POSIX

I nie zaczniemy od samego standardu POSIX, ale od uporządkowania roli organizacji zaangażowanych w prace nad nim.

Pierwszym uczestnikiem jest IEEE(Instytut Inżynierów Elektryków i Elektroników, Instytut Inżynierów Elektryków i Elektroników), publiczne stowarzyszenie profesjonalistów non-profit. IEEE sięga roku 1884 (formalnie - od 1963), zrzesza 380 000 indywidualnych członków ze 150 krajów, publikuje trzecią część literatury technicznej związanej z wykorzystaniem komputerów, sterowania, elektryki i informatyki oraz ponad 100 czasopism. popularny wśród profesjonalistów; ponadto stowarzyszenie organizuje ponad 300 dużych konferencji rocznie. IEEE uczestniczyło w rozwoju ponad 900 istniejących standardów (www.ieee.ru/ieee.htm). Dziś instytut ten zajmuje się przygotowywaniem, koordynacją, zatwierdzaniem, publikacją norm, ale ze względu na swój formalny status nie ma uprawnień do przyjmowania takich dokumentów jak normy międzynarodowe czy krajowe. Dlatego termin „norma” w rozumieniu IEEE należy raczej rozumieć jako „specyfikację”, która jest bardziej spójna ze statusem dokumentów akceptowanych przez stowarzyszenie. Zgodnie z IEEE uczestniczy w programach szeregu organizacji międzynarodowych i regionalnych – IEC, ISO, ITU (Międzynarodowy Związek Telekomunikacyjny), ETSI (Europejski Instytut Norm Telekomunikacyjnych), CENELEC (Europejski Komitet Normalizacji Elektrotechnicznej) oraz krajowych programy, na przykład w programie takiej organizacji jak ANSI.

IEEE obejmuje PASC (Portable Application Standards Committee), komitet stowarzyszeniowy, który rozwija rodzinę standardów POSIX (www.pasc.org/). PASC był wcześniej znany jako Komitet Techniczny Systemów Operacyjnych.

Drugi uczestnik pracy - ANSI(American National Standards Institute, American National Standards Institute) – prywatna organizacja non-profit, która administruje i koordynuje w Stanach Zjednoczonych działalność normalizacyjną. Zatrudnia tylko 75 osób, ale członkowie ANSI to ponad 1000 firm, organizacji, agencji rządowych i instytucji (www.ansi.org). ANSI reprezentuje Stany Zjednoczone w dwóch głównych międzynarodowych organach normalizacyjnych, ISO i IEC.

Trzeci uczestnik - ISO(Międzynarodowa Organizacja Normalizacyjna). Powstała w 1946 r. decyzją Komitetu ds. Koordynacji Standardów i Zgromadzenia Ogólnego ONZ i oficjalnie rozpoczęła pracę 23 lutego 1947 r. (www.iso.org). ISO to sieć krajowych instytutów normalizacyjnych ze 146 krajów (jeden kraj - jeden członek ISO) z centralnym sekretariatem w Genewie (Szwajcaria). Normy ISO są opracowywane w komitetach technicznych, których pierwszym produktem jest Projekt Normy Międzynarodowej (DIS), który po kilku zatwierdzeniach staje się Ostatecznym Projektem Normy Międzynarodowej (FDIS). Następnie kwestia zatwierdzenia tego dokumentu jest poddawana pod głosowanie; jeśli się powiedzie, staje się międzynarodowym standardem.

I w końcu - IEC(Międzynarodowa Komisja Elektrotechniczna, Międzynarodowa Komisja Elektrotechniczna - IEC), założona w 1906 roku, IEC opracowuje i publikuje międzynarodowe normy dla wszystkich technologii elektrycznych, elektronicznych i pokrewnych (www.iec.ch/). Na dzień 1 listopada 2004 r. komitety narodowe 64 krajów były aktywnymi członkami tej komisji. IEC publikuje również zalecenia, które są publikowane w języku angielskim i francuskim i mają status norm międzynarodowych. Na ich podstawie opracowywane są normy regionalne i krajowe. Komitety techniczne (TC) są odpowiedzialne za przygotowywanie norm w różnych obszarach działalności IEC, w których biorą udział komitety krajowe zainteresowane działalnością konkretnego TC.

IEC jest kluczową organizacją w przygotowaniu międzynarodowych standardów informatycznych. W tym obszarze istnieje wspólny komitet techniczny ds. technologii informatycznych - JTC 1, utworzony w 1987 r. na podstawie porozumienia między IEC i ISO. JTC1 ma 17 podkomitetów nadzorujących wszystko, od oprogramowania po języki programowania, grafikę komputerową i edycję obrazów, wzajemne połączenia sprzętu i praktyki bezpieczeństwa.

Przygotowanie nowych norm IEC obejmuje kilka etapów (etap wstępny, etap propozycji, etap przygotowawczy, etap komitetu technicznego, etap zapytania, etap akceptacji, publikacja). Jeżeli dokument IEC ma stać się jedynie specyfikacją techniczną, a nie normą międzynarodową, zaktualizowana wersja dokumentu jest wysyłana do centrali w celu publikacji. Ostateczny projekt standardu międzynarodowego (FDIS) zajmie cztery miesiące. Po zatwierdzeniu przez wszystkich członków komitetu technicznego jest przesyłany do biura centralnego w celu publikacji bez etapu zatwierdzania FDIS. Następnie FDIS trafia do komitetów krajowych, które muszą go zatwierdzić w ciągu dwóch miesięcy. FDIS jest uważany za zatwierdzony, jeśli ponad dwie trzecie komitetów narodowych głosowało za nim, a liczba głosów negatywnych nie przekracza 25%. Jeśli dokument nie zostanie zatwierdzony, jest przesyłany do weryfikacji do komitetów technicznych i podkomitetów. Norma musi zostać opublikowana nie później niż dwa miesiące po zatwierdzeniu przez FDIS.

Kilka innych organizacji jest zaangażowanych w rozwój i przyjęcie standardów POSIX.

Grupa otwarta Jest międzynarodową organizacją zajmującą się standaryzacją oprogramowania, zrzeszającą blisko 200 producentów i społeczności użytkowników działających w obszarze technologii informatycznych (www.opengroup.org/). Open Group powstała w 1995 roku z połączenia swoich dwóch poprzedników: X/Open i Open Software Foundation (OSF). Open Group specjalizuje się w opracowywaniu metodologii certyfikacji oprogramowania oraz testowaniu zgodności. W szczególności Open Group zapewnia certyfikaty dla takich obszarów jak COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S/MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) i wreszcie Rodzina standardów POSIX (www.opengroup.org/certification/).

Austin Common Standards Revision Group (CSRG)- wspólne techniczne Grupa robocza utworzona w 2002 roku przez ISO, IEC i Open Group w celu tworzenia i utrzymywania najnowsze wersje standard 1003.1, który powstanie w oparciu o normy ISO/IEC 9945-1-1996, ISO/IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 oraz Single UNIX Specification (www.opengroup.org /prasa/ 14nov02.htm).

Narodowy Instytut Standardów i Technologii (NIST)- federalna agencja w ramach Administracji Technologii Departamentu Handlu (www.nist.gov/public_affairs/general2.htm), założona w Stanach Zjednoczonych w 1901 roku. Misją NIST jest opracowywanie i promowanie standardów i technologii w celu poprawy jakości produktów. NIST obejmuje Laboratorium Technologii Informacyjnych (ITL), którego jednym z wyników są Federalne Standardy Przetwarzania Informacji (FIPS, www.opengroup.org/testing/fips/general_info.html). NIST / ITL zaoferował wstępny zestaw testów do certyfikacji POSIX zgodnie z FIPS PUB 151-1 1990 w 1991 roku.

Co to jest POSIX?

Formalnie termin POSIX zaproponowany przez Richarda Stallmana jako skrót od P stolik O operować S interfejs systemowy dla un IX(interfejs przenośnego systemu operacyjnego dla systemu Unix). POSIX został opracowany dla systemów operacyjnych podobnych do UNIX (ich najwcześniejsze wersje pochodzą z wczesnych lat 70-tych) w celu zapewnienia przenośności źródeł do aplikacji.

Wstępny opis interfejsu został opublikowany w 1986 roku, kiedy nosił nazwę IEEE-IX (wersja IEEE-Unix). Jednak nazwa szybko się zmieniła, stając się POSIX i już w następnej publikacji (w 1986 r.) ta nowa wersja była używana Przez pewien czas POSIX był rozumiany jako odniesienie (lub synonim) do grupy powiązanych dokumentów IEEE 1003.1-1988 i części ISO / IEC 9945 oraz jako kompletny i zatwierdzony międzynarodowy standard ISO / IEC 9945.1: 1990 POSIX została przyjęta w 1990 roku. Specyfikacje POSIX definiują standardowy mechanizm interakcji między programem aplikacji a systemem operacyjnym i obecnie obejmują ponad 30 standardów pod auspicjami IEEE, ISO, IEC i ANSI.

W swojej historii POSIX przeszedł długą drogę, wielokrotnie zmieniały się oznaczenia specyfikacji, ich specyficzna zawartość, procedury i logistyka ich weryfikacji. Od tego czasu w ramach różnych organizacji międzynarodowych wydano kilka edycji standardu POSIX.

Historia rozwoju standardu POSIX

Pierwsza wersja specyfikacji IEEE Std 1003.1 została opublikowana w 1988 roku. Następnie liczne edycje IEEE Std 1003.1 zostały przyjęte jako standardy międzynarodowe.

Etapy rozwoju POSIX:

1990 rok

Wydane w 1988 roku wydanie zostało poprawione i stało się podstawą do dalszych poprawek i uzupełnień. Został zatwierdzony jako międzynarodowa norma ISO/IEC 9945-1: 1990.

1993 rok

Wydanie 1003.1b-1993 zostało opublikowane.

1996 rok

Wprowadzono zmiany w normach IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995 i 1003.1i-1995, ale większość dokumentu pozostaje niezmieniona. W 1996 r. rewizja IEEE Std 1003.1 została również zatwierdzona jako międzynarodowa norma ISO / IEC 9945-1: 1996.

1998 rok

Pojawił się pierwszy standard dla "czasu rzeczywistego" - IEEE Std 1003.13-1998. Jest rozszerzeniem standardu POSIX dla wbudowanych aplikacji czasu rzeczywistego.

1999 rok

Postanowiono wprowadzić istotne zmiany w głównym tekście standardu po raz pierwszy w ciągu ostatnich 10 lat, w tym połączenie ze standardem 1003.2 (Shell i narzędzia), ponieważ do tego czasu były to odrębne standardy. PASC zdecydował się sfinalizować zmiany tekstu bazowego po ukończeniu standardów IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q i 1003.2b.

2004 r.

Najnowsza wersja 1003.1 została opublikowana 30 kwietnia i wydana pod auspicjami Austin Common Standards Revision Group. Została ona zmieniona do wydania normy z 2001 r. Formalnie, wydanie 2004 jest znane jako IEEE Std 1003.1, 2004 Edition, Specyfikacje bazy danych technicznych Open Group, wydanie 6 i obejmuje IEEE Std 1003.1-2001, IEEE Std 1003.1-2001/ Cor 1-2002 i IEEE Std 1003.1-2001 / Cor 2-2004.

Najważniejsze standardy POSIX dla RT OS

W przypadku systemów operacyjnych czasu rzeczywistego najważniejsze jest siedem specyfikacji standardu (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), ale tylko trzy otrzymały szerokie wsparcie w komercyjnych systemach operacyjnych:

• 1003.1a (definicja systemu operacyjnego) definiuje główne interfejsy systemu operacyjnego, kontrolę zadań, sygnały, funkcje systemu plików oraz pracę z urządzeniami, grupami użytkowników, potokami, buforami FIFO;
• 1003.1b (Rozszerzenia w czasie rzeczywistym) opisuje rozszerzenia czasu rzeczywistego takie jak sygnały czasu rzeczywistego, szeregowanie priorytetów, timery, synchroniczne i asynchroniczne we/wy, semafory, pamięć współdzielona, ​​komunikaty. Początkowo (przed 1993) standard ten nosił nazwę POSIX.4.
• 1003.1c (wątki) definiuje funkcje obsługi wątków - kontrola wątków, atrybuty wątków, muteksy, rozsyłanie. Pierwotnie oznaczony jako POSIX.4a.

Oprócz tych standardów ważne są dla RT OS następujące standardy, które zostały wdrożone w ramach prac nad projektem Std 1003.1-2001:

• IEEE 1003.1d-1999. Dodatkowe rozszerzenia w czasie rzeczywistym. Pierwotnie oznaczony jako POSIX.4b;
• IEEE 1003.1j-2000. Ulepszone (zaawansowane) rozszerzenia w czasie rzeczywistym;
• IEEE 1003.1q-2000. Rysunek kalkowy.

Procedura certyfikacji

Aby był zgodny z POSIX, system operacyjny musi być certyfikowany zgodnie z odpowiednim zestawem testów. Od czasu wprowadzenia POSIX zestaw testów przeszedł formalne i de facto zmiany.

W 1991 roku NIST opracował program testujący POSIX zgodnie z FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). Ta opcja testu była oparta na IEEE 1003.3 „Standard for Test Methods for Measurement Conformance to POSIX” Draft 10, 3 maja 1989. W 1993 roku NIST zakończył program testowania POSIX dla FIPS 151-1 i rozpoczął program dla FIPS 151-2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 dostosował „Information Technology – Portable Operating System Interface (POSIX) – Part 1: System Application Program Interface (API)”, który jest standardem ISO/IEC 9945-1: 1990. Zestawy testów dla FIPS 151-2 zostały oparte na normie IEEE 2003.1-1992 „Standard for Test Methods for Measurement Conformance to POSIX”.

NIST rozróżnia dwie metodologie certyfikacji: samocertyfikację i certyfikację przez laboratoria badawcze akredytowane przez IEEE (Accredited POSIX Testing Laboratories - APTL). W pierwszym przypadku firma przeprowadza testy samodzielnie, ale zgodnie z planem zatwierdzonym przez NIST. W drugim przypadku testy przeprowadza niezależne laboratorium przy użyciu zautomatyzowanych zestawów testowych. W sumie akredytowano dwa laboratoria APTL: Mindcraft (www.mindcraft.com) i Perennial (www.peren.com).

W 1997 r. NIST/ITL ogłosił zamiar zakończenia certyfikacji FIPS 151-2 pod koniec tego roku (oficjalnie 31 grudnia 1997 r.), podczas gdy Open Group ogłosiła, że ​​przejmie ją od 1 października tego roku. roczna usługa certyfikacji zgodnie z FIPS 151-2, w oparciu o program NIST/ITL. Te same funkcje zostały przejęte przez IEEE Standards Association (IEEE-SA) od 1 stycznia 1998 roku, również w oparciu o FIPS 151-2.

W 2003 roku IEEE-SA i Open Group ogłosiły nowy wspólny program certyfikacji najnowszych wersji POSIX, począwszy od IEEE 1003.1 ™ 2001. Open Group ma teraz kilka zestawów testów obejmujących 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). Produkt uznaje się za certyfikowany zgodnie z POSIX, jeśli przeszedł pełną procedurę certyfikacji, zgodnie z wynikami testów spełnia wszystkie wymagania i jest wpisany do oficjalnego rejestru certyfikowanych produktów.

Zestawy testowe obejmują:

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - zestaw testów zgodności interfejsów systemowych IEEE Std 1003.1-1990;
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - zestaw testów zgodności dla IEEE Std 1003.13-1998 Profile PSE54 (wielofunkcyjny czas rzeczywisty);
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - zestaw testów zgodności interfejsów systemowych IEEE Std 1003.1-2003 (tylko części obowiązkowe);
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) to zestaw testów zgodności dla IEEE Std 1003.1-2003 (powłoka i narzędzia - tylko wymagane części).

Ponadto Open Group opracowała testy porównawcze dla standardów POSIX Realtime Standards i Embedded POSIX Standards Profile. POSIX Realtime Test Suite (www.opengroup.org/testing/testsuites/realtime.html) zawiera następujące testy:

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Rozszerzenie czasu rzeczywistego i wydanie IEEE POSIX 1003.1,2003;
• IEEE Std POSIX 1003.1c-1995 rozszerzenie Threads (pthreads) i IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1d-1999 Dodatkowe rozszerzenie czasu rzeczywistego i IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1j-2000 Advanced Realtime Extension i IEEE POSIX 1003.1,2003 Edition;
• IEEE POSIX 1003.1q-2000 Trace i IEEE POSIX 1003.1,2003 Edition oraz IEEE POSIX 1003.1,2003 Edition;

Pakiet Embedded POSIX Standards Profile Test Suite (www.opengroup.org/testing/testsuites/embedded.html) zawiera następujące testy:

• IEEE POSIX 1003.1-1990 (5310 testów);
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Rozszerzenie czasu rzeczywistego (1430 testów);
• IEEE Std POSIX 1003.1c-1995 Rozszerzenie wątków (pthreads) (1232 testy);
• IEEE POSIX 1003.13-1998 Profil 52.

Trochę o zamieszaniu terminologicznym

W stosunku do grupy standardów POSIX w języku angielskim często używa się nie jednego, a aż trzech terminów. Niestety mają one podobne znaczenie i często tłumaczone są w ten sam sposób, co wprowadza pewne zamieszanie. Terminy te są następujące:

• kompatybilność (dosłownie - „kompatybilność”);
• zgodność (dosłownie - „zgodność”);
• zgodność (dosłownie „spójność”).

Pierwszy termin zastosowany do POSIX nie jest formalnie zdefiniowany. Drugie oznacza, że ​​organizacja – producent oprogramowania, samodzielnie deklaruje, że ten produkt (w całości lub w części) jest zgodny z wymienionymi normami NIST-PCTS. Trzeci termin oznacza, że oprogramowanie zdał ustalony system testowy albo z pomocą akredytowanego laboratorium, albo w ramach Open Group i istnieje na to udokumentowany dowód (tzw. Oświadczenie o zgodności). W dalszej części artykułu oryginały terminów będą cytowane wszędzie w celu wyeliminowania niejasności.

Certyfikowany OS RV

Jeśli przestrzegasz surowych zasad, które wymagają, aby dane dotyczące certyfikowanego RT OS były publikowane w oficjalnym rejestrze, a testy przeprowadzane są na poziomie zgodności, to obecnie istnieją tylko dwa certyfikowane RT OS (dane podane są w porządku chronologicznym):

LynxOS v.3(produkt Lynx Real-Time Systems, obecnie LynuxWorks, Inc., www.lynuxworks.com) jest przeznaczony do tworzenia oprogramowania dla systemów wbudowanych działających w czasie rzeczywistym, producentów OEM i sprzętu telekomunikacyjnego, w szczególności producentów systemów pokładowych do zastosowań wojskowych ... Rozwój może odbywać się zarówno na samym systemie docelowym (samohosting), jak i na komputerze instrumentalnym (host), gotowe oprogramowanie jest przeznaczone do pracy na systemie docelowym (docelowym). LynxOS v.3 posiada certyfikat zgodności z POSIX na platformach Intel i PowerPC. Informacje na ten temat można znaleźć na stronie IEEE pod adresem http://standards.ieee.org/regauth/posix/posix2.html. LynxOS posiada certyfikat POSIX 1003.1-1996 wydany przez Mindcraft, akredytowane laboratorium testowe POSIX IEEE POSIX na zestawie testów zgodności NIST FIPS 151-2. Numer dokumentu certyfikacji: Plik referencyjny: IP-2LYX002, Plik referencyjny: IP-2LYX001.

UCZCIWOŚĆ v.5(produkt Green Hills Software, www.ghs.com) posiada certyfikat zgodności z POSIX 1003.1-2003, System Interfaces for PowerPC architecture w lipcu 2004 (http://get.posixcertified.ieee.org/select_product.tpl). Zestaw testowy VSX-PCTS 2003.

POSIX i system operacyjny QNX

QNX v.4.20 (opracowany przez QNX Software Systems, www.qnx.com) posiada certyfikat zgodności platformy Intel z POSIX 1003.1-1988 wydany przez DataFocus Incorporated. Testy przeprowadzone 13 września 1993 i wydane 1 listopada 1993. NIST PCTS 151-1 Test Suite, wersja 1.1.

QNX Neutrino (wersja 6.3) jest zgodny z następującymi standardami rodziny 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, twórca QNX Neutrino, również planuje zgodność QNX Neutrino z niektórymi z tych standardów; prace planowane są na 2005 rok (www.qnx.com/news/pr_959_1.html).

Literatura

1. Instrukcja obsługi stowarzyszenia standardów IEEE. IEEE, październik 2004.
2. Kevina M. Obelanda. POSIX w czasie rzeczywistym, programowanie systemów wbudowanych, 2001.
3. Standard IEEE / ANSI 1003.1: Technologia informacyjna — (POSIX) — Część 1: Aplikacja systemu: Interfejs programowy (API).
4. Gallmeister, B.O. Programowanie w świecie rzeczywistym, POSIX.4 Sewastopol, Kalifornia: O'Reilly & Associates, 1995.
5. Narodowy Instytut Standardów i Technologii, PCTS: 151-2, POSIX Test Suite.
6. POSIX: Certyfikat IEEE i The Open Group. Certyfikowana Polityka. The Open Group, 21 października 2003, wersja 1.1.

Aleksiej Fiodorczuk
2005 rok

Jedną z charakterystycznych cech logicznej struktury systemu plików systemów operacyjnych z rodziny POSIX jest ich hierarchiczna lub podobna do drzewa organizacja (chociaż, jak powiedziałem, drzewo wygląda trochę dziwnie). Oznacza to, że tak jak w DOS lub Windows wszelkiego rodzaju, nie ma oznaczenia (na przykład alfabetycznego lub innego) dla poszczególnych nośników i ich partycji: wszystkie są zawarte w pojedynczej strukturze jako podkatalogi katalogu głównego. zwany korzeń. Proces połączenia systemy plików na niezależnych nośnikach fizycznych (i ich partycjach) do katalogu głównego drzewa plików nazywa się montowanie, a zawarte w nich podkatalogi nazywane są punktami montowania.

Historycznie rzecz biorąc, Unix opracował specyficzną strukturę katalogów, która jest bardzo podobna w całej rodzinie pod względem ogólnym, ale nieco inna w szczegółach. W szczególności hierarchia plików w systemach BSD jest prawie identyczna, ale różni się od tej w systemie Linux. A w tym ostatnim występują znaczne różnice między różnymi dystrybucjami. Do tego stopnia, że ​​struktura hierarchii plików jest jedną z cech charakterystycznych dla dystrybucji.

Taki stan rzeczy utrudnia pisanie aplikacji wieloplatformowych. Dlatego istnieje i aktywnie rozwija projekt standaryzacji hierarchii plików - FHS (Filesystem Hierarchy Standard).

Projekt FHS miał na celu przede wszystkim usprawnienie struktury katalogów w wielu dystrybucjach Linuksa. Został później zaadaptowany dla innych Systemy uniksopodobne(w tym klan BSD). A teraz podejmowane są aktywne (ale niezbyt udane) wysiłki, aby uczynić go standardem dla systemów POSIX, nie tylko z nazwy, ale także w rzeczywistości.

Standard FHS opiera się na dwóch fundamentalnych zasadach - wyraźnym oddzieleniu w hierarchii plików katalogów współdzielonych i niewspółdzielonych z jednej strony oraz niezmiennych i mutowalnych z drugiej.

Kontrast między katalogami współdzielonymi i niewspółdzielonymi wynika z nieodłącznej sieciowej natury Unixa. Oznacza to, że dane związane z maszyną lokalną (na przykład pliki konfiguracyjne dla jej urządzeń) powinny znajdować się w katalogach odrębnych od tych, których zawartość jest dostępna z innych maszyn w sieci, lokalnych lub globalnych (przykładem jest nie tylko użytkownik dane, ale także programy) ...

Istotę opozycji między katalogami niezmiennymi i zmiennymi łatwo wyjaśnić na przykładzie. Zatem te same ogólne programy użytkownika ze swej natury powinny być niezmienne (a raczej dostępne do modyfikacji tylko dla administratora systemu, ale nie dla samego użytkownika, który używa ich w swojej pracy). Jednocześnie programy te podczas swojej pracy generują nie tylko pliki danych, powiedzmy, teksty czy obrazy (ich zmienny charakter jest czytelny bez komentarzy), ale wszelkiego rodzaju informacje serwisowe, takie jak pliki dziennika, pliki tymczasowe itp.) . Które powinny być pogrupowane w katalogach oddzielonych od rzeczywistych plików wykonywalnych programów wymaganych do ich uruchomienia, bibliotek, plików konfiguracyjnych itp.

Niemniej jednak, pomimo aktywnej promocji w wielu dystrybucjach Linuksa spośród najpopularniejszych, FHS nie uzyskał statusu prawdziwego standardu. Istnieje wiele dystrybucji Linuksa, które nie korzystają z niektórych jego postanowień. I tylko częściowo koreluje z tradycyjną hierarchią plików systemów BSD.

Powodem jest to, że FHS ignoruje jeszcze jeden sprzeciw, który jest bardzo ważny dla użytkownika: sprzeciw dotyczący łatwych do odzyskania części systemu plików oraz tych jego komponentów, które są trudne do odzyskania lub w ogóle nie do odzyskania.

Pierwsze, co dziwne, można przypisać samemu systemowi bazowemu: w końcu ponowna instalacja z nośnika dystrybucyjnego w przypadku fatalnej awarii nie jest taka trudna. Trudne do odzyskania części systemu plików oczywiście zawierają dane użytkowników: nawet jeśli są regularnie tworzone kopie zapasowe (i ilu użytkowników jest tak ostrożnych?), Wdrażanie ich z archiwów zajmie dużo czasu (i prawie nieuchronnie pociągnie za sobą straty).

Dodatkowo w systemach BSD i dystrybucjach Source Based Linux zaklasyfikowałbym wszystko związane z zarządzaniem pakietami jako katalogi trudne do odzyskania - drzewo portów FreeBSD lub pkgsrc w NetBSD (i systemach, które go pożyczyły), ich odpowiedniki w dystrybucjach Linuksa, rzeczywiste źródła przeniesionych programów, a także kod źródłowy systemu. Ponieważ nawet jeśli to wszystko znajduje się w pakiecie dystrybucyjnym, te komponenty systemu plików są z reguły aktualizowane przez użytkownika poprzez synchronizację z serwerami projektu przez sieć (w przeciwnym razie ich użycie jest bezsensowne). A ich utrata pociągnie za sobą zarówno straty tymczasowe (zwłaszcza przy połączeniu modemowym), jak i finansowe (niewiele osób jest szczęśliwymi posiadaczami darmowego dostępu do Internetu).

Ścisłe przestrzeganie koncepcji oddzielenia współdzielonych i nieudostępnionych, niezmiennych i niezmiennych, możliwych do odzyskania i nieodzyskiwalnych katalogów od siebie pozwala, w ramach jednej hierarchii plików przypominającej drzewo, na fizyczne oddzielenie poszczególnych gałęzi - to znaczy w formie niezależnych systemów plików znajdujących się na izolowanych urządzeniach (dyski, partycje dyskowe, plasterki, partycje itp.). Powodów tego jest wiele – zarówno wzrost wydajności, jak i zwiększenie niezawodności, a także względy wygody – ale nie będziemy o nich teraz rozmawiać. Ponieważ w ten moment ważne dla nas jest to, że te gałęzie drzewa plików muszą zostać włączone do wspólnego systemu plików.

Typowy zestaw katalogów systemowych POSIX

W rzeczywistości do działania absolutnie niezbędny jest tylko jeden system plików - ten, który jest zamontowany w katalogu głównym drzewa plików (rodzaj odpowiednika drzewa świata Yggdrassil). Katalog główny i jego niezbędne gałęzie muszą stanowić jeden system plików umieszczony na jednym nośniku – dysku, partycji dyskowej, programowej lub sprzętowej macierzy RAID, czy też woluminie logicznym w rozumieniu LVM. Powinien zawierać wszystkie elementy niezbędne do uruchomienia systemu, a najlepiej nic więcej.

Możesz wyświetlić skład katalogu głównego za pomocą polecenia

zł ls -1 /

który w dowolnym systemie POSIX pokaże jakiś minimalny zestaw katalogów dla dżentelmenów:

Bin / boot / etc / root / sbin /

To w nich gromadzone są wszystkie pliki, bez których system nie może istnieć. Inne katalogi to mniej więcej tak:

Strona główna / mnt / opt / tmp / usr / var /

a) nie są wymagane (przynajmniej teoretycznie – praktycznie trudno się bez nich obejść), b) nie wszystkie występują we wszystkich systemach i dystrybucjach oraz c) każdy z nich może być (i często jest – jeśli robisz wszystko zgodnie ze swoim umysłem) punkt montowania własnej gałęzi drzewa plików.

Ponadto w większości przypadków w katalogu głównym systemu plików systemów operacyjnych zgodnych z POSIX znajdują się jeszcze dwa podkatalogi:

Deweloper / proc /

Są to zwykle punkty montowania wirtualnych systemów plików - odpowiednio urządzeń i procesów (chociaż, jeśli system plików urządzeń nie jest używany, katalog / dev musi być składnikiem głównego systemu plików. Wreszcie w systemach Linux, jak regułą jest, że katalogiem głównym drzewa plików jest również katalog / lib dla głównych bibliotek systemowych, aw przypadku udev nieunikniony katalog / sys jest także miejscem, w którym montowany jest wirtualny system plików sysfs.

Główny system plików

Główny system plików nie może być udostępniany (to znaczy, że nie jest przeznaczony do udostępniania przez różne komputery w sieci) i niezmienny (to znaczy, że tylko administrator systemu może wprowadzać w nim zmiany, ale nie programy użytkownika i co więcej, nie użytkownicy). Ponadto zdecydowanie odradza się tworzenie w nim podkatalogów wykraczających poza te przewidziane przez standard (i wymienione powyżej).

Wypełnianie głównego systemu plików jest wybrane tak, aby maszyna mogła się uruchomić i zachować minimalną funkcjonalność nawet podczas awaryjnego rozruchu (lub w trybie jednego użytkownika), gdy wszystkie inne systemy plików nie są zamontowane (i odpowiednio jego gałęzie, takie jak / usr lub / var mogą być niedostępne.

W związku z tym start maszyny jest zapewniany przez pliki katalogowe / boot i / etc. Pierwsza zawiera jądro systemu — plik wykonywalny „specjalnego przeznaczenia” — i wszystko, co jest wymagane do jego załadowania — w systemie Linux, na przykład mapę systemu (/etc/System.map) oraz we FreeBSD — ładowalne moduły jądra . Czasami jednak jądro znajduje się bezpośrednio w katalogu głównym systemu plików i wtedy katalog / boot może być całkowicie nieobecny, a katalog / modules może być zarezerwowany dla modułów jądra.

Katalog / etc jest przeznaczony dla ogólnosystemowych plików konfiguracyjnych, które określają warunki jego ładowania. Jego zawartość bardzo mocno zależy od systemu (a w Linuksie - także od pakietu dystrybucyjnego), dlatego nie będę go tutaj rozważał - do tego tematu będę musiał wrócić jeszcze nie raz.

Minimalną niezbędną funkcjonalność zapewnia zawartość katalogów /bin i /sbin - zawierają one pliki wykonywalne odpowiednio najważniejszych programów użytkownika i systemowych, tych, które pozwolą wykonać kompleks działań naprawczych i ratunkowych i doprowadzić samochód do ludzkiej postaci po awarii.

Podział programów systemowych i programów użytkownika na podkatalogi główne jest raczej arbitralny. Żadne z tych poleceń nie jest tak naprawdę przeznaczone do rozwiązywania problemów użytkowników. Tyle, że katalog / bin zawiera polecenia administracyjne, do których od czasu do czasu uzyskuje dostęp (lub może uzyskać do nich dostęp) zwykły użytkownik, a katalog sbin jest przeznaczony dla poleceń, o których użytkownik nie powinien wiedzieć. A z których w większości przypadków nadal nie będzie mógł skorzystać ze względu na brak odpowiednich uprawnień (np. wymaganych praw dostępu do plików urządzeń).

Aby uruchamiać programy POSIX (w tym te skompilowane w katalogach /bin i sbin), z reguły potrzebny jest dostęp do funkcji bibliotek systemowych (przede wszystkim głównej biblioteki glibc). A zatem (prawie) niezbędnym składnikiem katalogu głównego jest podkatalog /lib, w którym są one montowane.

W Linuksie katalog / lib spełnia jeszcze jeden ważny cel — jego podkatalog ( / lib / modules) zawiera ładowalne moduły jądra (w FreeBSD ich miejsce to / boot / kernel).

FreeBSD nie wykrywa katalogu /lib w głównym systemie plików - odpowiednie komponenty są umieszczone tutaj w /usr/lib (patrz poniżej). Dzieje się tak, ponieważ, historycznie, FreeBSD zbudowało główne programy ogólnosystemowe, dzięki czemu funkcje biblioteczne, których potrzebują, są osadzone w ich plikach wykonywalnych (tzw. linkowanie statyczne, które zostanie omówione w rozdziale 14). We FreeBSD 5. gałęzi programy z katalogów /bin i /sbin są łączone dynamicznie, to znaczy w przypadku braku katalogu /usr (a we Free jest to prawie zawsze osobna gałąź systemu plików) nie działają. Aby to zrekompensować, istnieje katalog /restore wykraczający poza standardy, zawierający te same programy, ale powiązany statycznie (jak sugeruje nazwa katalogu, jedynym przeznaczeniem jego zawartości są operacje ratunkowe).

Wreszcie / root. Jest to zwykły katalog domowy użytkownika o tej samej nazwie, czyli administratora systemu. Ponieważ nie wykonuje żadnej praktycznej pracy (a przynajmniej nie powinien tego robić), jego zawartość to tylko własne pliki konfiguracyjne administratora (powłoka poleceń użytkownika, ulubiony edytor itd.).

Oddział / usr

Historycznie katalog /usr był przeznaczony dla programów i danych użytkownika. Funkcje te są teraz podzielone między /usr/local i /home (chociaż ten ostatni jest teraz domyślnie dowiązaniem symbolicznym do /usr/home we FreeBSD). Katalog / usr — nie modyfikowalny, ale współdzielony — służy jako repozytorium większości aplikacji i wszystkiego, co z nimi związane — kodu źródłowego, plików konfiguracyjnych, bibliotek współdzielonych, dokumentacji i tym podobnych.

Skład katalogu /usr różni się znacznie między systemami BSD i Linux. W pierwszym zawiera tylko integralne części systemu operacyjnego (tego, który we FreeBSD łączy koncepcja Dystrybucji). Aplikacje instalowane z portów lub pakietów mają swoje miejsce w podkatalogu /usr/local, który może reprezentować osobną gałąź drzewa plików.

W systemie Linux katalog / usr służy jako repozytorium dla wszystkich programów (i ich komponentów) zawartych w pakiecie dystrybucyjnym. A podkatalog /usr/local jest zwykle przeznaczony dla programów, które są niezależnie kompilowane ze źródeł.

W każdym razie zwykły skład katalogu /usr jest następujący (zgłoszony przez polecenie ls -1):

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

Jak już wspomniano, podkatalog /usr/local jest oddzielną gałęzią drzewa plików i dlatego będzie rozpatrywany oddzielnie. Przeznaczenie pozostałych katalogów jest następujące:

• /usr/bin i /usr/sbin przeznaczone są dla plików wykonywalnych programów użytkownika i systemowych (tu granica między nimi jest jeszcze bardziej dowolna niż w przypadku katalogu głównego), których cel wykracza poza zapewnienie podstawowego funkcjonowania system;
• /usr/etc jest dla pojedynczych plików konfiguracyjnych aplikacji;
• /usr/include zawiera tzw. pliki nagłówkowe wymagane do linkowania pliki wykonywalne z komponentami bibliotecznymi;
• /usr/lib i /usr/libexec to katalogi dla bibliotek współdzielonych, od których zależą aplikacje użytkownika;
• /usr/share – repozytorium najbardziej zróżnicowane, tzw. komponenty niezależne architektonicznie: tutaj możesz zobaczyć dokumentację w różnych formatach oraz przykłady plików konfiguracyjnych i danych używanych przez programy do zarządzania konsolą (czcionki, układy klawiatury) oraz opis stref czasowych;
• / usr / src - katalog z kodem źródłowym; w Linuksie zwykle umieszczane są tutaj tylko kody źródłowe jądra (jądra) systemu, w klonach BSD - pełny zestaw źródeł kompleksu, który we FreeBSD nosi nazwę Dystrybucje; z reguły niepożądane jest umieszczanie tutaj źródeł samoskładających się programów;
• /usr/X11R6 - katalog na komponenty systemu okienkowego X - pliki wykonywalne (/usr/X11R6/bin), biblioteki (/usr/X11R6/lib), nagłówki (/usr/X11R6/include), dokumentacja (/usr/X11R6/ facet); Pliki aplikacji X nie powinny być tutaj umieszczane (poza, być może, menedżerami okien) - ich miejsce znajduje się w /usr, /usr/local lub /opt, w zależności od systemu.

Ponadto katalog /usr może zawierać podkatalogi /usr/var i /usr/tmp — zwykle dowiązania symboliczne do odpowiednich gałęzi katalogu głównego. W niektórych dystrybucjach Linuksa główna dokumentacja ogólnosystemowa — strony podręcznika systemowego (w podkatalogu /usr/man) — jest umieszczana bezpośrednio w katalogu /usr.

Wreszcie, w systemach BSD i niektórych dystrybucjach Linuksa opartych na źródłach (na przykład Gentoo), katalog / usr zawiera podkatalog systemu zarządzania pakietami - porty FreeBSD i OpenBSD (/ usr / ports), ich odpowiedniki w innych systemach (/ usr / portage w Gentoo). Choć z punktu widzenia przestrzegania litery i ducha standardu FHS (sam nie wspomina ani słowa o portach i podobnych systemach), bardziej logicznym miejscem ich umieszczenia byłby katalog /var (patrz niżej) - i dokładnie to robi się w dystrybucjach takich jak CRUX i Archlinux.

Oddział / usr / lokalny

Jak już wspomniano, gałąź /usr/local w systemie Linux jest przeznaczona do samodzielnego kompilowania programów ze źródeł (nie zawartych w tym zestawie dystrybucyjnym). A we FreeBSD służy jako dom dla większości aplikacji użytkownika — prawie wszystkiego poza dystrybucjami i instalowanych z pakietów lub portów. W związku z tym struktura katalogów jest bardzo podobna do struktury gałęzi /usr (z zrozumiałymi wyjątkami):

Bin / etc / include / lib / man / sbin / share /

Zawartość podkatalogów jest również podobna: pliki wykonywalne programów (/usr/local/bin i /usr/local/sbin), ich konfiguracje (/usr/local/etc), biblioteki, z którymi są połączone oraz ich pliki nagłówkowe ( /usr/local/lib i /usr/local/include, odpowiednio), strony podręcznika systemowego (/usr/local/man) i wszelkiego rodzaju rzeczy niezależne od architektury (/usr/local/share), w tym dokumentacja w innych formatach.

/ Oddział Opt

Katalog / opt jest dostarczany przez standard FHS, ale w rzeczywistości nie jest używany we wszystkich dystrybucjach Linuksa, aw systemach BSD jest całkowicie nieobecny. Niemniej jednak coraz więcej programów jest pisanych z oczekiwaniem na domyślną instalację w nim.

Historycznie, /opt był używany w Linuksie w aplikacjach komercyjnych i wszelkiego rodzaju niewolnym oprogramowaniu. Obecnie jego celem jest hostowanie dużych, samodzielnych systemów oprogramowania, takich jak biblioteka Qt, KDE ze wszystkimi jego komponentami i aplikacjami, OpenOffice.org i tym podobne. Struktura katalogów powinna mieć postać /opt/pkg_name. Tak to wygląda na moim systemie (Archlinux):

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

Każdy z podkatalogów ma swoją wewnętrzną strukturę:

$ ls -1 / opt / * / opt / gnome: bin / lib / man / share / / opt / kde: bin / etc / include / lib / share / /opt/OpenOffice.org1.1.2: help / LICENSE LICENSE. program html / README README.html [e-mail chroniony] udział / [e-mail chroniony] THIRDPARTYLICENSEREADME.html użytkownik / / opt / qt: bin / doc / include / lib / mkspecs / rozmówki / wtyczki / szablony / tłumaczenia /

Przeznaczenie podkatalogów w /opt/pkg_name można łatwo odgadnąć przez analogię z /usr i /usr/local. Na przykład / opt / kde / bin dotyczy plików wykonywalnych systemu KDE i jego aplikacji, / opt / kde / etc dotyczy plików konfiguracyjnych, / opt / kde / include dotyczy plików nagłówkowych, / opt / kde / lib jest dla bibliotek, a /opt/kde/share - dla współdzielonych plików, w tym dokumentacji. KDE nie ma dokumentacji manualnej, ale jeśli jest dostępna, to (tak jak w przypadku Gnome - nie instalowałem, to wciągnął Gimp i podobne aplikacje Gtk) widać podkatalog /opt/pkg_name/man .

Widać, że struktura katalogów /opt odbiega od ustalonej historycznie (i wewnętrznie ugruntowanej POSIX-owej tradycji łączenia w katalogi komponentów tego samego typu - plików wykonywalnych, bibliotek itp. $ PATH, która zapewnia szybki dostęp do poleceń (które będą omówione w rozdziale 12) lub utworzyć specjalny katalog /opt/bin i umieścić w nim dowiązania symboliczne do wykonywalnych programów binarnych. rzeczywiście we wszystkich systemach BSD.Całkiem możliwe, że tak jest lepiej...

/ Oddział Var

Jak sama nazwa wskazuje, katalog / var jest przeznaczony do przechowywania zmiennych plików generowanych podczas normalnego życia różnych programów - pamięci podręcznej oprogramowania (na przykład przeglądarki), plików dziennika, buforowania wydruku i systemów pocztowych. skrzynki pocztowe, opisy uruchomionych procesów i tak dalej. W szczególności w katalogu / var umieszczane są tak zwane zrzuty - migawki stanu pamięci RAM, generowane podczas nieprawidłowego zamykania w celu zidentyfikowania przyczyn tego. Cechą charakterystyczną wszystkich tych komponentów jest ich zmienny charakter podczas sesji oraz fakt, że muszą one jednak zostać zachowane przy ponownym uruchomieniu systemu.

Wewnętrzna struktura / var różni się znacznie w zależności od systemu, dlatego nie będę się rozwodził nad szczegółami jej struktury. Zaznaczę tylko, że ten katalog jest logicznym miejscem do umieszczania komponentów wszelkiego rodzaju portopodobnych systemów zarządzania pakietami, jak to się dzieje np. w dystrybucji Archlinux, gdzie ma podkatalog /var/abs (abs - Archlinux system budowlany).

Katalog / mnt

Katalog / mnt jest przeznaczony do montowania tymczasowo używanych systemów plików, zwykle znajdujących się na nośniki wymienne... W ugruntowanym systemie jest zwykle pusty, a jego struktura nie jest w żaden sposób regulowana. Użytkownik może dowolnie tworzyć w nim podkatalogi dla określonych rodzajów mediów. Na przykład w moim systemie są to / mnt / cd, / mnt / dvd, / mnt / usb i / mnt / hd - w przypadku płyt CD, DVD, dysków flash i wymiennych dysków twardych.

We FreeBSD domyślnymi katalogami do montowania płyt CD i dyskietek są /cdrom i /floppy bezpośrednio w katalogu głównym. Co nie jest do końca zgodne ze standardem, ale na swój sposób jest logiczne - punkty montowania istniejących urządzeń (takich jak CD ROM) lub do niedawna (stacja dyskietek) w dowolnej maszynie są przenoszone do katalogu głównego.

/ Oddział w domu

Katalog / home służy do hostowania katalogów domowych użytkowników. Jego zawartość nie jest w żaden sposób regulowana, ale zazwyczaj wygląda jak /home/(nazwaużytkownika1,...,nazwaużytkownika#). Jednak w dużych systemach z wieloma użytkownikami ich katalogi domowe można pogrupować.

Katalog / home może zawierać katalogi domowe nie tylko rzeczywistych użytkowników, ale także niektórych użytkowników wirtualnych. Tak więc, jeśli maszyna jest używana jako serwer WWW lub ftp, zobaczysz odpowiednio podkatalogi, takie jak /home/www lub /home/ftp.

Oddział / tmp

Pozostaje mówić tylko o katalogu do przechowywania plików tymczasowych - / tmp. Podobnie jak / var komponenty są generowane przez różne programy w trakcie ich normalnego życia. Jednak w przeciwieństwie do /var, składniki /tmp nie powinny być utrzymywane poza bieżącą sesją. Co więcej, wszystkie przewodniki administracji systemu zalecają regularne (na przykład podczas ponownego uruchamiania komputera) lub okresowe czyszczenie tego katalogu. I dlatego jako /tmp wskazane jest montowanie systemów plików w pamięci RAM - tmpfs (w Linuksie) lub mfs (w FreeBSD). Oprócz tego, że zapewnia to wyczyszczenie jego zawartości po ponownym uruchomieniu komputera, przyczynia się to również do wydajności, na przykład kompilacji programów, których tymczasowe produkty nie są zapisywane na dysku, ale są umieszczane w wirtualnym katalogu, takim jak / tmp / obj.

W wielu systemach zobaczysz katalogi takie jak /usr/tmp i /var/tmp. Są to zazwyczaj dowiązania symboliczne do /tmp.

Strategia partycjonowania systemu plików

Na zakończenie rozmowy o hierarchii plików należy podkreślić, że tylko katalogi wymienione w akapicie Główny system plików... Wszystkie inne katalogi - /usr, /opt, /var, /tmp i oczywiście /home mogą reprezentować punkty montowania niezależnych systemów plików na oddzielnych nośnikach fizycznych lub ich partycjach.

Co więcej, w lokalna sieć katalogi te mogą znajdować się nawet na różnych komputerach. Na przykład jeden komputer działający jako serwer aplikacji może zawierać katalogi /usr i /opt w sieci, inny serwer plików zawierający wszystkie katalogi domowe użytkownika i tak dalej.

Pozostaje tylko zdecydować, które systemy plików należy odizolować od wspólnego drzewa plików i dlaczego to robić. Odpowiedź na te pytania w dużej mierze zależy od używanego systemu operacyjnego, aw przypadku Linuksa także od jego dystrybucji. Niemniej jednak można nakreślić ogólne zasady separacji systemów plików. Dlaczego powinniśmy pamiętać o opozycji z jednej strony niezmiennych i mutowalnych katalogów, z drugiej strony łatwych do odzyskania, trudnych do odzyskania i praktycznie nieodzyskiwalnych danych. Podejmijmy tę próbę w odniesieniu do pulpitu użytkownika - w przypadku serwera obliczenia będą znacząco inne.

Oczywiście główny system plików w katalogach /bin, /boot, /etc, /root, /sbin, zawierający łatwe do odzyskania z nośnika dystrybucyjnego i praktycznie niezmienione dane, powinien znajdować się na wydzielonej partycji dyskowej. W systemie Linux należy również dodać katalog / lib. Z drugiej strony, gdy używasz GRUB-a jako programu ładującego (niezależnie od systemu operacyjnego), zaleca się przeniesienie katalogu /boot na oddzielną partycję.

W starych źródłach o Linuksie można przeczytać o jeszcze jednym powodzie przydzielania partycji dla katalogu /boot i to na samym początku dysku: z powodu braku możliwości załadowania jądra z Lilo z numeru cylindra wyższego niż 1023. nowoczesne wersje programów ładujących, nie ma takich ograniczeń. Jednakże, jeśli tworzysz partycję dla /boot, sensowne jest ustawienie jej jako pierwszej na dysku i umieszczenie partycji wymiany bezpośrednio za nią: doda to pięć kopiejek do szybkości podczas wykonywania wymiany.

I jeszcze jedna rzecz z dziedziny historii: wymóg, aby partycja główna i partycja startowa były jak najbardziej podstawowymi, również został dawno usunięty. A te systemy plików mogą dobrze zmieścić się na partycjach logicznych w ramach partycji rozszerzonej.

Równie jasne jest, że mutowalne gałęzie systemu plików — /var i /tmp — muszą zostać przeniesione poza partycję główną. Co więcej, ten ostatni, jak już wielokrotnie powiedziano, ogólnie zaleca się umieszczać w systemie plików w pamięci RAM (tmpfs lub mfs). W przypadku, gdy katalog / var zawiera podkatalogi dla systemów zarządzania pakietami podobnych do portów, takich jak / var / abs, / var / cache / pacman / src i / var / cache / pacman / pkg w Archlinux, powinny one również utworzyć własny plik systemy.

Teraz katalog /usr, który zawiera komponenty systemu podstawowego (jak w BSD) lub większość aplikacji użytkownika (jak w większości dystrybucji Linuksa). Zawiera łatwe do odzyskania dane i nie bez powodu powinien być praktycznie niezmienny, dlatego oczywiście zasługuje na wyróżnienie w niezależnej sekcji. Ponadto wskazane jest wyizolowanie z jego składu z jednej strony podkatalogów /usr/X11R6 i /usr/local, z drugiej podkatalogi dla portopodobnych systemów zarządzania pakietami: /usr/ports, /usr/pkgsrc oraz /usr/pkg w systemach BSD, /usr/portages w Gentoo Linux i tak dalej. Ponadto należy oddzielić podkatalogi do umieszczania źródeł pobieranych z sieci podczas budowania portów - /usr/ports/distfiles, /usr/pkgsrc/disfiles, /usr/portages/distfiles i tym podobne.

W systemach BSD dodatkowo sensowne jest oddzielenie podkatalogów /usr/src i /usr/obj od katalogu /usr, które zawierają źródła komponentów bazowych (w tym jądro) oraz ich pośrednie produkty kompilacji, które są generowane przez make buildworld i tworzenie procedur buildkernel....

Wreszcie katalog / home, który zawiera nietrwałe i często niemożliwe do odzyskania dane, musi zostać bezbłędnie usunięty z katalogu głównego hierarchii plików. I zawsze staram się umieścić go w osobnym wycinku (w BSD) lub na partycji podstawowej (w Linuksie).

Proponowany schemat partycjonowania systemu plików może wydawać się zbyt skomplikowany. Gwarantuje jednak izolację danych łatwych do odzyskania, trudnych do odzyskania i nieodwracalnych, co ułatwia ponowną instalację systemu w przypadku awarii, a nawet migrację z systemu do systemu.

Jego dodatkowym plusem jest to, że dla poszczególnych gałęzi drzewa plików, w zależności od charakteru znajdujących się na nim danych, w Linuksie można wybrać optymalny fizycznie system plików. Na przykład dla partycji pod /boot nie ma sensu używać czegokolwiek innego niż Ext2fs. Ogólnie zaleca się sformatowanie partycji głównej za pomocą bezpiecznego, a jednocześnie najbardziej kompatybilnego Ext3fs. W przypadku katalogów z ogromną liczbą małych plików, takich jak /var/abs w Archlinux, /usr/portages w Gentoo, wskazane jest użycie ReiserFS: w końcu umiejętne operowanie małymi plikami jest jego profilem. A w katalogu /home, gdzie mogą pojawić się ogromne pliki multimedialne (a który sam w sobie jest zwykle bardzo duży), XFS może trafić do sądu (choć, jak pokazują pomiary, ReiserFS wygląda tu całkiem przyzwoicie). Takie środki mogą poprawić zarówno niezawodność przechowywania danych, jak i szybkość operacji na plikach.

Użytkownicy systemów operacyjnych BSD są związani z systemami plików typu FFS bez żadnej alternatywy. Mają jednak również pole manewru. Po pierwsze, poprzez zróżnicowanie rozmiaru bloku i fragmentu poszczególnych systemów plików, co przyczynia się albo do wydajności operacji dyskowych, albo do zaoszczędzenia miejsca na dysku. Po drugie, niektóre gałęzie drzewa plików (takie jak /tmp lub /usr/obj, wbrew zaleceniom, można bez obaw montować w trybie czysto asynchronicznym, zyskując procent lub dwa procent wydajności.

Ogólnie o standardach

Wśród praktykujących programistów panuje opinia, że ​​standardy w programowaniu wcale nie są potrzebne, ponieważ:

(1) początkowo są bez znaczenia, ponieważ ich autorzy nie piszą programów komputerowych;

(2) krępują inicjatywę programistów;

(3) programiści zawsze zgodzą się bez standardów.

Być może na tę opinię nie należało zwracać uwagi, gdyby nie dwie okoliczności:

(1) wyrażają ją praktycy, czyli właśnie ci, którzy „wydają oprogramowanie”;

(2) Powyższe rozumowanie autor tego artykułu odkrył w jednej z publikacji w Internecie, poświęconej standardowi dla języka programowania C, z którego stało się jasne, że taka opinia jest powszechna „na skalę międzynarodową”, a nie tylko wśród aroganckich rosyjskich „superprogramistów”.

Słowo „standard” zwykle kojarzy się z czymś materialnym (standardowe wymiary, standardowe napięcie elektryczne itp.), podczas gdy program komputerowy to obiekt niematerialny („Nowa niematerialna”), a może normy w sferze niematerialnej są naprawdę bezcelowe?

Istnieje jednak przykład obalający. Zestaw reguł pisowni dla języka rosyjskiego jest zasadniczo standardem, chociaż nie został zatwierdzony przez organy normalizacyjne. Ponadto, oprócz reguł (lub, jeśli wolisz, wymagań) pisowni, istnieją reguły syntaktyczne i, co najważniejsze, semantyka. To ostatnie dobrze ilustruje „dziecinne” pytanie: dlaczego kota nazywa się kotem? Jest dokładna odpowiedź na to pytanie: ponieważ nasi przodkowie tak się zgodzili; przodkowie Brytyjczyków zgodzili się nazwać tę samą bestię kotem, przodkami Niemców - kotkiem itp. Ogólnie rzecz biorąc, znaczenie, semantyka lub zasady interpretacji dowolnego słowa lub kombinacji słów są kwestią porozumienia.

Cel i „superzadanie” standardu POSIX

Jak sama nazwa wskazuje, POSIX (Portable Operating System Interface) jest standardem interfejsu (interfejsu) między systemem operacyjnym a aplikacją. Minęły czasy, kiedy programiści pisali programy na „gołą” maszynę (implementując własne pakiety programów wejścia/wyjścia, funkcje trygonometryczne itp.). Tekst POSIX wielokrotnie podkreśla, że ​​standard nie nakłada żadnych wymagań na szczegóły implementacji systemu operacyjnego; można go postrzegać jako zestaw umów między programistami aplikacji a twórcami systemów operacyjnych. Tym samym (ponownie wbrew dość rozpowszechnionej opinii) POSIX jest przedmiotem zainteresowania nie tylko twórców systemów operacyjnych, ale przede wszystkim znacznie szerszej kategorii programistów – aplikowanych.

Potrzebę takiego standardu dostrzeżono już w latach 80., kiedy systemy operacyjne UNIX stały się powszechne. Okazało się, że choć system ten był pomyślany jako system zunifikowany, różnice między jego konkretnymi implementacjami powodowały, że programy użytkowe napisane dla jednego systemu nie zawsze mogły być wykonywane w innym. To właśnie ten problem, znany jako problem z przenośnością oprogramowania, ma na celu rozwiązanie POSIX. Pierwsze wydanie standardu zostało wydane w 1988 roku (jest tłumaczenie, patrz), w którym cała różnorodność zagadnień związanych z przenośnością programu została podzielona na dwie części: (1) interfejs aplikacji, (2) interpreter poleceń i narzędzia (interfejs użytkownika ); te części są nazywane odpowiednio POSIX.1 i POSIX.2.

Wyjaśnijmy, że w tym artykule omówimy tylko standard interfejsu programu użytkowego, POSIX.1, którego drugie (i ostatnie do tej pory) wydanie zostało zatwierdzone 12 lipca 1996 r.

W części informacyjnej standardu podkreśla się również, że POSIX nie jest opisem interfejsu jakiegoś „idealnego” systemu operacyjnego, ale wynikiem uogólnienia i usystematyzowania doświadczeń zdobytych przy tworzeniu systemów operacyjnych UNIX. Ponadto POSIX nie może służyć jako przewodnik lub przewodnik do nauki na systemach operacyjnych, chociaż część informacyjna zawiera zalecenia dla programistów i fragmenty programów.

Norma wprost stwierdza, że ​​nie da się stworzyć pełnoprawnego systemu operacyjnego, skupiając się wyłącznie na opisanych w nim funkcjach interfejsu. (W szczególności POSIX.1 nie rozwiązuje problemów, takich jak sieć i powiązane funkcje interfejsu lub interfejs graficzny.) Jednak koszty finansowe braku mobilności oprogramowania i wynikająca z tego potrzeba ujednolicenia interfejsu są tak duże, że większość dostawców woli mieć przynajmniej część standard niż nie mieć. Z tego powodu wielu programistów koncentruje się na POSIX. Pozwala to, jeśli nie całkowicie wyeliminować unieruchomienie programów, to przynajmniej znacząco ograniczyć nieruchomą część programu.

O semantyce

Jak omówiono wcześniej, POSIX może być postrzegany jako zestaw umów między programistą systemu operacyjnego a programistą aplikacji. „Umowa” oznacza przede wszystkim tę samą interpretację (semantykę) słów i wyrażeń. Poniżej znajdują się przykłady ilustrujące trudność w osiągnięciu „porozumienia”.

Jak przekazać znaczenie w tłumaczeniu

Przede wszystkim należy pamiętać, że standard POSIX jest napisany w języku angielskim, co ze swej natury prowokuje do niejednoznaczności (np. to samo słowo może być rzeczownikiem, przymiotnikiem i czasownikiem), a na nich czają się „pułapki semantyczne”. prawie na każdej stronie. Dobrą ilustracją tego jest przykład z fikcji. Jedno z najsłynniejszych dzieł Oscara Wilde'a, który znakomicie wykorzystał tę funkcję języka angielskiego, - Znaczenie bycia gorliwym - znane w języku rosyjskim jako "Znaczenie bycia gorliwym". ale angielskie imie ma drugie znaczenie: Earnest (poważne) to nazwisko jednego z bohaterów, a imię można by przetłumaczyć inaczej: „Jak ważne jest, aby być Ernst”. Istnieje rosyjskie nazwisko Serebryany, a gdyby istniało nazwisko Poważny, tłumaczenie byłoby idealnie dokładne, z przeniesieniem obu znaczeń.

Podobnie jest z nazwą samego standardu: Portable Operating System Interface. Przymiotnik Przenośny (mobilny) odnosi się zarówno do systemu operacyjnego, jak i aplikacji, ale nie można go wyrazić tak krótko w języku rosyjskim, można go przetłumaczyć jako „Interfejs mobilnego systemu operacyjnego” lub „Interfejs systemu operacyjnego, który zapewnia mobilność programów aplikacyjnych”. Druga opcja lepiej oddaje intencje twórców standardu, ale jednocześnie traci pierwsze znaczenie (podczas tłumaczenia zachowano bardziej znaną pierwszą opcję).

Semantyka słowa „standard”

Główny tekst normy poprzedzony jest preambułą wyjaśniającą znaczenie słów IEEE Standards2. Jak wynika z tych wyjaśnień, istnieją co najmniej trzy semantyczne różnice w stosunku do rosyjskojęzycznego terminu GOST:

(1) Intuicyjnie uważa się, że GOST ma moc prawa, którego naruszenie jest ścigane; POSIX to zestaw wymagań, których przestrzeganie jest całkowicie dobrowolne.

(2) GOST jest ważny do momentu anulowania (wielu prawdopodobnie słyszało wyrażenie „GOST nie został anulowany”); preambuła do POSIX mówi, że jeśli standard nie był zmieniany przez 5 lat, oznacza to, że rozważane w nim kwestie prawdopodobnie straciły na aktualności i można go uznać za anulowany automatycznie;

(3) GOST jest anonimowy; część wprowadzająca POSIX zawiera listę osób, które brały udział w opracowaniu tego standardu, a także podaje adres, na który można kierować prośby o tłumaczenie; stwierdza również, że odpowiedź na każde żądanie podlega procedurze zatwierdzenia (innymi słowy, autorzy standardu uzgadniają między sobą przed udzieleniem odpowiedzi).

Dlatego tłumaczenie nawet tak znanego słowa jak Standard na słowo „standard” wymaga komentarza.

Semantyka słów „powinien”, „nieokreślony”, „nieokreślony”, „zdefiniowany wdrożeniowy”

Sekcja 2 normy nosi nazwę Terminologia i wymagania ogólne. Zawiera definicje nie tylko specjalnych terminów (takich jak „proces” czy „semafor”), ale także takich pozornie oczywistych słów, jak „powinien” czy „może”. Ponieważ POSIX.1 jest standardem interfejsu, jego wymagania dotyczą zarówno systemu operacyjnego, jak i aplikacji. Wyraźny wymóg wyraża się słowem „shall”, na przykład: „Jeśli się powiedzie, link () zwróci zero”. W tym przykładzie mówimy o wymaganiu systemu operacyjnego: funkcja link() musi być zaimplementowana tak, aby w przypadku powodzenia zwracała zero.

Terminy „nieokreślony” i „nieokreślony” wyrażają tę samą ideę, że norma pozwala na swobodę wyboru, ale znaczenie tych terminów jest inne. Termin „nieokreślony” oznacza, że ​​mówimy o pewnych poprawnych (działaniach, konstrukcjach programu itp.), a termin „nieokreślony” - o nieprawidłowym (błędnym). Część informacyjna normy zawiera następujące wyjaśnienie.

Termin „nieokreślony” oznacza, że ​​różne opcje (wyniki, rezultaty wywołania funkcji itp.) są uznawane za znane, a standard dopuszcza każdą z nich; w konkretnej implementacji systemu operacyjnego można wybrać dowolny i taki system jest uważany za zgodny ze standardem. Program użytkowy (ściśle zgodny ze standardem) musi być napisany w taki sposób, aby działał poprawnie w każdym wariancie; jako taki, termin domyślnie wyraża wymaganie dla programu użytkowego.

Podajmy przykład: „Funkcja readdir() powinna zwrócić wskaźnik do struktury związanej z kolejnym elementem katalogu. To, czy elementy katalogu o nazwach „punkt” i „od punktu do punktu” są zwracane, nie jest określone przez normę. W tym przykładzie istnieją cztery możliwe wyniki, a aplikacja wymaga, aby była zaprojektowana dla dowolnego z nich.

Inny przykład: „Jeśli funkcja sigwait() instruująca oczekiwanie na sygnał o określonym numerze jest wywoływana w kilku wątkach kontrolnych, to gdy sygnał nadejdzie w nie więcej niż jednym z nich, sigwait() musi zwrócić. W jakim rodzaju przepływu sterowania to się stanie, norma nie określa. ” W tym przykładzie może być o wiele więcej możliwych wyników, ale wszystkie one są również znane, a aplikacja musi działać poprawnie dla każdego wyniku.

Termin „nieokreślony” oznacza, że ​​nawet wiele wyników nie jest znanych, każdy wynik jest możliwy, nawet katastrofalny (na przykład awaria systemu, utrata danych itp.). Zasadniczo termin ten domyślnie wyraża wymóg, aby aplikacja nie używała odpowiednich danych lub konstrukcji. Na przykład: „Jeśli argument dirp do readdir() nie odnosi się do aktualnie otwartego katalogu, wynik jest niezdefiniowany”.

Ten przykład wymaga, aby aplikacja zastąpiła argument funkcji readdir() tylko odwołaniem do katalogu otwartego; naruszenie tego wymogu może prowadzić do katastrofalnych konsekwencji, a odpowiedzialność za to ponosi programista aplikacji.

Oto kolejny przykład: „Jeśli się powiedzie, funkcja read() powinna zwrócić liczbę całkowitą reprezentującą liczbę faktycznie odczytanych bajtów. W przeciwnym razie funkcja musi przypisać kod błędu do errno i zwrócić -1, a zawartość bufora wskazywanego przez buf jest niezdefiniowana.”

Norma zabrania wykorzystania danych z bufora w programie użytkowym w przypadku wystąpienia błędu w funkcji read(), a konsekwencje naruszenia tego wymogu obciążają programistę aplikacji.

Znaczenie terminu „zdefiniowana implementacja” różni się od intuicyjnego. Oczywiście w konkretnym systemie operacyjnym nie może być „nieokreślonego” lub „nieokreślonego” wyniku, jakiś konkretny wynik zostanie uzyskany bezbłędnie. Termin „zdefiniowany przez implementację” wyraża wymagania normy dotyczące dokumentacji systemu operacyjnego: wynik musi być nie tylko określony (programista systemu operacyjnego i tak będzie musiał to zrobić), ale także wyraźnie odzwierciedlony w dokumentacji systemu.

Semantyka domyślna

Żaden dokument regulacyjny nie może objąć całej różnorodności przypadków, które mogą wystąpić w praktyce, dlatego nieuchronnie o czymś się milczy3. Na przykład opis funkcji może mówić, że jej argument może przyjmować wartości z pewnego zakresu, ale nic nie jest powiedziane o tym, jaki będzie wynik, jeśli argument nie mieści się w tym zakresie. Oczywiście, aby uniknąć nieporozumień, konieczna jest jednolita domyślna semantyka. W części informacyjnej standardu znajduje się ciekawa fraza: „ogólnie przyjęta semantyka niewykonania zobowiązania jest zabroniona”. To stwierdzenie jest sprzeczne ze znanym od dziesięciu lat hasłem „wszystko jest dozwolone, co nie jest wyraźnie zabronione”. Najwyraźniej jest tak zakorzeniony w umysłach obywateli, że wielu, nawet programistów, nie zgadza się z przytoczonym stwierdzeniem standardu. Tymczasem, jeśli użycie jakiejkolwiek konstrukcji jest wyraźnie niedozwolone i nie wynika z opisu, to każdy praktykujący programista zdaje sobie sprawę, że używanie go jest ryzykowne, a jeśli to nie działa, nie przychodzi mu do głowy wysuwanie roszczenia.

Procesy i przepływy kontroli

Oba te terminy wyrażają ideę wykonania równoległego. System operacyjny UNIX został pierwotnie pomyślany jako wieloużytkownikowy, a programy uruchamiane przez różnych użytkowników muszą być niezawodnie odizolowane od siebie, aby przypadkowo nie zniekształcić „obcych” danych. Izolację tę zapewnia fakt, że program użytkownika jest wykonywany w procesie, który rozwija się we własnej wirtualnej przestrzeni adresowej. Nawet jeśli program zawiera dane globalne, to po uruchomieniu w różnych procesach zostaną one automatycznie „rozdzielone” na różne przestrzenie adresowe.

Jednak mechanizm procesu nie jest w pełni zadowalający przy programowaniu zadań czasu rzeczywistego. Aplikacja czasu rzeczywistego (działająca w imieniu tego samego użytkownika) często może być naturalnie reprezentowana jako współbieżnie wykonywane elementy zwane wątkami. Ich najważniejszą różnicą w stosunku do procesów jest to, że wszystkie przepływy sterowania rozwijają się w jednej przestrzeni adresowej; zapewnia to szybki dostęp do danych globalnych, ale jednocześnie istnieje ryzyko ich niezamierzonego zniekształcenia, a żeby do tego nie doszło, konieczne jest zachowanie pewnej dyscypliny programistycznej. Odpowiednie zalecenia zawarte są w części informacyjnej normy.

Należy podkreślić, że idea wielowątkowości jest realizowana w wielu systemach operacyjnych czasu rzeczywistego i realizowana na różne sposoby w tym sensie, że każdy wątek kontrolny posiada inny zestaw atrybutów i funkcji interfejsu; czasami zamiast wątku używany jest termin zadanie. Aby uniknąć nieporozumień, standard podkreśla, że ​​dotyczy wyłącznie wątków POSIX i że nazwy odpowiednich funkcji interfejsu są poprzedzone prefiksem pthread_ (na przykład pthread_create(), pthread_join() itp.).

Zgodność z normą. Semantyka słowa „dopasowanie”

Intuicyjnie uważa się, że jeśli dwa przedmioty są wykonane zgodnie z tym samym standardem, to gwarantuje się, że „pasują” ze sobą i będą współpracować w parach; to jest właśnie cel wprowadzenia standardu interfejsu (interfejsu). Ponieważ POSIX jest standardem interfejsu, możemy mówić o zgodności ze standardem zarówno systemu operacyjnego, jak i aplikacji.

Standard POSIX.1 zawiera kilkaset (jeśli nie tysiące) wymagań; uważa się za oczywiste, że jeśli przynajmniej jeden z nich nie jest spełniony, to system (lub program użytkowy) nie spełnia normy. Jednocześnie napisano do tej pory tak wiele systemów operacyjnych i programów użytkowych klasy UNIX, że wymaganie pełnej zgodności we wskazanym sensie jest mało uzasadnione. Trudności w opracowaniu tego rodzaju międzynarodowego standardu potęguje istnienie różnych języków narodowych. Nawet jeśli zapomnimy o programach użytkowych przeznaczonych do przetwarzania tekstów w językach narodowych, to praktycznie każdy program użytkowy musi generować jakiś rodzaj komunikatów diagnostycznych i/lub odbierać teksty wprowadzane przez operatora.

• ścisła zgodność ze standardem POSIX.1;
• zgodność z międzynarodową wersją POSIX.1;
• zgodność z krajową wersją POSIX.1;
• Zgodność z POSIX.1 z rozszerzeniami.

Po drugie, wiele udogodnień interfejsu jest opcjonalnych; Standard wymaga, aby opcjonalne funkcje interfejsu albo zachowywały się zgodnie z zaleceniami standardu, albo zawsze zwracały specjalny kod błędu, ENOSYS (co oznacza, że ​​funkcja nie jest zaimplementowana). Opcje są podzielone na kilka grup, z których każda odpowiada pewnej stałej konfiguracyjnej, która jest zadeklarowana (przez instrukcję #define) w odpowiednim pliku nagłówkowym; umożliwia to sprawdzenie, czy funkcja została zaimplementowana w fazie kompilacji.

Opisana metoda osiągania mobilności nie została wymyślona przez autorów POSIX, ale od dawna jest stosowana w praktyce; w wielu systemach operacyjnych stałe konfiguracyjne służą do identyfikacji samego systemu lub jego wersji. I tutaj standard nie oferuje niczego fundamentalnie nowego, a jedynie systematyzuje dotychczasową praktykę.

Przedmioty normalizacji i struktura normy

Krótko mówiąc, obiekty standaryzacji POSIX.1 to nazwy i semantyka. Mówiąc dokładniej, mówimy o następujących.

• Nazwy funkcji interfejsu. 357 funkcji jest ustandaryzowanych, z 107 funkcjami zaczerpniętymi ze standardowych bibliotek C (matematyczne, przetwarzanie łańcuchów, wejście/wyjście itp.); te funkcje są uważane za część standardu POSIX.1, ale są Pełny opis zawarte w standardzie dla języka programowania C.
• Nazwy typów danych systemowych. Te nazwy mają przyrostek _t.
• Nazwy plików nagłówkowych, a także minimalny skład tych plików.
• Ogólnosystemowe nazwy zmiennych globalnych (na przykład errno).
• Symboliczne nazwy kodów błędów, które można ustawić podczas wykonywania funkcji. Nazwy te zaczynają się od litery E (EPERM, ENOTEMPTY itp.).
• Nazwy stałych konfiguracji. Te nazwy są poprzedzone _POSIX_.
• Nazwy symboliczne numerów sygnałów; te nazwy są poprzedzone prefiksem SIG. Oprócz 20 „tradycyjnych” sygnałów (SIGABRT, SIGALRM itp.) standaryzowane są sygnały czasu rzeczywistego, których liczby muszą zajmować pewien ciągły zakres od SIGRTMIN do SIGRTMAX włącznie, zawierający co najmniej liczby RTSIG_MAX.
• Nazwy symboliczne odpowiadające wartościom poszczególnych argumentów niektórych funkcji (na przykład argument cmd funkcji fcntl() może przyjmować wartości F_DUPFD, F_GETFD, F_GETLK itp.).
• Nazwy makr, stałe, flagi bitowe, zmienne środowiskowe.

Ogólnie rzecz biorąc, standard składa się z dwóch dużych części o w przybliżeniu tej samej objętości. Pierwsza połowa - część normatywna - zawiera wymagania i zalecenia normy (18 rozdziałów), druga - część informacyjna - zawiera załączniki, które zawierają spis odniesień, komentarzy i wyjaśnień do części normatywnej, skład nagłówka pliki, przykład profilu („projekcja”) normy (dla Danii), charakterystyka i metodologia pomiaru wydajności najważniejszych funkcji, a także opis dodatkowych funkcji interfejsu do pracy z plikami w czasie rzeczywistym; oczekuje się, że w przyszłych wydaniach normy funkcje te zostaną włączone do części normatywnej.

Pasek boczny „Podsumowania klauzul standardu” daje wyobrażenie o tym, jakie rodzaje usług systemu operacyjnego są objęte standardem.

Wniosek

Główną treścią standardu POSIX jest semantyka funkcji interfejsu. Standaryzacja semantyki sama w sobie nie jest łatwym biznesem (każdy wie, jak trudno jest dojść do porozumienia nawet dla dwóch osób), a trudności potęguje fakt, że programowaniem zajmuje się obecnie wiele osób. Na przykład paradygmat współbieżności wyrażany jest w terminach „proces”, „zadanie” i „przepływ sterowania”, ale z praktycznego punktu widzenia programowania „zadanie” w systemie operacyjnym IBM OS/360 i system operacyjny czasu VxWorks to nie to samo.a także. Innym przykładem są semafory. Semafory są binarne, całkowite („z licznikiem”) i wzajemne wykluczanie (które, notabene, programiści nazywają między sobą „muteksami”, spontanicznie starając się uniknąć nieporozumień). A semafory liczb całkowitych, na przykład w systemie operacyjnym VxWorks, wcale nie są takie same jak semafory POSIX.

Twórcy standardu POSIX, doskonale zdając sobie sprawę z tego, jak trudno jest wyzbyć się przyzwyczajeń (które nazywają „ustaloną praktyką”), deklarują, że skompilowali spójny i minimalny system funkcji interfejsu obejmujący większość usług tradycyjnie dostarczonych przez system operacyjny, szczegółowo opisali dokładną semantykę tych funkcji i zaprosili wszystkich do korzystania z nich w swoich opracowaniach4.

Czytając normę można czasem odnieść wrażenie, że niektóre sformułowania miały jeden cel: nie usuwać z kategorii spełniających normę jakichkolwiek aplikacji czy systemów operacyjnych. Taki cel został rzeczywiście postawiony i wyraźnie sformułowany we wstępie: standard powinien w jak największym stopniu uwzględniać panującą praktykę. Jednak głównym celem jest nadal zapewnienie mobilności programów aplikacyjnych.

O autorze

Siergiej Romaniuk - starszy pracownik naukowy w Research Institute for System Research, szef grupy tłumaczy standardowych POSIX. Można się z nim skontaktować poprzez e-mail pod adresem: [e-mail chroniony]

1 Należy dodać, że prace nad standardem trwają od wielu lat; identyfikowane są nowe zagadnienia, które są albo włączane do jednej z istniejących części, albo sformalizowane jako odrębna część, którą można następnie anulować. Stało się tak na przykład z obiektami front-end w czasie rzeczywistym, które początkowo zostały zadeklarowane jako POSIX.4, a później zawarte w POSIX.1.

2 IEEE to organizacja, która opracowała standard POSIX.

3 Tutaj „domyślny” oznacza cichy, a nie domyślny; nie mówimy o niektórych wartościach dorozumianych, które są faktycznie deklarowane, ale o całkowitym braku odniesień.

4 Rosyjskie tłumaczenie normy zostanie opublikowane na początku 2000 roku.

Literatura

Międzynarodowa norma ISO / IEC 9945-1 (ANSI / IEEE Std 1003.1) Wydanie drugie. 1996-07-12. Technologia informacyjna — przenośny interfejs systemu operacyjnego (POSIX) — część 1: Interfejs programu aplikacji systemu (API).

MI Belyakov, YuI Rabover, A.L. Fridman. Mobilny system operacyjny. Informator. Moskwa, „Radio i komunikacja”, 1991.

ISO/IEC 9899: 1990, Języki programowania - C.

Sekcja 1	- Wstęp
Sekcja 2	- Terminologia i definicje
Sekcja 3	- Funkcje do zarządzania procesami (tworzenie, zastępowanie obrazu, uzupełnianie) i sygnałami (zarządzanie maskami, reagowanie na sygnały)
Sekcja 4	- Identyfikacja (procesy, użytkownicy, system, terminal), odpytywanie czasu poświęconego na wykonanie procesu, odpytywanie zmiennych środowiskowych.
Sekcja 5	- Zarządzanie plikami i katalogami
Sekcja 6	- Funkcje wejścia i wyjścia
Sekcja 7	- Funkcje sterowania terminalem
Sekcja 8	- Funkcje zapożyczone ze standardu języka C
Sekcja 9	- Dostęp do baz danych użytkowników i grup użytkowników
Sekcja 10	- Formaty danych do archiwizacji i wymiany (tar i cpio)
Sekcja 11	- Ułatwienia synchronizacji: semafory, muteksy i zmienne warunkowe
Sekcja 12	- Funkcje zarządzania pamięcią: przypinanie i odpinanie przestrzeni adresowej procesu, mapowanie plików do pamięci, ochrona pamięci, pamięć współdzielona
Sekcja 13	- Funkcje związane z harmonogramowaniem procesów i przepływami kontrolnymi
Sekcja 14	- Zarządzanie zegarem i timerem
Sekcja 15	- Zarządzanie kolejką wiadomości
Sekcja 16	- Podstawowe funkcje związane z przepływami sterowania
Sekcja 17	- Dane specyficzne dla wątku
Sekcja 18	- Środki niszczenia przepływów kontrolnych

Temat: Systemy operacyjne.
Pytanie: nr 8

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

Zasady budowy systemu operacyjnego:

1.) Zasada modułowości- moduł jest ogólnie rozumiany jako kompletny funkcjonalnie element systemu, wykonany zgodnie z przyjętymi interfejsami międzymodułowymi. Moduł z definicji zakłada możliwość łatwego zastąpienia go innym, jeśli dostępne są określone interfejsy. W dużej mierze o podziale systemu na moduły decyduje zastosowana metoda projektowania systemu operacyjnego (oddolna lub odwrotnie).

Moduły uprzywilejowane, ponownie wchodzące i ponownie wchodzące mają szczególne znaczenie podczas tworzenia systemu operacyjnego (ponowne uprawnienie oznacza dosłownie ponowne uprawnienie; specjalny termin oznaczający kondycję programu; właściwość programu do prawidłowego wykonania, gdy występuje cykliczne (zwracane) wywołanie z przerwania).

Największy efekt zastosowania tej zasady można osiągnąć w przypadku jednoczesnego rozszerzenia tej zasady na system operacyjny, programy użytkowe i sprzęt.

2.) Zasada selektywności funkcjonalnej- pewna część ważnych modułów jest przydzielona w systemie operacyjnym, które muszą być stale w pamięci RAM, aby zapewnić bardziej wydajną organizację procesu obliczeniowego. Ta część nazywa się jądrem w systemie operacyjnym, ponieważ jest podstawą systemu. Przy tworzeniu składu rdzenia należy wziąć pod uwagę dwa sprzeczne wymagania. Z jednej strony najczęściej używane moduły systemowe powinny być zawarte w jądrze, z drugiej ilość modułów powinna być taka, aby ilość pamięci zajmowanej przez jądro nie była zbyt duża. Oprócz modułów oprogramowania, które tworzą jądro i są na stałe umieszczone w pamięci RAM, może istnieć wiele innych modułów oprogramowania systemowego, które są nazywane tranzyt. Tranzyt moduły oprogramowaniaładowane do pamięci RAM tylko wtedy, gdy jest to konieczne i pod nieobecność wolna przestrzeń można zastąpić innymi modułami tranzytowymi.

3.) Zasada generowania systemu operacyjnego: istota zasady polega na zorganizowaniu (wyborze) takiej metody wstępnej prezentacji programu centralnego systemu sterującego systemu operacyjnego (jądra i głównych komponentów na stałe rezydujących w pamięci RAM), co umożliwiło dostosowanie tej części nadzorczej systemu w oparciu o specyficzną konfigurację konkretnego kompleksu obliczeniowego oraz zakres zadań do rozwiązania. Ta procedura jest rzadko przeprowadzana przed wystarczająco długim okresem działania systemu operacyjnego. Proces generowania odbywa się za pomocą specjalnego programu generatora i odpowiedniego języka wejściowego dla tego programu, co pozwala na opisanie możliwości oprogramowania systemu oraz konfigurację maszyny. Wynikiem generacji jest pełna wersja system operacyjny. Wygenerowana wersja systemu operacyjnego to zbiór systemowych zestawów modułów i danych.

4.) Zasada redundancji funkcjonalnej: Zasada ta uwzględnia możliwość wykonywania tej samej pracy różnymi środkami. System operacyjny może zawierać kilka rodzajów monitorów (moduły nadzorcze, które kontrolują ten lub inny rodzaj zasobów), różne sposoby organizowania komunikacji między procesami obliczeniowymi. Obecność kilku rodzajów monitorów, kilku systemów zarządzania plikami pozwala użytkownikom szybko i najbardziej adekwatnie dostosować system operacyjny do określonej konfiguracji systemu komputerowego, aby zapewnić najbardziej wydajne ładowanie sprzętu przy rozwiązywaniu określonej klasy problemów, aby uzyskać maksimum wydajność przy rozwiązywaniu danej klasy problemów.

5.) Zasada wirtualizacji: budowa wirtualnych zasobów, ich dystrybucja i wykorzystanie są obecnie wykorzystywane w prawie każdym systemie operacyjnym. Zasada ta pozwala na przedstawienie struktury systemu w postaci określonego zestawu planistów procesów i alokatorów zasobów (monitorów) oraz wykorzystanie jednego scentralizowanego schematu alokacji zasobów.

Najbardziej naturalnym i kompletnym przejawem koncepcji wirtualności jest koncepcja maszyna wirtualna ... Dostarczona użytkownikowi maszyna wirtualna odtwarza architekturę maszyny rzeczywistej, ale elementy architektoniczne w tej reprezentacji mają nowe lub ulepszone cechy, które z reguły ułatwiają pracę z systemem. Charakterystyka może być dowolna, ale najczęściej użytkownicy chcą mieć własną „idealną” maszynę pod względem cech architektonicznych w następującym składzie:

- pamięć wirtualna o praktycznie nieograniczonej objętości, jednolita pod względem logiki działania.

- dowolna liczba procesorów wirtualnych zdolnych do równoległej pracy i interakcji podczas pracy.

- dowolna liczba zewnętrznych urządzeń wirtualnych zdolnych do pracy z pamięcią maszyny wirtualnej równolegle lub sekwencyjnie, asynchronicznie lub synchronicznie w odniesieniu do działania jednego lub drugiego procesora wirtualnego, który inicjuje działanie tych urządzeń.

Jednym z aspektów wirtualizacji jest organizacja możliwości uruchamiania w danym systemie operacyjnym aplikacji opracowanych dla innego systemu operacyjnego. Innymi słowy, mówimy o zorganizowaniu kilku środowisk operacyjnych.

6.) Zasada niezależności programów od urządzeń zewnętrznych: zasada ta jest obecnie wdrożona w przeważającej większości systemów operacyjnych ogólnego przeznaczenia. Po raz pierwszy zasada ta została najbardziej konsekwentnie zaimplementowana w systemie operacyjnym UNIX. Jest również zaimplementowany w większości nowoczesnych systemów operacyjnych PC. Zasada ta polega na tym, że łączenie programów z określonymi urządzeniami odbywa się nie na poziomie emisji programu, ale w okresie planowania jego realizacji. Dzięki temu ponowna kompilacja nie jest wymagana, gdy program działa na nowym urządzeniu, na którym znajdują się dane.

7.) Zasada kompatybilności: jednym z aspektów kompatybilności jest zdolność systemu operacyjnego do uruchamiania programów napisanych dla innego systemu operacyjnego lub dla wcześniejszych wersji tego systemu operacyjnego, a także dla innej platformy sprzętowej. Konieczne jest oddzielenie pytań zgodność binarna oraz zgodność źródła Aplikacje.

Kompatybilność binarną osiąga się, gdy można pobrać program wykonywalny i uruchomić go w innym systemie operacyjnym. Wymaga to kompatybilności na poziomie instrukcji procesora i kompatybilności na poziomie wywołań systemowych, a nawet na poziomie wywołań bibliotecznych, jeśli są one połączone dynamicznie.

Kompatybilność źródeł wymaga odpowiedniego translatora w oprogramowaniu systemowym, a także kompatybilności bibliotek i wywołań systemowych. W takim przypadku konieczne jest przekompilowanie istniejących tekstów źródłowych do nowego modułu wykonywalnego.

O wiele trudniej jest osiągnąć binarną kompatybilność między procesorami opartymi na różnych architekturach. Aby jeden komputer mógł wykonywać programy innego (na przykład program dla komputera PC, taki jak IBM PC, jest pożądany do uruchomienia na komputerze PC, takim jak Apple Macintosh), ten komputer musi działać z instrukcjami maszynowymi, których początkowo nie obsługuje Rozumiesz. W takim przypadku musi wykonać procesor 680x0 (lub PowerPC) kod binarny przeznaczony dla procesora i80x86. Procesor 80x86 ma własny dekoder instrukcji, rejestry i architekturę wewnętrzną. Procesor 680x0 nie rozumie binarnych 80x86, więc musi wybrać każde polecenie, zdekodować je, aby określić, czy

co ma zrobić, a następnie wykonać równoważny podprogram napisany dla 680 × 0.

Jednym ze sposobów zapewnienia kompatybilności oprogramowania i interfejsów użytkownika jest zgodność ze standardami POSIX, których zastosowanie pozwala na tworzenie programów w stylu UNIX, które można łatwo przenosić później z jednego systemu do drugiego.

8.) Zasada otwartości i skalowalności: Otwarty system operacyjny jest dostępny do analizy zarówno przez użytkowników, jak i specjalistów systemowych obsługujących system obliczeniowy. Rozszerzalny (modyfikowalny, rozwijany) system operacyjny pozwala nie tylko korzystać z możliwości generowania, ale także wprowadzać do jego struktury nowe moduły, ulepszać już istniejące itp. Innymi słowy, powinno być możliwe łatwe wprowadzanie niezbędnych uzupełnień i zmian bez naruszania integralności systemu. Podejście klient-serwer do strukturyzowania systemu operacyjnego z wykorzystaniem technologii mikrojądrowej zapewnia doskonałe możliwości rozbudowy. Zgodnie z tym podejściem system operacyjny jest zbudowany jako zestaw uprzywilejowanych programów sterujących i zestaw nieuprzywilejowanych usług (serwerów). Główna część systemu operacyjnego pozostaje niezmieniona, a jednocześnie można dodawać nowe serwery lub ulepszać stare. Ta zasada jest czasami interpretowana jako możliwość rozbudowy systemu.

9.) Zasada mobilności: system operacyjny musi być stosunkowo łatwy do przenoszenia

Łączenie z jednego typu procesora do innego typu procesora oraz z platformy sprzętowej jednego typu, która obejmuje, wraz z rodzajem procesora i sposobem organizacji całego sprzętu komputerowego (architektura systemu komputerowego), z innym rodzajem platformy sprzętowej. Zauważ, że zasada przenoszenia jest bardzo zbliżona do zasady kompatybilności, chociaż nie są tym samym. Pisanie przenośnego systemu operacyjnego jest jak pisanie dowolnego przenośnego kodu, ale jest kilka rzeczy do naśladowania. zasady:

- większość systemu operacyjnego musi być wykonana w języku, który jest dostępny we wszystkich systemach, na które planuje się go później przenieść. Oznacza to przede wszystkim, że system operacyjny musi być napisany w języku wysoki poziom, najlepiej ustandaryzowane, na przykład w C. Program napisany w asemblerze nie jest ogólnie przenośny.

- ważne jest, aby zminimalizować lub, jeśli to możliwe, wykluczyć te części kodu, które bezpośrednio oddziałują ze sprzętem. Zależność sprzętowa może przybierać różne formy. Niektóre oczywiste formy zależności obejmują bezpośrednią manipulację rejestrami i innym sprzętem. Wreszcie, jeśli nie można całkowicie wykluczyć kodu zależnego od sprzętu, należy go wyizolować w kilku dobrze zlokalizowanych modułach. Kod zależny od sprzętu nie musi być rozpowszechniany w całym systemie. Na przykład można ukryć strukturę zależną od sprzętu w programowalnym abstrakcyjnym typie danych.

Wprowadzenie standardów POSIX miało na celu zapewnienie przenośności tworzonego oprogramowania.

10.) Zasada bezpieczeństwa obliczeniowego: Zapewnienie bezpieczeństwa obliczeniowego jest pożądaną cechą każdego systemu wieloużytkownikowego. Reguły bezpieczeństwa definiują właściwości, takie jak ochrona zasobów jednego użytkownika przed innymi i ustawianie limitów zasobów, aby uniemożliwić jednemu użytkownikowi przejęcie wszystkich zasobów systemowych, takich jak pamięć.

Zapewnienie ochrony informacji przed nieautoryzowanym dostępem jest obowiązkową funkcją sieciowych systemów operacyjnych.

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

CoPOSIX: niezależny od platformy interfejs systemowy dla środowiska komputerowego POSIX (Portable Operating System Interface for Computer Environments) to standard IEEE (Institute of Electrical and Electronics Engineers), który opisuje interfejsy systemowe dla otwartych systemów operacyjnych, w tym powłoki, narzędzia i zestawy narzędzi. Ponadto POSIX standaryzuje zadania bezpieczeństwa, zadania czasu rzeczywistego, procesy administracyjne, funkcje sieciowe i przetwarzanie transakcji. Standard bazuje na systemach UNIX, ale może być również zaimplementowany w innych systemach operacyjnych. POSIX powstał jako próba na całym świecie znana organizacja IEEE promuje przenośność aplikacji w środowiskach UNIX poprzez opracowanie abstrakcyjnego, niezależnego od platformy standardu. Na przykład dobrze znany system operacyjny czasu rzeczywistego QNX jest zgodny ze specyfikacjami tego standardu.

Ten standard szczegółowo opisuje system pamięci wirtualnej VMS (Virtual Memory System), wielozadaniowość MPE (Multi-Process Executing) i CTOS (Technologia konwergentna wyprodukowana przez system operacyjny...). Tak więc POSIX jest w rzeczywistości zestawem standardów o nazwie POSIX.I –POSIX.12. Należy również zauważyć, że POSIX.1 zakłada C jako język główny.

Język opisu funkcji systemu API.

W ten sposób programy napisane zgodnie z tymi standardami będą działać identycznie na wszystkich systemach zgodnych z POSIX. Jednak w niektórych przypadkach standard ma jedynie charakter doradczy. Niektóre normy są opisane bardzo rygorystycznie, podczas gdy inna część tylko powierzchownie odsłania podstawowe wymagania.

Implementacje systemu operacyjnego POSIX API są różne. Jeśli zdecydowana większość systemów UNIX jest początkowo zgodna ze specyfikacją IEEE Standard 1003.1-1990, to WinAPI nie jest zgodne z POSIX. Jednak do obsługi tego standardu w systemie operacyjnym MS Windows NT wprowadzono specjalny moduł obsługi POSIX API, który działa na poziomie uprawnień procesów użytkownika.

Moduł ten zapewnia konwersję i transfer wywołań z programu użytkownika do jądra systemu iz powrotem, pracując z jądrem poprzez Win API. Inne aplikacje zbudowane przy użyciu WinAPI mogą przekazywać informacje do aplikacji POSIX poprzez standardowe mechanizmy strumieni I/O (stdin, stdout).

Brak powiązanych postów ...