Dom / Problemy/ Unix standaryzacja systemów operacyjnych i posix. Standardy systemu operacyjnego czasu rzeczywistego

Uniksowa standaryzacja systemów operacyjnych i posix. Standardy systemu operacyjnego czasu rzeczywistego

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órej 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 jest przedmiotem niematerialnym („Nowa niematerialna”), a może normy w sferze niematerialnej są naprawdę bez znaczenia?

Istnieje jednak przykład obalający. Zbiór reguł pisowni języka rosyjskiego jest zasadniczo standardem, chociaż nie został zatwierdzony przez organy normalizacyjne. Ponadto, oprócz zasad (lub, jeśli wolisz, wymagań) pisowni, istnieją zasady składniowe 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 (przenośny System operacyjny Interfejs) to standard interfejsu (interfejsu) między systemem operacyjnym a aplikacją. Czasy, w których programiści pisali programy dla „gołej” maszyny (implementując własne pakiety programów wejścia/wyjścia, funkcje trygonometryczne itp.) minęły bezpowrotnie. Tekst POSIX wielokrotnie podkreśla, że standard nie nakłada żadnych wymagań na szczegóły implementacji systemu operacyjnego; można go traktować jako zbiór umów między programistami aplikacji a deweloperami system operacyjny... Tym samym (ponownie wbrew dość rozpowszechnionej opinii) POSIX jest przedmiotem zainteresowania nie tylko twórców systemów operacyjnych, ale przede wszystkim znacznie liczniejszej 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 pomiędzy jego konkretnymi implementacjami powodowały, że programy użytkowe napisane dla jednego systemu nie zawsze mogły być wykonywane w innym. Aby rozwiązać ten konkretny problem, znany jako problem mobilności oprogramowanie jest celem 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 ); części te nazywają się odpowiednio POSIX.1 i POSIX.21.

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 podręcznik lub samouczek dotyczący systemów operacyjnych, chociaż część informacyjna zawiera wskazówki 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 związane z brakiem mobilności programów i wynikająca z tego potrzeba ujednolicenia interfejsu są tak duże, że większość dostawców woli mieć przynajmniej jakiś standard, niż nie ma żadnego. 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 przypomnieć, że standard POSIX jest ułożony w: język angielski, który ze swej natury prowokuje do niejednoznaczności (np. to samo słowo może być rzeczownikiem, przymiotnikiem i czasownikiem), a „pułapki semantyczne” czają się niemal na każdej stronie. Dobrą ilustracją tego jest przykład z fikcji. Jedno z najsłynniejszych dzieł Oscara Wilde'a, który znakomicie wykorzystywał tę cechę języka angielskiego, „The Znaczenie of bearnest” jest znane po rosyjsku jako „The Znaczenie of Being Earnest”. Jednak angielska nazwa ma drugie znaczenie: Earnest (poważne) to nazwisko jednej z postaci, 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 samą nazwą 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 użytkowych." 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 odwołania (wielu prawdopodobnie słyszało wyrażenie „GOST nie został anulowany”); preambuła do POSIX mówi, że jeśli norma nie była zmieniana przez 5 lat, oznacza to, że kwestie w niej omawiane prawdopodobnie straciły na aktualności i można ją uznać za anulowaną 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źne wymaganie wyraża się słowem „shall”, na przykład: „Jeśli się powiedzie, funkcja link() musi 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 zakłada się, że wiele opcji (wyników, wywołań funkcji itp.) jest znanych, 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 () musi zwracać wskaźnik do struktury, która odwołuje się do następnego elementu 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 (), która nakazuje czekać na sygnał z określony numer, wywoływane 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 wiele możliwych wyników może być większych, ale wszystkie są również znane, a aplikacja wymaga, aby działał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 program użytkowy nie używał 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 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 hasłem sprzed dziesięciu lat „wszystko jest dozwolone, co nie jest wyraźnie zabronione”. Najwyraźniej jest to tak zakorzenione w umysłach obywateli, że wielu, nawet programistów, nie zgadza się z przytoczonym stwierdzeniem standardu. Tymczasem, jeśli użycie jakiejkolwiek konstrukcji nie jest wprost dozwolone i nie wynika z opisu, to każdy praktykujący programista zdaje sobie sprawę, że użycie 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 system operacyjny dla wielu użytkowników, a programy, które się uruchamiają 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. Aplikację działającą w czasie rzeczywistym (działającą w imieniu tego samego użytkownika) można często w naturalny sposób przedstawić jako równolegle działające 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; to zapewnia 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 sterujący ma 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, a 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 program aplikacyjny.

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 jest zgodny ze standardem. 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, prawie 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). Opcjonalne udogodnienia 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.); funkcje te są uważane za część standardu POSIX.1, ale są w pełni opisane w standardzie języka programowania C.
Systemowe nazwy typów danych. Te nazwy mają przyrostek _t.
Nazwy pliki nagłówkowe, 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, 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ć niektórych aplikacji lub systemów operacyjnych z kategorii spełniających normę. 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żesz się z nim skontaktować przez 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 najpierw 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 żadnych dorozumianych wartościach, 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

NORMY

Siergiej Zolotariew,

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 oprogramowania?

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 wynika z tego, że programiści muszą „wymyślać koło na nowo”, wciąż na nowo wdrażając dostępne od dawna funkcjonalności. 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 korzystających z 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 związku z tym, używając systemu operacyjnego zgodnego z POSIX jako platformy dla swoich projektów, programista jest w stanie przenieść gotowy kod na poziomie kodu źródłowego zarówno z ich przeszłych lub równoległych projektów, jak i z 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 oznacza raczej „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; www.pasc.org/), komitet stowarzyszeniowy, który rozwija rodzinę standardów POSIX. PASC był wcześniej znany jako Komitet Techniczny Systemów Operacyjnych.

Drugim uczestnikiem prac jest ANSI (American National Standards Institute; www.ansi.org), prywatna organizacja non-profit, która administruje i koordynuje działania normalizacyjne w Stanach Zjednoczonych. Zatrudnia tylko 75 osób, ale członkami ANSI jest ponad 1000 firm, organizacji, agencji rządowych i instytucji. ANSI reprezentuje Stany Zjednoczone w dwóch głównych międzynarodowych organach normalizacyjnych, ISO i IEC.

Trzeci uczestnik - ISO(Międzynarodowa Organizacja Normalizacyjna; www.iso.org). Została utworzona w 1946 r. decyzją Komitetu Koordynacji Norm i Zgromadzenia Ogólnego ONZ i oficjalnie rozpoczęła pracę 23 lutego 1947 r. ISO to sieć krajowych instytutów normalizacyjnych ze 146 krajów (jeden kraj - jeden członek ISO) z sekretariat centralny w Genewie (Szwajcaria). Normy ISO są opracowywane w komitetach technicznych, których pierwszym wynikiem 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; www.iec.ch/), założona w 1906 roku, IEC przygotowuje i publikuje międzynarodowe normy dla wszystkich technologii elektrycznych, elektronicznych i pokrewnych. 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- kluczowa organizacja w przygotowaniu międzynarodowych standardów dla technologia informacyjna... 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 to międzynarodowa organizacja zajmująca się standaryzacją oprogramowania, zrzeszająca blisko 200 producentów i społeczności użytkowników działających w obszarze technologii informatycznych (www.opengroup.org/) OpenGroup powstała w 1995 roku z połączenia dwóch poprzedników: X/Open i Open Fundacja Oprogramowania (OSF). Open Group specjalizuje się w opracowywaniu metodologii certyfikacji oprogramowania oraz testowaniu zgodności. W szczególności Open Group zajmuje się certyfikacją w takich obszarach jak COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S/MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) oraz, wreszcie rodzina standardów POSIX (www.opengroup.org/certification/).

AustinCommonStandardsRevisionGroup (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 (Laboratorium Informatyki - ITL), którego jednym z wyników jest Federal Information Processing Standards (FIPS, www.opengroup.org/testing/fips/general_info.html).NIST/ITL zaproponował w 1991 roku wstępny zestaw testów do certyfikacji POSIX zgodnie z FIPS PUB 151-1 1990.

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, potem nazwano go IEEE-IX (wersja systemu UNIX dla IEEE). Jednak nazwa szybko zmieniła się na POSIX, a kolejna publikacja (w 1986 r.) wykorzystywała ten nowy wariant. 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 kompletna i zatwierdzona międzynarodowa norma ISO / IEC 9945.1: 1990 POSIX została przyjęta w 1990. Specyfikacje POSIX definiują standard mechanizmu interakcji pomiędzy programem aplikacyjnym 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 zmieniając oznaczenia specyfikacji, ich konkretną zawartość, procedury i logistykę ich weryfikacji. Od tego czasu w różnych organizacjach międzynarodowych wydano kilka wydań 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 Wydanie wydane w 1988 roku zostało zrewidowane 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 Pojawił się pierwszy standard dla "czasu rzeczywistego" - IEEE Std 1003.13-1998. Jest rozszerzeniem standardu POSIX dla wbudowanych aplikacji czasu rzeczywistego.

- 1999 Postanowiono wprowadzić znaczące 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 zakończeniu prac nad standardami IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q i 1003.2b.

- 2004r. 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, ale tylko trzy otrzymały szerokie wsparcie w komercyjnych systemach operacyjnych:

1003.1a (Definicja systemu operacyjnego) definiuje podstawowe interfejsy systemu operacyjnego, kontrolę zadań, sygnały, funkcje system plików i pracować z urządzeniami, grupami użytkowników, rurociągami, buforami FIFO;

1003.1b (Realtime Extensions) opisuje rozszerzenia czasu rzeczywistego, takie jak sygnały czasu rzeczywistego, wysyłanie priorytetów, liczniki czasu, synchroniczne i asynchroniczne wejścia / wyjścia, semafory, pamięć współdzielona, komunikaty. Początkowo (przed 1993) standard ten nosił nazwę POSIX.4;

1003.1c (Wątki) definiuje funkcje wspierające wątki (wątki) - 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 testowania 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) Dostosowany do FIPS 151-2 „Information Technology – Portable Operating System Interface (POSIX) – Part 1: System Application Program Interface (API)”, czyli ISO / IEC 9945-1: norma 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 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 dla najnowszych wersji POSIX, począwszy od IEEE 1003.1 (tm) 2001. Open Group ma teraz kilka zestawów testów obejmujących IEEE Std 1003.1-1996, IEEE Standardowy 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) to zestaw testów zgodności dla interfejsy systemowe norma IEEE 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 obowiązkowe 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 przeszedł zainstalowany system testy 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 rygorystycznych zasad wymagających, aby dane dotyczące certyfikowanego RT OS były publikowane w oficjalnym rejestrze, a testy przeprowadzane są na poziomie zgodność, to obecnie istnieją tylko dwa certyfikowane systemy operacyjne RT (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żna przeprowadzić zarówno na samym systemie docelowym (samohosting) jak i na komputerze instrumentalnym (host), gotowe oprogramowanie jest zaprojektowane do pracy na systemie docelowym (docelowym). Certyfikat LynxOS v.3 za spójność (zgodność) POSIX na platformach Intel i PowerPC. Informacje na ten temat można znaleźć na stronie IEEE http://standards.ieee.org/regauth/posix/posix2.html LynxOS posiada certyfikat POSIX 1003.1-1996 wydany przez Mindcraft, akredytowane przez IEEE POSIX laboratorium testowe POSIX na NIST FIPS 151- 2 Zestaw testów zgodności. Numer dokumentu certyfikacji: Plik referencyjny: IP-2LYX002, Plik referencyjny: IP-2LYX001.

- UCZCIWOŚĆ v.5(produkt Green Hills Software, www.ghs.com) Certyfikat zgodności (zgodność) wg POSIX 1003.1-2003, Interfejsy systemowe dla architektury PowerPC w lipcu 2004 (http://get.posixcertified.ieee.org/select_product.tpl). Zestaw testowy VSX-PCTS 2003.

POSIX i system operacyjny QNX

QNX wer.4.20(opracowany przez QNX Software Systems, www.qnx.com) posiada certyfikat zgodności (zgodność) wg POSIX 1003.1-1988 dla platformy Intel według 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 IEEE Standards Association. IEEE, październik 2004.

2. Kevin M. Obeland... POSIX w czasie rzeczywistym, programowanie systemów wbudowanych, 2001.

3. Standard IEEE / ANSI 1003.1: Technologia informacyjna - (POSIX) - Część 1: Aplikacja systemowa: Interfejs programowy (API).

4. Gallmeister B.O. Programowanie w świecie rzeczywistym, POSIX.4 Sebastopol, Kalifornia: O'Reilly & Associates, 1995.

5. National Institute of Standards and Technology, 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.

PO) 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ługi systemowe takie środowisko opisuje standard POSIX (Portable Operating System Interface - interfejs mobilnego systemu operacyjnego); nazwę zasugerował znany ekspert, założyciel Free Software Foundation, Richard Stallman.

Rozważymy najnowszą dostępną wersję standardu POSIX, edycję 2003, którą można nazwać „potrójnym standardem”, a mianowicie standard IEEE Std 1003.1, Norma techniczna Open Group oraz (patrz [6]), która jest dla nas najważniejsza, międzynarodowa norma ISO/IEC 9945 (patrz [1], [2], [3], [4]).

Historia powstania tej wersji jest następująca. Na początku 1998 r. przedstawiciele trzech organizacji - Komitetu Standardów Aplikacji Mobilnych Instytutu Inżynierów Elektryków i Elektroników, Grupy Otwartej oraz Grupy Roboczej 15 Podkomitetu 22 Wspólnego Komitetu Technicznego 1 (JTC1/SC22/WG15) Międzynarodowej Organizacji dla Standaryzacji - rozpoczęli konsultacje w sprawie połączenia i rozwoju nadzorowanych przez siebie standardów dla interfejsów do usług systemowych: IEEE Std 1003.1, IEEE Std 1003.2, Basic Specifications z Open Group, ISO/IEC 9945-1, ISO/IEC 9945-2 . We wrześniu tego samego roku w Austin w Teksasie, w biurze IBM, odbyło się spotkanie organizacyjne grupy utworzonej w tym celu (patrz http://www.opengroup.org/austin).

Dokumentem założycielskim dla zrewidowanej normy, której pierwszy projekt został przedłożony w lipcu 1999 r., były Podstawowe Specyfikacje z Open Group, ponieważ zawierały one postanowienia norm IEEE i ISO/IEC. W 2001 roku, po zakończeniu prac przygotowawczych, norma zawierała następujące cztery części:

podstawowe definicje (terminy, pojęcia i interfejsy wspólne dla wszystkich części);
opis C-API do usług systemowych;
opis interfejsu do usług systemowych na poziomie język poleceń oraz narzędzia ;
szczegółowe wyjaśnienie zapisów normy, uzasadnienie podjętych decyzji.

Ponadto w ISO, IEEE i Open Group z większą lub mniejszą szybkością (w latach 2001-2002) przeszło formalne zatwierdzenie nowego standardu POSIX. W międzyczasie nagromadziły się stosunkowo niewielkie korekty, uwzględnione w edycji z 2003 roku.

Wraz z rozwojem standardu rozszerzono również interpretację terminu „POSIX”. Pierwotnie odnosił się do dokumentu IEEE Std 1003.1-1988 opisującego Interfejs aplikacji do programowania System operacyjny klasy Unix. Po standaryzacji interfejsu na poziomie języka poleceń i narzędzi bardziej poprawne jest rozumienie słowa „POSIX” jako całości standardu, oznaczającego części 2 i 3 wymienione powyżej poprzez POSIX .1 i POSIX .2 zgodnie z numeracją dokumenty IEEE i ISO/IEC.

Podstawowe idee standardu POSIX

Standard POSIX opisuje wiele podstawowych usług systemowych niezbędnych do działania programów użytkowych. Dostęp do nich uzyskuje się za pośrednictwem interfejsu określonego dla języka C, języka poleceń i popularnych narzędzi.

Każdy interfejs ma dwie strony: dzwoniącego i wywoływanego. Standard POSIX jest przede wszystkim zorientowany na rozmówcę. Jego celem jest tworzenie aplikacji mobile na poziomie języka źródłowego... Oznacza to w szczególności, że przy przenoszeniu programów w języku C na inną platformę operacyjną wymagana jest ponowna kompilacja. Przenośność programów wykonywalnych i/lub plików obiektowych nie jest zaangażowana.

Standard POSIX nie jest w żaden sposób ograniczony do środowiska Unix. Istnieją systemy operacyjne (OS) „niezależnego pochodzenia” (na przykład systemy czasu rzeczywistego), które zapewniają niezbędne usługi, a tym samym wspierają wykonywanie aplikacji zgodnych z POSIX. Można argumentować, że przestrzeganie standardu POSIX ułatwia przenoszenie aplikacji na praktycznie każdą popularną platformę operacyjną. Dodatkowe wysiłki na rzecz mobilności poczynione w fazie rozwoju z pewnością się opłaci.

Definiując interfejs do usług systemowych, POSIX pozostawia ich implementację poza zakresem. W szczególności się nie różnią wywołania systemowe oraz funkcje biblioteczne... Środki nie podlegają standaryzacji administracja, wymagane tylko ograniczenia sprzętowe i funkcje superużytkownik, co po raz kolejny podkreśla koncentrację normy

Dzisiaj postaramy się dowiedzieć, co opisuje standard POSIX. Standardy zostały zaprojektowane tak, aby mój komputer mógł komunikować się z Twoim. Dzięki nim strony internetowe czy streaming wideo na żywo będą wyglądały tak samo na dwóch podobnych komputerach.

Jednak standardowe są przeznaczone do bardziej ambitnych zadań niż prosta wymiana jakichkolwiek danych między użytkownikami. Niektóre standardy definiują konkretny model, który otwiera możliwości wykraczające daleko poza zgodność plików lub sieci. Jednym z nich jest standard POSIX.

Co to jest POSIX?

POSIX (wymawiane „posix”) to interfejs dla przenośnych systemów operacyjnych. Ale co to oznacza? Najpierw należy zdefiniować zakres pojęcia „przenośności”, w tym konkretny przypadek i zdefiniować pojęcie „interfejsu”. Aby się tego dowiedzieć, trzeba zacząć od tego, że oba pojęcia są ze sobą nierozerwalnie związane.

„Przenośność”, w kontekście standardu POSIX, odnosi się do: kod źródłowy(nie do plików binarnych, które są zbierane z tych źródeł). Teraz dowiedzmy się, czym jest „interfejs”. W programowaniu „interfejs” to sposób, w jaki Twój kod współdziała z resztą kodu. Interfejs oczekuje, że Twój kod dostarczy określonych informacji. Twój kod z kolei wymaga otrzymania pewnych informacji z interfejsu. Dobry przykład- funkcja fopen() w języku C. Oczekuje informacji z dwóch części: ścieżki do pliku oraz trybu, w jakim zostanie otwarty. Korzystając z tych danych, system operacyjny zwraca inny rodzaj informacji, zwany „deskryptorem pliku”. Deskryptora pliku można użyć do odczytania pliku lub zapisania do pliku. To jest interfejs. Wynika z tego, że kod zgodny z POSIX może być skompilowany dla dowolnego systemu operacyjnego zgodnego z POSIX bez większych zmian, co oznacza, że będzie przenośny.

Lista interfejsów POSIX jest dostępna, jednak mimo że jest ogromna, całkiem możliwe, że jest niekompletna. POSIX nie ogranicza się do wywołań systemowych, definiuje również standardy powłok systemu operacyjnego (powłoki, w przeciwnym razie - interfejsy wiersz poleceń), narzędzia systemowe, takie jak „awk” lub „echo”, biblioteki systemowe i inne.

Standard POSIX pojawił się jako projekt Richarda Stallmana w 1985 roku, a później został sformalizowany jako IEEE Std 1003.-1998. Jak sama nazwa wskazuje, 1998 był rokiem oficjalnej publikacji. Od tego czasu wydano dużą liczbę dodatków i rozszerzeń do POSIX, które stopniowo przekształcają się w całą rodzinę standardów, formalnie znaną jako IEEE 1003, uznawaną za międzynarodową, z oznaczeniem SO/IEC 9945, nazywaną po prostu standardem rodziny POSIX .

System operacyjny nie musi być zgodny z POSIX, ani nawet mniej certyfikowany, ale pozwala to programistom tworzyć aplikacje, narzędzia i platformy bez ciągłego przepisywania kodu, a jedynie uzupełniać i łączyć się z już gotowym . Nie jest również konieczne pisanie kodu zgodnego z POSIX, ale to znacznie poprawia przenośność projektów między systemami operacyjnymi. Oznacza to, że umiejętność pisania kodu zgodnego z POSIX jest cenna sama w sobie iz pewnością bardzo satysfakcjonująca dla Twojej kariery. Duże projekty, takie jak Gnome czy KDE, są zgodne ze standardem POSIX, co zapewnia, że działają na różnych systemach operacyjnych. Podsystem POSIX jest zaimplementowany nawet w najnowsze wydania Okna. Linux jest znany z tego, że obsługuje większość wywołań systemowych związanych z POSIX, a także jego główne rozszerzenie o nazwie Linux Standard Base, które zostało zaprojektowane do łączenia dystrybucji Linuksa pod względem obsługi kodu źródłowego i binarnego.

Mamy nadzieję, że rzuciliśmy trochę światła na to, czym jest POSIX. Masz ciekawe informacje na ten temat? Podziel się tym w komentarzach.

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 oprogramowania?

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 korzystających z innych systemów operacyjnych).

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 kodu ź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) to prywatna organizacja non-profit, która administruje i koordynuje działania normalizacyjne w Stanach Zjednoczonych. Zatrudnia tylko 75 osób, ale ANSI ma ponad 1000 członków, 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, a 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 wynikiem 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 przygotowuje 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.

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 zajmuje się certyfikacją w takich obszarach jak COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S/MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) oraz, wreszcie rodzina standardów POSIX (www.opengroup.org/certification/).

Austin Common Standards Revision Group (CSRG)- wspólną techniczną grupę roboczą utworzoną w 2002 roku przez ISO, IEC i Open Group w celu stworzenia i utrzymania najnowszych wersji standardu 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 i Single UNIX Specification (www.opengroup.org/press/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, a już w następnej publikacji (w 1986 r.) ta nowa wersja był używany 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ł przyjęte w 1990 r. Specyfikacje POSIX definiują standardowy mechanizm interakcji między programem użytkowym a systemem operacyjnym i obecnie obejmują ponad 30 standardów pod auspicjami IEEE, ISO, IEC i ANSI.

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 zakończeniu prac nad standardami 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 testowania 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”.

W 2003 roku IEEE-SA i Open Group ogłosiły nowy wspólny program certyfikacji dla najnowszych wersji POSIX, zaczynając 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 obowiązkowe części).

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

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 pomyślnie przeszło ustalony system testowy z pomocą akredytowanego laboratorium lub 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 są podane 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żna przeprowadzić zarówno na samym systemie docelowym (samohosting) jak i na komputerze instrumentalnym (host), gotowe oprogramowanie jest zaprojektowane 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

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

Uniksowa standaryzacja systemów operacyjnych i posix. Standardy systemu operacyjnego czasu rzeczywistego

Ogólnie o standardach

Cel i „superzadanie” standardu POSIX

O semantyce

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

Przedmioty normalizacji i struktura normy

Wniosek

O autorze

Literatura

Podstawowe idee standardu POSIX

Co to jest POSIX?

POSIX i RV OS: próba systematyzacji

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

Kto jest kim w rozwoju POSIX

Co to jest POSIX?

Historia rozwoju standardu POSIX

Najważniejsze standardy POSIX dla RT OS

Procedura certyfikacji

Trochę o zamieszaniu terminologicznym

Certyfikowany OS RV

POSIX i system operacyjny QNX

Odzyskiwanie hasła