Menu
Jest wolny
Zameldować się
główny  /  Problemy / UNIX Standaryzacja systemów operacyjnych i POSIX. Standardy systemów operacyjnych w czasie rzeczywistym

Uniks Standaryzacja systemów operacyjnych i Posix. Standardy systemów operacyjnych w czasie rzeczywistym

O standardach w ogóle

Wśród programistów praktyków są opinią, że normy w programowaniu nie są w ogóle potrzebne, ponieważ:

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

(2) Walczą z inicjatywą programistów;

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

Być może ta opinia nie powinna być zwracana na uwagę, jeśli nie dwie okoliczności:

(1) Jego praktyki wyraziste, to znaczy, że są to osoby "kwestionują produkty programowe";

(2) Powyższy argument został odkryty przez autora tego artykułu w jednej z publikacji w Internecie w stosunku do standardu języka programowego C, co stało się jasne, że taka opinia została rozpowszechniona "w skali międzynarodowej", a nie tylko wśród arogancki rosyjski "superfrogramów".

Słowo "standard" jest zwykle związany z czymś materiałem (standardowe wymiary, standard napięcie elektryczne Itd.), Podczas gdy program komputerowy jest wartością niematerialną ("nową niematerialną"), a może standardy w kulach niematerialnej są naprawdę bez znaczenia?

Istnieje jednak przykład refutujący. Połączenie zasad pisowni języka rosyjskiego zasadniczo jest standardem, choć nie zatwierdzony przez władze normalizacyjne. Ponadto, z wyjątkiem zasad (lub, jeśli jesteś wymaganiami) pisowni, istnieją zasady składniowe, a co najważniejsze, semantyka. Ten ostatni ilustruje pytanie "dzieci": Dlaczego kot nazywa kota? Dokładna odpowiedź na to pytanie: Ponieważ nasi przodkowie zgodzili się tak; Przodkowie Brytyjczyków zgodzili się nazwać ten sam kot bestii, przodkowie Niemców - kotek itp. Ogólnie rzecz biorąc, znaczenie lub semantyki lub zasady interpretacji dowolnego słowa lub kombinacji słów - kwestia porozumienia.

Spotkanie i "superbate" standardowego posix

W następujący sposób z nazwy, POSIX (przenośny System operacyjny Interfejs) jest standardem do parowania (interfejs) między systemem operacyjnym a programem aplikacji. Czasy, gdy programistrzy napisali programy do maszyny "Naked" (wdrażanie własnych pakietów programów I / O, funkcje trygonometryczne itp.), Przekazywane bezpowrotnie. Tekst Posix wielokrotnie podkreśla, że \u200b\u200bstandard nie przedstawił żadnych wymagań dotyczących operacji systemu operacyjnego; Można go traktować jako całość porozumień między programistami i programistami system operacyjny. Tak więc (ponownie, w przeciwieństwie do dość popularnej opinii), POSIX jest interesujący nie tylko dla deweloperów systemów operacyjnych, ale przede wszystkim dla znacznie większej kategorii programistów - zastosowanych.

Potrzeba standardu tego rodzaju została zrealizowana w latach 80., kiedy systemy operacyjne UNIX były rozpowszechnione. Okazało się, że chociaż system ten został pomyślany jako ujednolicony, różnice między jego konkretnymi wdrożeniami doprowadziło do faktu, że programy zgłoszeniowe napisane dla jednego systemu nie zawsze mogą być wykonywane w innym. W sprawie decyzji o tym konkretnym problemie, znany jako problem mobilności oprogramowanie, POSIX skierowany. Pierwsza edycja standardu została wydana w 1988 r. (Istnieje tłumaczenie), w którym wszystkie różne kwestie związane z mobilnością programu podzielono na dwie części: (1) Interfejs aplikacji, (2) tłumacza poleceń i narzędzia (Interfejs użytkownika); Te części zostały nazwane Posix.1 i Posix.2, odpowiednio1.

Określimy, że ten artykuł będzie mówił tylko o standardowym interfejsie aplikacji, Posix.1, którego druga (i ostatnio do tej pory) została zatwierdzona w dniu 12 lipca 1996 r.

Część informacyjna standardu podkreśla również, że Posix nie jest opisem interfejsu niektórych "idealnego" systemu operacyjnego, ale wynikiem uogólnienia i systematyzacji doświadczeń zdobytych w rozwoju systemów operacyjnych UNIX. Ponadto Posix nie może służyć jako instrukcja obsługi lub szkolenia systemów operacyjnych, chociaż część informacyjna zawiera zalecenia dla programistów i fragmentów programów.

Standard odnosi się do faktu, że nie można stworzyć pełnoprawnego systemu operacyjnego, koncentrując się wyłącznie na funkcjach interfejsu opisanych w nim. (W szczególności, POSIX.1 nie odzwierciedla takich problemów jako funkcje sieciowe i powiązane interfejsu lub interfejsu graficznego.) Jednakże koszty finansowe spowodowane przez nongetity programów oraz potrzebę zjednoczenia interfejsu jest tak wielki, że większość producentów preferuje Mieć przynajmniej jakiś standard niż nie ma nikogo. Z tego powodu bardzo wielu programistów dąży do nawigacji na Posix. Umożliwia to całkowicie wyeliminować bezgranicznościowy programów, a następnie przynajmniej znacznie zmniejszyć nonglabilną część programu.

O SEMANTICS.

Jak już wspomniano, POSIX można uznać za zestaw umów między deweloperem systemu operacyjnego a programistą aplikacji. "Umowa" oznacza przede wszystkim identyczności interpretacji (semantyki) słów i wyrażeń. Poniżej przedstawiono przykłady ilustrujące trudność zadania osiągnięcia umowy.

Jak przekazywać znaczenie podczas tłumaczenia

Przede wszystkim musisz przypomnieć, że standard POSIX został przedstawiony w języku angielskim, który w przywidzianych przywiedziniu dwuznaczności (na przykład, to samo słowo może być rzeczownikami, przymiotnikiem i czasownikiem), a "pułapki semantyczne" słuchało prawie na każdej stronie. Dobra ilustracja wspomnianego jest przykładem fikcji. Jednym z najsłynniejszych dzieł Oscara Wilde, który świetnie użył tej funkcji języka angielskiego, - znaczenie bycia poważnym - jest znany w języku rosyjskim ", jak ważne jest poważne". Jednak nazwa angielska ma drugie znaczenie: Zdarzenie (poważne) - nazwisko jednego ze znaków, a nazwa może być przetłumaczona inaczej: "Jak ważne jest być Ernst". Jest srebro rosyjskiego, a jeśli było poważne nazwisko, tłumaczenie byłoby idealnie dokładne, z przeniesieniem obu znaczeń.

To samo jest w przypadku nazwy standardu: przenośny interfejs systemu operacyjnego. Poradnik przymiotnikowy (mobilny) odnosi się do systemu operacyjnego oraz do programu aplikacji, ale nie jest możliwe, aby wyrazić go wkrótce w języku rosyjskim, możesz przetłumaczyć jako "Mobilny interfejs systemu operacyjnego" lub "Interfejs systemu operacyjnego, który zapewnia mobilność Programy aplikacji. " Druga opcja Lepiej odzwierciedla intencje standardowych programistów, ale jednocześnie utracono pierwszy przemyty (bardziej znana pierwsza opcja została zachowana).

Semantyka słowa "Standard"

Głównym tekstem standardu jest przede wszystkim preambuły, w którym wyjaśniono znaczenie słowa IEEE Standards2. W następujący sposób z tych wyjaśnień istnieje co najmniej trzy różnice semantyczne z rosyjskojęzycznego terminu GOST:

(1) Intuicyjnie uważa, że \u200b\u200bGost ma potęgę prawa, którego naruszenie jest prześladowane; Posix jest zestawem wymagań, zgodnie z tym, jaką jest wyłącznie dobrowolne.

(2) GOST działa do anulowania (wielu, prawdopodobnie musiał usłyszeć wyrażenie "Gost nikt anulowany"); W preambule Posix mówi się, że jeśli standard nie został zmieniony przez 5 lat, oznacza to, że pytania rozpatrywane w nim najprawdopodobniej straciły znaczenie i można go uznać za anulowane automatycznie;

(3) Gost Anonomen; W wprowadzającej części Posix lista osób, które uczestniczyły w rozwoju tego standardu, a także podaje adres, w którym możesz wysłać żądania interpretacji; Mówi się również, że odpowiedź na każde żądanie podlega procedurze koordynacji (innymi słowy, autorzy standardu zgadzają się ze sobą przed udzieleniem odpowiedzi).

Tak więc tłumaczenie nawet takiego znanego słowa jako standardowe słowo "standard" wymaga komentarzy.

Semantyka słów "musi", "nie określono", "nie zdefiniowane", "określone przez wdrożenie"

Sekcja 2 normy nazywana jest "terminologią i wymaganiami ogólnymi". Zawiera definicje nie tylko specjalnych terminów (takich jak "proces" lub "semaphor"), ale także taki wydawał się, że oczywiste słowa, jako "muszą" lub "maj". Ponieważ Posix.1 jest standardem w interfejsie, jego wymagania są związane zarówno z systemem operacyjnym, jak i programem aplikacji. Wyraźne wymóg wyraża słowo "musi" (powinno), na przykład: "w przypadku pomyślnego zakończenia, funkcja Link () musi zwrócić wartość zerową." W tym przykładzie mówimy o wymogu systemem operacyjnym: Funkcja Link () musi być wdrażana, tak że po pomyślnym zakończeniu wartość zerowa zwrócona.

Warunki "nie określone" i "nie zdefiniowane" wyraziły ten sam pomysł, że standard przyznaje swobodę wyboru, ale znaczenie tych terminów jest zróżnicowane. Termin "nie określony" oznacza, że \u200b\u200bmówimy o niektórych poprawnych (działania, struktury oprogramowania itp.), A termin "nie zdefiniowany" - o niepoprawnym (błędne). Część informacyjna standardu stanowi następujące wyjaśnienie.

Termin "nie określono" oznacza, że \u200b\u200buważa się, że wiele opcji (wyników, wyniki wywołania funkcji itp.) Zastanawia się, a norma pozwala każdemu z nich; W konkretnym wdrożeniu systemu operacyjnego każdy może zostać wybrany, a taki system jest uważany za odpowiedni standard. Program zastosowany (ściśle istotny standard) musi być zapisany w taki sposób, że działa poprawnie w dowolnym wariancie; Zasadniczo termin ten niejawnie wyraził wymóg programu aplikacji.

Daj nam przykład: "Funkcja READDIR () musi zwrócić wskaźnik do struktury odnoszącej się do następnego elementu katalogowego. Niezależnie od tego, czy elementy katalogu są zwracane z nazwami "kropki" i "punkt - punkt", standard nie jest określony. " W tym przykładzie możliwe jest cztery wyniki, a wymogiem programu aplikacji jest to, że musi być zaprojektowany dla któregokolwiek z nich.

Innym przykładem: "Jeśli funkcja SIGWAIT (), która przepisuje oczekiwanie na sygnał z określoną liczbą, jest spowodowany w kilku strumieniach sterujących, wtedy, gdy sygnał zostanie odebrany, nie więcej niż jeden z nich powinien powrócić z Sigwait (). W jakim przepływie kontroli stanie się, standard nie zostanie określony. " W tym przykładzie wiele możliwych rezultatów może być więcej, ale są również znane, a wymogiem programu aplikacji jest to, że powinno działać poprawnie w każdym wyniku.

Termin "nie zdefiniowany" oznacza, że \u200b\u200bnawet wiele rezultatów nie jest znane, każdy wynik jest możliwy, nawet zgadzający (na przykład upadek systemu, utraty danych itp.). Zasadniczo, termin ten niejawnie wyraził wymóg dla programu aplikacji, aby nie używać odpowiednich danych lub projektów. Na przykład: "Jeśli funkcja argumentu DirP Readir () nie odnosi się do aktualnie otwartego katalogu, wynik nie jest zdefiniowany."

Ten przykład zawiera żądanie, aby zastosować jako argument READDIR () Link tylko do operacyjnego katalogu; Naruszenie tego wymogu może prowadzić do katastrofalnych konsekwencji, a odpowiedzialność za ona przypisana do programatora aplikacji.

Oto kolejny przykład: "W przypadku pomyślnego zakończenia funkcja odczytu () musi zwrócić liczbę całkowitą, która wskazuje liczbę praktycznie odczytanych bajtów. W przeciwnym razie funkcja musi przypisać kod błędu do errno i powrotu -1, a zawartość bufora, do którego określa argument BUF nie jest zdefiniowany. "

Użyj w programie aplikacji z bufora w przypadku błędu funkcji odczytu (), standard zakazuje, a konsekwencje naruszenia tego wymogu nakłada na programista aplikacji.

Znaczenie terminu "jest określone przez wdrożenie" różni się od intuicyjnego. Oczywiście, w określonym systemie operacyjnym, nie może być żadna "nie rada" lub "niepewna" wynik, uzyskano jakiś konkretny wynik. Termin "określony przez wdrożenie" wyraża wymóg normy do dokumentacji dla systemu operacyjnego: wynik nie tylko należy wyjaśnić (deweloper systemu operacyjnego będzie musiała zrobić), ale także wyraźnie odzwierciedla dokumentację system.

Semantycy domyślnie.

Żaden dokument regulacyjny nie może obejmować całej różnorodności przypadków, które mogą sprostać w praktyce, więc jest to nieuniknione o czymś silczym3. Na przykład, w opisie funkcji można powiedzieć, że jego argument może podejmować wartości z określonego zakresu, ale nic nie mówi, że będzie to wynik, jeśli argument nie wpada w ten zakres. Oczywiście, aby uniknąć nieporozumień, konieczne jest posiadanie pojedynczej domyślnej semantyki. W części pouczającej normy istnieje ciekawska fraza: "Ogólnie akceptowane semantyki domyślnego jest zabronione". To oświadczenie zaprzecza dobrze znanym hasłem dekady temu "Wszystko, co wyraźnie nie jest dozwolone. Najwyraźniej był tak zakorzeniony świadomości obywateli, że wielu, nawet programiści, nie zgadzają się z udzielonym oświadczeniem standardu. Tymczasem, jeśli użycie dowolnego projektu jest wyraźnie niedozwolone i nie następuje z opisu, wówczas dowolny programista praktykujący zdaje sobie sprawę, że jego użycie jest ryzykowne, a jeśli nie działa, nie występuje do roszczenia.

Procesy i przepływy sterujące

Oba te terminy wyrażają ideę równoległości wykonania. System operacyjny Unix został pierwotnie pomyślany jako multiplayer, a programy, które są wprowadzane przez różnych użytkowników, muszą być bezpiecznie odizolowane od siebie, aby przypadkowo zniekształcać dane "innych osób". Izolacja ta jest dostarczana przez fakt, że program użytkownika jest wykonywany w pewnym procesie rozwijającym się we własnej wirtualnej przestrzeni adresowej. Nawet jeśli program ma globalne dane, gdy zaczyna go w różnych procesach, będą one automatycznie "rozwiedzione" przez różne przestrzenie adresowe.

Jednak mechanizm procesów nie jest dość zadowalający podczas programowania zadań w czasie rzeczywistym. Program aplikacji w czasie rzeczywistym (działający w imieniu tego samego użytkownika) może być często naturalnie reprezentowany jako równolegle do części wykonywalnych, które są nazywane "przepływami sterującymi" (gwint). Najważniejszą różnicą z procesów jest to, że wszystkie przepływy sterujące rozwijają się w jednej przestrzeni adresowej; Zapewnia to szybki dostęp do globalnych danych, ale jednocześnie ryzyko niezamierzonego zakłóceń ich zniekształceń i że nie wystąpi to, konieczne jest spełnienie pewnego programowania dyscypliny. Odpowiednie zalecenia są zawarte w częściowej części standardu.

Należy podkreślić, że idea wielokrotnego wdrażana jest w wielu systemach operacyjnych w czasie rzeczywistym i jest realizowana inaczej w tym sensie, że różne zestawy atrybutów i funkcji interfejsu odpowiadają każdemu strumieniom sterującym; Czasami zamiast terminu "przepływ sterowania" (wątek) używa terminu "zadanie" (zadanie). Aby uniknąć nieporozumień, standard podkreśla, że \u200b\u200bprzychodzi wyłącznie o strumieniach sterujących POSIX, a nazwy odpowiednich funkcji interfejsu mają prefiks PTHREAD_ (na przykład, pthread_create (), pthread_join () itp.).

Zgodność ze standardem. Semantyka słowa "odpowiada"

Jest intuicyjny, że jeśli dwa przedmioty są dokonywane zgodnie z tym samym standardem, są one gwarantowane "dopasować" ze sobą i będzie działać razem w parze; W tym celu jest cel wprowadzenia standardu koniugacji (interfejs). Ponieważ POSIX jest standardem na interfejsie, możesz porozmawiać o zgodności ze standardem zarówno systemu operacyjnego, jak i program aplikacyjny.

POSIX.1 Standard zawiera kilkaset (jeśli nie tysiące) wymagań; Uważa się, że jeśli przynajmniej jeden z nich nie zostanie spełniony, system (lub program aplikacji) nie spełnia standardu. Jednocześnie, taka liczba systemów operacyjnych UNIX i programy aplikacji są dla nich zapisane, które jest mało prawdopodobne, aby rozsądnie wymaga pełnej korespondencji w określonym znaczeniu. Trudności z rozwijaniem międzynarodowego standardu tego rodzaju są pogarszane przez istnienie różnych języków narodowych. Nawet jeśli zapomnisz o programach aplikacji przeznaczonych do przetwarzania tekstów w językach narodowych, prawie każda aplikacja musi wydać pewne komunikaty diagnostyczne i / lub postrzegają teksty wprowadzone przez operatora.

  • Ścisłe przestrzeganie standardu POSIX.1;
  • zgodność z międzynarodową wersją Posix.1;
  • zgodność z wersją krajową POSIX.1;
  • zgodność POSIX.1 z rozszerzeniami.

Po drugie, wiele funduszy interfejsu są opcjonalne (opcjonalne); Norma wymaga opcjonalnego funkcji interfejsu, który zostanie opracowany zgodnie z przepisami standardu, albo zawsze zwrócił specjalny kod błędu, enosys (co oznacza, że \u200b\u200bfunkcja nie jest wdrażana). Opcjonalne środki są podzielone na kilka grup, z których każdy odpowiada pewnym stałym konfiguracji, który jest zadeklarowany (#Define Operator) w odpowiednim pliku nagłówka; Zapewnia to możliwość ustalenia, czy funkcja jest implementowana w fazie kompilacji.

Opisany dopuszczenie mobilności wynalazł nie przez autorów Posix i dawno temu stosowane w praktyce; W wielu systemach operacyjnych stałe konfiguracji są stosowane do identyfikacji samego systemu lub jego wersji. A tutaj standard nie oferuje nic zasadniczo nowego, ale tylko systematyzuje istniejącą praktykę.

Obiekty normalizacyjne i standardowa struktura

Mówić na krótko, obiekty normalizacyjne Posix.1 to nazwy i semantyki. Dokładniej, mówimy o następujących.

  • Funkcje interfejsu. 357 Funkcje są znormalizowane, a 107 funkcji są pobierane ze standardowych bibliotek SI (matematyczny, przetwarzanie wierszy, wejście / wyjście itp.); Funkcje te są uważane za część standardu POSIX.1, ale ich pełny opis jest zawarty w standardowym języku programowania.
  • Nazwy typów danych systemowych. Te nazwy mają przyrostek _t.
  • Nazwy plików nagłówka, a także minimalna kompozycja tych plików.
  • Nazwy wielokrotnych zmiennych globalnych (na przykład errno).
  • Nazwy symboliczne dla kodeksów błędów, które można zainstalować podczas pracy funkcji. Te nazwy zaczynają się od litery E (Eperm, enotempty itp.).
  • Stałe nazwy konfiguracji. Te nazwy mają prefiks _posix_.
  • Symboliczne nazwy sygnałów; Te nazwy mają prefiks SIG. Oprócz 20 "tradycyjnych" sygnałów (Sigabrt, Sigalrm itp.), Sygnały w czasie rzeczywistym są znormalizowane, których liczby powinny zajmować niektórych stałych zakresów od Sigtmin do SigRtmax Inclusive, zawierający nie mniej niż numery RTSIG_MAX.
  • Nazwy symboliczne odpowiadające wartości poszczególnych argumentów niektórych funkcji (na przykład funkcji argumentu CMD FCNTL () może przyjmować F_DUPFD, F_GETFD, wartości F_GetLK itp.).
  • Nazwy makr, stałych, flag bitowych, zmiennych środowiskowych.

Ogólnie rzecz biorąc, standard składa się z dwóch dużych części w przybliżeniu takiej samej objętości. Pierwsza połowa jest częścią regulacyjną - zawiera wymagania i zalecenia standardu (18 sekcji), drugą - częścią informacyjną - zawiera aplikacje, które zawierają listę odniesień, komentarzy i wyjaśnień do części regulacyjnej, kompozycji plików nagłówka , przykład profilu ("projekcja") standardu (dla Danii), charakterystyki i metod pomiaru wydajności najważniejszych funkcji, a także opis dodatkowych funkcji interfejsu do pracy z plikami w czasie rzeczywistym; Oczekuje się, że w następujących edycjach standardu funkcje te zostaną uwzględnione w części regulacyjnej.

Pomysł, z którego typami usług systemu operacyjnego są objęte standardem, daje sumę "podsumowania standardowych sekcji".

Wniosek

Główną zawartością standardu POSIX jest semantyka funkcji interfejsu. Standaryzacja semantyki - sama sprawa nie jest łatwa (wszyscy wiedzą, jak trudno jest zgodzić się nawet do dwóch osób), a trudności są zaostrzone przez wielu ludzi, obecnie zaangażowanych w działania programistyczne. Na przykład paradygmator wykonania równoległego jest wyrażona przez takie warunki, jak "proces", "zadanie" i "przepływ zarządzania", ale z punktu widzenia praktycznych programowania "zadania" w systemie operacyjnym IBM OS / 360 iw System operacyjny w czasie rzeczywistym VXWorks nie jest również jeden, a także. Innym przykładem jest semafory. Semafory są binarne, liczb całkowity ("z miernikiem") i wzajemnym wyjątkiem (przy okazji programistry nazywają się "Mutaxes", zwalniając, aby uniknąć nieporozumień). I na przykład semafory liczby całkowitej w systemie operacyjnym VXWORKS, nie jest tak samo jak Semafory Posix.

Autorzy standardu POSIX, doskonale zdając sobie sprawę, jak trudno jest sprawić, by ludzie porzucili swoje nawyki (które nazywają "ustaloną praktyką"), oświadczają, że dokonali logicznie połączonego i minimalnego systemu funkcji interfejsu obejmujących większość usług tradycyjnie świadczonych Według systemu operacyjnego opisano szczegółowo semantykę tych funkcji i oferują wszystkich do korzystania z nich w swoich rozwojach4.

Podczas czytania standardy czasami pojawia się wrażenie, że niektóre preparaty miały pojedynczy cel: nie wycofać niektórych programów aplikacji lub systemów operacyjnych z kategorii. Taki cel był rzeczywiście ustawiony i wyraźnie sformułowany we wprowadzeniu: Standard powinien uwzględniać bieżącą praktykę, aby zmaksymalizować zakres. Głównym celem jest jednak, aby zapewnić mobilność programów aplikacji.

O autentycznym

Sergey Romanyuk. - starszy badacz Instytutu Badań Badań Systemów, Szef Grupa Tłumaczenia Systemów Posix. Możesz się z nim skontaktować e-mail Adres: [Chroniony e-mail]

1 Należy dodać, że praca na standard trwa przez wiele lat; Nowe pytania są identyfikowane, a są one zawarte w jednej z istniejących części lub są wykonane w postaci oddzielnej części, którą później można anulować. Tak się stało, na przykład, z interfejsem środkiem w czasie rzeczywistym, który został po raz pierwszy ogłoszony jako POSIX.4, a następnie włączony do Posix.1.

2 IEEE jest organizacją, w której został opracowany standard POSIX.

3 Tutaj "Midor" oznacza cichy, a nie domyślnie; Nie chodzi o niektóre dorozumiane wartości, które są rzeczywiście zadeklarowane, ale o deklaracji wzmianki w ogóle.

4 Tłumaczenie standardu na rosyjski zostanie opublikowany na początku 2000 roku.

Literatura

Międzynarodowy standard ISO / IEC 9945-1 (ANSI / IEEE STD 1003.1) Druga edycja. 1996-07-12. Technologia informacyjna - Przenośny interfejs systemu operacyjnego (POSIX) - Część 1: Interfejs programu aplikacji systemu (API).

M.I. Belysakov, Yu.i. Wereruve, A.l.fridman. Mobilny system operacyjny. Informator. Moskwa, radio i komunikacja, 1991.

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

Sekcja 1 - Wprowadzenie
Sekcja 2. - Terminologia i definicje
Sekcja 3. - Funkcje zarządzania procesami (tworzenie, zastępowanie obrazów, zakończenia) i sygnałów (zarządzanie maską, odpowiedź sygnału)
Sekcja 4. - Identyfikacja (procesy, użytkownicy, systemy, terminal), badania czasów spędzonych na wykonaniu procesu, badania zmiennej środowiskowej.
Sekcja 5. - Zarządzaj plikami i katalogami
Sekcja 6. - Funkcje wejścia i wyjścia
Sekcja 7. - Funkcje zarządzania terminalami
Sekcja 8. - funkcje pożyczone ze standardu
Sekcja 9. - Dostęp do baz danych użytkownika i grup użytkowników
Sekcja 10. - Formaty danych do archiwizacji i wymiany (TAR i CPIO)
Sekcja 11. - Narzędzia synchronizacji: semafory, mutaxes i warunki zmienne
Sekcja 12. - Funkcje zarządzania pamięcią: Przestrzeń procesu mocowania i nieporozumienia, wyświetla pliki pamięci, ochrona pamięci, pamięci współdzielonej
Sekcja 13. - Funkcje związane z procesami planowania i przepływami sterującymi
Sekcja 14. - Zarządzaj zegarówami i timerami
Sekcja 15. - Zarządzanie kolejkami raportami
Sekcja 16. - Podstawowe funkcje związane z przepływami sterującymi
Sekcja 17. - Dane strumienia indywidualnego sterowania (dane specyficzne dla wątków)
Sekcja 18. - Środki niszczenia przepływów sterujących

Standardy

Sergey Zolotarev,

Celem tego artykułu jest próbę dokonania pewnej jasności w historii rozwoju standardu POSIX w odniesieniu do systemów operacyjnych w czasie rzeczywistym (OS RV).

Jako wprowadzenie: Dlaczego potrzebujesz standaryzacji interfejsu programowania?

Jednym z najważniejszych właściwości standardu POSIX jest to, że określa "znormalizowany interfejs programowania", który deweloperzy złożonego oprogramowania i systemów sprzętowych powinny przestrzegać programistów. Twórcy tych systemów są zmuszeni stawić czoła takim wymaganiom jako krótki czas wejścia na rynek (ze względu na sztywną konkurencję), minimalizując koszty i przyspieszenie zwrotu inwestycji. Jednocześnie udział wydatków Liona spowodowany spowolnieniem procesu rozwoju jest związane z faktem, że programowani muszą "wymyślić rower", ponownie i ponownie wdrażać funkcjonalność, która od dawna dostępna. Ale można to uniknąć przez:

Kod ponownego użycia z poprzednich i równoległych projektów;

Przeniesienie kodu z innego systemu operacyjnego;

Przyciąganie deweloperów z innych projektów (w tym za pomocą innego systemu operacyjnego).

Wszystko to jest możliwe dzięki zastosowaniu systemu operacyjnego ze standardowym API. Ponadto, jeśli w pierwszym przypadku organizacja wystarczy, aby mieć pewną normę wewnętrzną (która jest szczególnie charakterystyczna dla marki OS), a drugie dwa przypadki są po prostu wymagające dostępności ogólnie przyjętych standardów - na przykład, posix.

Tak więc, przy użyciu projektu OS Posix-Compatible jako platformy, deweloper ma możliwość przeniesienia gotowy kod. Na poziomie tekstu źródłowego, zarówno z ich przeszłych lub równoległych projektów, jak i z projektów trzeciej firm. Nie tylko znacząco zmniejsza czas rozwoju oprogramowania, ale także poprawia jakość, ponieważ sprawdzony kod zawsze zawiera mniej błędów.

Kto jest kim w rozwoju Posix

I zacznijmy od bardzo standardowego POSIX, ale w celu zamawiania rolę organizacji zaangażowanych w działanie nad tym.

Pierwszym uczestnikiem jest Ieee. Instytut Inżynierów Elektryk i Elektronicznych, Instytut Inżynierów Elektryk i Elektroniki), Publiczne Stowarzyszenie Non-Zysk Specjaliści. IEEE prowadzi swoją historię od 1884 r. (Formalnie - od 1963 r.), Łączy 380 000 członków indywidualnych z 150 krajów, publikuje trzecią część literatury technicznej dotyczącej korzystania z komputerów, zarządzania, technologii elektrycznych i informacyjnych, a także ponad 100 magazynów, popularne w środowisku profesjonalistów; Ponadto Stowarzyszenie jest rocznie ponad 300 głównych konferencji. Ieee uczestniczył w rozwoju ponad 900 istniejących standardów (www.ieee.ru/ieeee.htm). Obecnie Instytut ten jest zaangażowany w przygotowywanie, zatwierdzenie, zatwierdzenie, wydawanie standardów, ale w swoim formalnym statusie nie ma uprawnień do zaakceptowania takich dokumentów jako standardów międzynarodowych lub krajowych. Dlatego termin "standardowy" w zrozumieniu IEEE raczej oznacza "specyfikację", co więcej odpowiada statusowi dokumentów podjętych przez Stowarzyszenie. Zgodnie z IEEE uczestniczy w programach wielu organizacji międzynarodowych i regionalnych - IEC, ISO, ITU (Europejskie Instytut Telekomunikacji Telekomunikacyjnej Standarizacji elektrotechnicznej) oraz w programach krajowych, takich jak program takiej organizacji, jak ANSI.

Ieee obejmuje Pasc (Przenośne Komitet Standardów aplikacji; www.pasc.org/) - Komitet Stowarzyszenia, który rozwija rodzinę rodziny Posix. Wcześniej Pascc był znany jako Komitet Techniczny ds. Operacji.

Drugim uczestnikiem pracy - ANSI (American National Standards Institute, American National Standards Institute; www.ansi.org) - prywatna organizacja non-profit, która zarządza i koordynuje w Stanach Zjednoczonych w sprawach Normalizacyjnych. Zatrudnia tylko 75 osób, ale członkowie Ansi są ponad 1000 firm, organizacji, agencji rządowych i instytucji. Ansi reprezentuje Stany Zjednoczone w dwóch głównych organizacjach międzynarodowych standaryzacji - ISO i IEC.

Trzeci uczestnik - Iso. Międzynarodowa Organizacja Normalizacyjna, Międzynarodowa Organizacja Normalizacyjna; www.iso.org). Został utworzony w 1946 r. Na decyzję o koordynacji standardów i Zgromadzenia Ogólnego ONZ i oficjalnie rozpoczął pracę 23 lutego 1947 r. ISO jest siecią krajowych instytucji normalizacyjnych z 146 krajów (jeden kraj - jeden członek ISO) z Sekretariatem Środkowym w Genewie (Szwajcaria). Normy ISO są opracowywane w komitetach technicznych, którego pierwszy wynik jest projektem międzynarodowym standardowym dokumentem (DIS), obracając się po kilku dopasowaniu w wersji końcowej Międzynarodowej Standard (FDIS). Po tym kwestia zatwierdzenia tego dokumentu jest przeznaczona do głosowania; Przy pozytywnym wyniku staje się standardem międzynarodowym.

Wreszcie, - 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 standardy dla wszystkich technologii elektrycznych, elektronicznych i powiązanych. Od 1 listopada 2004 r. Krajowe komisje 64 krajów były ważnymi członkami tej Komisji. IEC publikuje również zalecenia, które wychodzą w języku angielskim i francuskim oraz wykonywać status międzynarodowych standardów. Opierają się na standardach regionalnych i krajowych. Komitety techniczne (TC) są odpowiedzialne za przygotowanie standardów w różnych dziedzinach działań IEC, a także zaangażowane są również komitety krajowe zainteresowane działalnością TC.

IEC. - Kluczowa organizacja w przygotowaniu międzynarodowych standardów technologii informacyjnej. Obszar ten ma wspólny komitet techniczny w sprawie technologii informacyjnej - JTC 1 utworzonego w 1987 r. Zgodnie z Umową między IEC i ISO. JTC1 ma 17 podkomitetów, którzy nadzorują cały rozwój - z oprogramowania do programowania języków, grafiki komputerowej i obrazów edycji, połączenia sprzętu i metod bezpieczeństwa.

Przygotowanie nowych standardów IEC obejmuje kilka etapów (wstępnych, etapów dostaw, przygotowawczych, etapie komitetu technicznego, etap żądania, zatwierdzenia, publikacji). Jeśli planuje się, że dokument IEC będzie tylko specyfikacją techniczną, a nie międzynarodową normą, zmieniona wersja dokumentu jest wysyłana do Centralnego Urzędu do publikacji. W celu rozwoju ostatecznego projektu standardu międzynarodowego (FDIS) podano cztery miesiące. Jeśli zatwierdzono wszystkich członków Komitetu Technicznego, przechodzi do Centralnego Urzędu Publikowania bez etapu zatwierdzania FDIS. Następnie FDIS spada do komisji krajowych, aby zatwierdzić go w ciągu dwóch miesięcy. FDIS jest uważany za zatwierdzony, jeśli więcej niż dwie trzecie komisji krajowych głosowało na niego, a liczba głosów negatywnych nie przekracza 25%. Jeśli dokument nie zostanie zatwierdzony, jest wysyłany do zmiany komitetów technicznych i podkomitetów. Standard musi być publikowany nie później niż dwa miesiące po zatwierdzeniu FDIS.

Kilka kolejnych organizacji związanych z rozwojem i przyjęciem standardów POSIX.

Otwarta grupa. - Międzynarodowa Organizacja Normalizacji Oprogramowania, która łączy prawie 200 producentów i społeczności użytkowników pracujących w dziedzinie technologii informacyjnej (www.opengroup.org/) .Opengroup został utworzony w 1995 roku, łącząc dwa poprzedniki: X / Open i Open Software Foundation ( OSF). Open Group specjalizuje się w opracowywaniu metodologii certyfikacji oprogramowania i testowania zgodności z określonymi wymaganiami. W szczególności otwartą grupę jest certyfikowany dla obszarów takich jak platforma COE, Corba, LDAP, Standardowa baza standardowa Linux, Ramy interoperacyjności szkół (SIF), S / Mime Gateway, specyfikacja pojedynczego UNIX, specyfikacje protokołu aplikacji bezprzewodowej (WAP) i wreszcie Rodzina Posix Standardy (www.opengroup.org/certification/).

AustincommonstandardsRevisionGroup (CSRG) - Zjednoczona grupa robocza techniczna utworzona w grupie ISO 2002 ISO, IEC i Open, aby utworzyć i utrzymywać najnowsze wersje standardu 1003.1, które zostaną utworzone na podstawie ISO / IEC 9945-1-1996, ISE / IEC 9945-2-1993 , IEEE STD 1003.1-1996, IEEE STD 1003.2-1992 i specyfikacja pojedynczego UNIX (www.opengroup.org/press/14nov02.htm).

Krajowy Instytut Standardów i Technologii (NIST) - Agencja Federalna przestrzegała Administracji Technologii Departamentu Commerce (www.nist.gov/Public_affairs/geneal2.htm), założona w Stanach Zjednoczonych w 1901 r. Zadaniem NIST jest rozwój i propaganda standardów i technologii w celu poprawy jakości produktu. NIST obejmuje laboratorium technologii informacyjnej. Laboratorium technologii informacyjnej - ITL)Jednym z wyników jest federalne standardy przetwarzania informacji (federalne standardy przetwarzania informacji - FIPS, www.opengroup.org/testing/fips/general_info.html).nist/itl oferowane w 1991 r. Początkowy zestaw testów dla certyfikacji POSIX w 1991 roku W ramach FIPS PUB 151-1 1990.

Co to jest posix?

Formalnie termin POSIX. proponowany przez Richarda Stallmana (Richard Stallman) jako skrót P.ortowy. O.zarabiać S.interfejs Systemu dla ONZ Ix. (Przenośny interfejs systemów operacyjnych dla UNIX). Posix został opracowany dla systemów operacyjnych podobnych do UNIX (ich pierwsze wersje liczą od początku lat siedemdziesiątych) w celu zapewnienia przenośności aplikacji na poziomie kodu źródłowego.

Początkowy opis interfejsu został opublikowany w 1986 roku, wtedy nazywano IEEE-IX (wersja UNIX IEEE). Jednak nazwa szybko się zmieniła, obracając się do Posix, a już w następnej publikacji (z powrotem w 1986) Ta nowa wersja została użyta. Przez pewien czas pod Posix, odniesienie (lub synonim) rozumiano jako grupę IEEE 1003.1-1988 powiązanych dokumentów i części ISO / IEC 9945, oraz jako kompletny i zatwierdzony międzynarodowy ISO / IEC Standard 9945.1: 1990 Posix został przyjęty 1990. Specyfikacje POSIX definiują standardowy mechanizm interakcji między programem aplikacji a systemem operacyjnym i obejmuje obecnie więcej niż 30 standardów pod auspicjami IEEE, ISO, IEC i ANSI.

W swojej historii, POSIX minęło wielki sposób, podczas gdy wiele razy zmieniło oznaczenia specyfikacji, ich konkretnych treści, procedur i logistyki ich weryfikacji. W ciągu ostatniego czasu wystawiono kilka edycji standardu POSIX w różnych organizacjach międzynarodowych.

Historia rozwoju standardowego 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. Redakcja wydana w 1988 roku została przeprojektowana i stała się podstawą dalszych edycji i uzupełnień. Został zatwierdzony jako międzynarodowy standard ISO / IEC 9945-1: 1990.

- 1993. Nadchodzi redakcja 1003,1B-1993.

- 1996. IEEE STD 1003.1B-1993, IEEE STD 1003.1C-1995 i 1003.1I-1995 r., Ale główna część dokumentu pozostała niezmieniona. W 1996 r. Edycja IEEE STD 1003.1 została również zatwierdzona jako międzynarodowa norma ISO / IEC 9945-1: 1996.

- 1998. Jest pierwszy standard "w czasie rzeczywistym" - IEEE STD 1003.13-1998. Jest to ekspansja standardu POSIX dla wbudowanych aplikacji w czasie rzeczywistym.

- 1999. Postanowiono podjąć istotne zmiany w głównym tekście normy przez ostatnie 10 lat, w tym zjednoczenie ze standardem 1003.2 (powłoki i narzędzia), ponieważ przez tę chwilę były to osobne standardy. PASC postanowił zakończyć zmianę podstawowego tekstu po zakończeniu standardów IEEE 1003.1A, 1003.1D, 1003,1 g, 1003.1j, 1003.1Q i 1003,2b.

- 2004. Ostatnie dzisiaj Rada Redakcyjna 1003,1 została opublikowana 30 kwietnia i została wydana pod auspicjami Grupy Rewizji Wspólnej Standardów Austin. Wprowadzono zmiany w Radzie Redakcyjnej 2001 r. Formalnie, Redakcja 2004 r. Jest znana jako IEEE STD 1003.1, 2004 Edition, standardowe specyfikacje podstawowe Grupy IEEE, wydanie 6 i obejmuje IEEE STD 1003,1-2001, 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 RV OS

W przypadku systemów operacyjnych w czasie rzeczywistym najważniejsze są siedem standardowych specyfikacji, ale tylko trzy były szeroko wspierane w komercyjnym OS:

1003.1a (definicja OS) określa podstawowe interfejsy systemu operacyjnego, zarządzania zadaniami, sygnałami, funkcjami system plików i pracować z urządzeniami, grupami użytkowników, przenośnikami, buforami FIFO;

1003.1b (rozszerzenia w czasie rzeczywistym) opisuje rozszerzenia w czasie rzeczywistym, takie jak sygnalizacja w czasie rzeczywistym, wysyłanie priorytetowe, timery, wejście synchroniczne i asynchroniczne, semafory, pamięć współdzielona, \u200b\u200bwiadomości. Początkowo (do 1993 r.) Norma ta została wskazana jako POSIX.4;

1003,1c (wątki) Definiuje funkcje wsporcze strumieniowe (wątki) - Kontrola przepływu, atrybuty strumienia, Muteks, wysyłanie. Pierwotnie wyznaczony jako POSIX.4A.

Oprócz tych standardów następujące normy są ważne dla RV, które zostały wdrożone w ramach projektu STD 1003.1-2001:

IEEE 1003.1D-1999. Dodatkowe rozszerzenia czasu rzeczywistego. Początkowo wyznaczony jako POSIX.4B;

IEEE 1003.1J-2000. Ulepszona (zaawansowana) rozszerzalność w czasie rzeczywistym;

IEEE 1003.1Q-2000. Rysunek kalkowy.

Procedura certyfikacji

Aby spełnić standardowy standard, system operacyjny musi być certyfikowany zgodnie z wynikami odpowiedniego zestawu testowego. Od wyglądu Posix zestaw testowy podlegał formalnemu i rzeczywistym zmianom.

W 1991 roku NIST opracował program testowy POSIX w FIPS 151-1 (http://poss.ieee.org/regauth/posix/posix-a.fm5.pdf). Ta opcja testowania była oparta na IEEE 1003.3 "Standard dla metod testowych do pomiaru zgodności z POSIX" Draft 10, 3 maja 1989 r. W 1993 r. Nist absolwent z programu testowego dla FIPS 151-1 i rozpoczął program do FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm).fips 151-2 Dostosowane "Technology informacyjne - Przenośny interfejs systemu operacyjnego (POSIX) - Część 1: Interfejs programu aplikacji systemu (API)," Audio ISO / IEC 9945-1: 1990 Standard. Zestawy testowe dla FIPS 151-2 opierały się na IEEE 2003.1-1992 "Standard dla metod testowych do pomiaru zgodności z POSIX".

NIST wyróżnia dwie metodologie certyfikacji: samodzielne certyfikacja (samo certyfikacja) i certyfikacja akredytowana w laboratoriach testowych IEEE (akredytowane laboratoria testowe POSIX - APTL). W pierwszym przypadku firma prowadzi testowanie niezależnie, ale zgodnie z planem zatwierdzonym w NIST. W drugim przypadku testowanie przeprowadza się przez niezależne laboratorium przy użyciu automatycznych zestawów testowych. Dwie laboratoria APTL zostały akredytowane: Mindcraft (www.mindcraft.com) i wieloletnie (www.peren.com).

W 1997 r. NIST / ITL ogłosił zamiar zakończenia certyfikacji dla FIPS 151-2 na koniec bieżącego roku (oficjalnie - 31 grudnia 1997 r.), Jednocześnie Otwarta Grupa ogłosiła, że \u200b\u200bweźmie udział 1 października Rok Usługi Certyfikacji zgodnie z FIPS 151-2, na podstawie programu NIST / ITL. Te same funkcje od 1 stycznia 1998 r. Zakłada Stowarzyszenie Normalizacyjne IEEE (IEEE-SA), a także oparte na FIPS 151-2.

W 2003 r. IEEE-SA i Otwarta Grupa ogłosiła początek nowego wspólnego programu do certyfikacji ostatnich wersji Posix, począwszy od IEEE 1003.1 (TM) 2001. Teraz Open Group ma kilka testów, które obejmują 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 jest uważany za certyfikowany przez POSIX, jeśli przekazał pełną procedurę certyfikacji, zgodnie z wynikami testu, spełnia ona wszystkie prezentowane wymagania i jest wymieniony w oficjalnym rejestrze certyfikowanych produktów.

Zestawy testowe obejmują:

VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - zestaw testów zgodności dla 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 Profil PSE54 (wielofunkcyjny czas w czasie rzeczywistym);

VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - zestaw testów zgodności dla interfejsów systemu IEEE STD 1003.1-2003 (tylko obowiązkowe części);

VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vsCPCTS2003.htm) - zestaw testów zgodności dla IEEE STD 1003.1-2003 (powłoki i narzędzia - tylko części obowiązkowe).

Ponadto Open Group opracował testy dla standardów Posix RealTime i Embedded Posix Standards Profil. Zestaw testów dla Posix Realtime (www.opengroup.org/testing/testsuites/Realtime.html) zawiera następujące testy:

Ieee Posix 1003.1B-1993 / 1003.1I-1995 Rozszerzenie realtime i IEEE Posix 1003.1.2003 Edycja;

IEEE STD POSIX 1003.1C-1995 Nici (Pthreads) Extension i IEEE Posix 1003.1.2003 Edition;

IEEE POSIX 1003.1D-1999 Dodatkowe rozszerzenie realtime i IEEE Posix 1003.1.2003 Edition;

Ieee Posix 1003.1J-2000 Advanced RealTim Extension i IEEE Posix 1003.1.2003 Edition;

Ieee Posix 1003.1Q-2000 Trace i IEEE Posix 1003.1.2003 Edycja i IEEE Posix 1003.1.2003 Edition;

Zestaw testów profili w Embedded Posix (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 Przedłużenie realtime (1430 testów);

IEEE STD Posix 1003.1c-1995 Nici (Pthreads) Przedłużenie (test 1232);

IEEE POSIX 1003.13-1998 Profil 52.

Trochę o zamieszaniu w terminologii

W odniesieniu do grupy standardów POSIX w języku angielskim, a nie jednym, ale aż do trzech warunków. Niestety, są one podobne w wartości i są często tłumaczone w równym stopniu, co przynosi pewne zamieszanie. Terminy to:

Kompatybilność (dosłownie "kompatybilność");

Zgodność (dosłownie "zgodność");

Sonformance (dosłownie "spójność").

Pierwszy termin zastosowany do POSIX nie jest formalnie zdefiniowany. Drugi oznacza, że \u200b\u200borganizacja jest producentem oprogramowania niezależnie oświadcza, że \u200b\u200bten produkt (w pełni lub częściowo) spełnia następujące normy NIST-PCTS. Trzeciarzysty sugeruje, że oprogramowanie minęło zainstalowany system. Testy za pomocą akredytowanego laboratorium lub w ramach grupy otwartej i ma to potwierdzenie dokumentalne (tzw. Oświadczenie zgodności). Dalej w tekście artykułu wszędzie będą oryginały warunków do wykluczenia dwuznaczności.

Certyfikowany OS RV.

Jeśli stosujesz ścisłe zasady wymagające, aby dane dotyczące certyfikowanego OS RV zostały opublikowane w oficjalnym rejestrze i testowaniu przeprowadzono przez poziom zgodność.Obecnie masz tylko dwa certyfikowane OS RV (dane są podane w porządku chronologicznym):

- Lynxos V.3. (Produkt firmy Lynx Systemy w czasie rzeczywistym, które są teraz nazywane Lynuksworks, Inc., www.lynoxworks.com) jest przeznaczone do opracowywania wbudowanych systemów działających w trudnych producentów w czasie rzeczywistym, producentów sprzętu kompletnego i telekomunikacyjnego, W szczególności producenci systemów pokładowych stosowania wojskowego. Rozwój może być przeprowadzany zarówno w systemie docelowym (samodzielnie), jak i na komputerze narzędziowym (host), gotowy do zaprojektowania do pracy w systemie docelowym (Cel). Lynxos V.3 jest certyfikowany dla spójności (Zgodność)pOSIX Standard na platformie Intel i PowerPC. Informacje o tym można znaleźć na stronie internetowej IEEE http://posix/posix.org/regauth/posix/osix2.html.lynxos certyfikowany przez POSIX 1003.1-1996 Mindcraft, który jest IEEE Posix Akredytowany Posix Testing Laboratorium dla FIPS NIST 151 Testy 2 test badania zgodności. Numer dokumentu potwierdzający certyfikat: Plik odniesienia: IP-2LYX002, plik referencyjny: IP-2LYX001.

- Integralność V.5. (Produkt oprogramowania firmy Green Hills, www.ghs.com) jest certyfikowane dla spójności (Zgodność) Przez Posix 1003.1-2003, interfejsy systemowe dla architektury PowerPC w lipcu 2004 r. (Http://get.posixCertyfikowany.ieee.org/select_product.tpl). Zestaw testów VSX-PCT 2003.

System operacyjny POSIX i QNX

QNX V.4.20.(Deweloper - firmy Systemy oprogramowania QNX, www.qnx.com) Certyfikowane za zgodność (SPEŁNIENIE) POSIX 1003.1-1988 dla platformy Firma Intel. Datafocus włączony. Testowanie przeprowadzono 13 września 1993 r., Data wydania dokumentu - 1 listopada 1993 r. Zestaw testów NIST PCTS 151-1, wersja 1.1.

QNX Neutrino (wersja 6.3) jest zgodna (spełnia) następne standardy rodziny POSIX (www.qnx.com/download/download/8660/portowal.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).

Systemy oprogramowania QNX, twórca QNX Neutrino planuje również certyfikację (zgodność) QNX neutrino zgodnie z niektórymi z tych standardów; Prace są zaplanowane na 2005 r. (Www.qnx.com/news/pr_959_1.html).

Literatura

1. Instrukcja obsługi standardów IEEE. IEEE, październik 2004 r.

2. Kevin M. Ogeland.. Posix w czasie rzeczywistym, programowanie systemów wbudowanych, 2001.

3. IEEE / ANSI Standard 1003.1: Technologia informacyjna - (Posix) - Part1: Aplikacja systemowa: interfejs programu (API).

4. Galmeister B. O. Programowanie dla prawdziwego świata, POSIX.4 Sebastopol, CA: O'Reilly & Associates, 1995.

5. Krajowy Instytut Standardów i Technologii PCTS: 151-2, Posix Posuście testowe.

6. POSIX: certyfikowany przez IEEE i otwartą grupę. Certyfikowana polityka. Grupa Open, 21 października 2003 r., Revision 1.1.

Oprogramowanie) - zadanie wyjątkowego znaczenia i złożoności; Obecnie ta okoliczność nie wymaga obszernych uzasadnień. Jednym z ogólnie przyjętych sposobów poprawy mobilności oprogramowania jest standaryzacja środowiska zastosowań: interfejsy programowania dostarczone, narzędzia itp. Na poziomie usługi systemowe. Podobne środowisko opisuje standard POSIX (przenośny interfejs systemu operacyjnego - mobilny interfejs systemu operacyjnego); Nazwa zaproponowana jest przez znanego specjalistę, założyciel Foundation Free Software Foundation Richard Tornen.

Będziemy rozważyć najnowocześniejsze z dostępnych wersji standardu POSIX, zmieniony 2003, który można nazwać "Standard Triple", a mianowicie: IEEE STD 1003.1 Standard, Standard techniczny Otwórz grupę i (patrz [6]), który jest dla nas najważniejszy, międzynarodowy standard ISO / IEC 9945 (patrz [1], [2], [3], [4]).

Historia tworzenia tej wersji jest taka. Na początku 1998 r. Przedstawiciele trzech organizacji - Komitet ds Mobilnych Standardów Instytut Inżynierów Inżynierii Elektrotechnicznej i Instytutu Elektroniki, Otwarty Grupy Roboczej 15 podkomitetu 22 Wspólnego Komitetu Technicznego 1 (JTC1 / SC22 / WG15) Międzynarodowej Organizacja standaryzacji - rozpoczął konsultację na temat połączenia i rozwoju standardów interfejsu nadzorowanych przez nich do usług systemowych: IEEE STD 1003.1, IEEE STD 1003.2, podstawowe specyfikacje z grupy otwartej, ISO / IEC 9945-1, ISO / IEC 9945-2. We wrześniu tego samego roku w mieście Austin, Teksas, spotkanie organizacyjne grupy utworzonej w celu osiągnięcia celu (patrz http://www.opengroup.org/austin) odbył się w biurze IBM.

Podstawowy dokument w ramach zmienionego standardu, którego pierwszy projekt został przedstawiony w lipcu 1999 r., Były podstawowe specyfikacje Grupy Open, ponieważ obejmowały one postanowienia norm IEEE i ISO / IEC. W 2001 r. Po zakończeniu prac przygotowawczych, standard zawierał następujące cztery części:

  1. główne definicje (warunki, koncepcje i interfejsy wspólne dla wszystkich części);
  2. opis aplikacja C-Interface do usług systemowych;
  3. opis interfejsu do usług systemowych na poziomie język poleceń i programy serwisowe ;
  4. szczegółowe wyjaśnienie standardowych przepisów, uzasadnienie podjętych decyzji.

Dalej w ISO, IEEE i otwartej grupie z większą lub mniejszą prędkością (w latach 2001-2002) minęło formalne zatwierdzenie nowego standardu POSIX. W międzyczasie gromadzono stosunkowo niewielkie korekty, uwzględnione w 2003 roku.

Wraz z rozwojem standardu interpretacja terminu "POSIX" rozszerzała się. Początkowo odnosi się do IEEE STD 1003,1-1988, opisany interfejs programu aplikacji. Klasa OS UNIX. Po standaryzacji interfejsu na poziomie języka poleceń i programów serwisowych jest bardziej prawidłowo rozumiany w ogólnym słowie "POSIX" Standard ogólnie, oznaczający część 2 i 3 wymienione powyżej przez POSIX .1 i POSIX .2 zgodnie z numerami Dokumenty IEEE i ISO / IEC.

Główne idee standardu POSIX

Standard POSIX opisuje wiele podstawowych, systemowych usług wymaganych do funkcjonowania aplikacji. Dostęp do nich jest dostarczany przez interfejs określony dla C, języka poleceń i wspólnych programów serwisowych.

Każdy interfejs ma dwie strony: powodując i wywołany. Standard POSIX jest przede wszystkim zorientowany na dzwonienie. Jego celem jest tworzenie aplikacji mobile na poziomie języka źródłowego. Oznacza to w szczególności, że podczas przenoszenia programów C. do innej platformy operacyjnej wymagane będzie rekompulacja. O mobilności programów wykonywalnych i / lub plików obiektów nie ma znaczenia.

Standard POSIX nie jest ograniczony do ram środowiska UNIX. Istnieją systemy operacyjne (OS) "Independent Origin" (na przykład, systemy w czasie rzeczywistym), zapewniając niezbędne usługi, a tym samym wspierające wykonanie aplikacji POSIX. Można argumentować, że zgodnie ze standardem POSIX ułatwia transfer aplikacji do niemal każdej wspólnej platformy operacyjnej. Dodatkowe wysiłki na rzecz poprawy mobilności załączonej podczas fazy rozwoju na pewno spłacą się.

Określenie interfejsu do usług systemowych, POSIX opuszcza ramy ich wdrażania. W szczególności nie rozróżniać połączenia systemowe. i funkcje biblioteki.. Nie są przedmiotem środków normalizacyjnych administracja, ograniczenia sprzętowe i funkcje tylko niezbędne super następcaCo jeszcze raz podkreśla skupienie standardu

Dzisiaj postaramy się dowiedzieć, co opisuje standard POSIX. Standardy mają na celu zapewnienie, że mój komputer może wchodzić w interakcję ze sobą. Dzięki nim na dwóch podobnych komputerach internetowych lub transmisji wideo w czasie rzeczywistym będzie wyglądać równie.

Jednak standard jest przeznaczony dla większych zadań niż prosta wymiana danych między użytkownikami. Niektóre standardy definiują specjalny model, dzięki któremu funkcji, które są znacznie lepsze w ich wartości kompatybilności plików lub sieci. Standard POSIX odnosi się do ich liczby.

Co to jest posix?

POSIX (wymawiane "Posiks") jest przenośnym interfejsem systemu operacyjnego. Ale co to oznacza? Po pierwsze, musisz wyznaczyć obszar koncepcji "przenośności", w tym betonowa obudowai zdecydować o koncepcji "interfejsu". Aby dowiedzieć się to, konieczne jest odpychanie od faktu, że oba koncepcje są nierozerwalnie związane.

"Przenośność", w kontekście standardu POSIX, odnosi się do kod źródłowy (Nie do binarnego, który zebrano z tych samych źródeł). Teraz dowiedz się, co jest "interfejs". W programowaniu "interfejs" jest interakcją twojego kodu z resztą kodu. Interfejs czeka na zapewnienie konkretnych informacji z kodu. Twój kod z kolei obejmuje uzyskanie pewnych informacji z interfejsu. Dobry przykład - Funkcja Fopen () w SI. Oczekuje, że informacje z dwóch części: ścieżki do pliku i trybu, w którym zostanie otwarty. Korzystając z tych danych, system operacyjny zwraca inny typ informacji o nazwie "Deskryptor plików". Uchwyt pliku można użyć do odczytywania pliku lub zapisu do pliku. To jest interfejs. Z tego wszystkiego wynika z tego, że kod kompatybilny POSIX może być kompilowany w dowolnym systemie operacyjnym kompatybilnym z POSIX bez dużych zmian, co oznacza, że \u200b\u200bbędzie przenośny.

Lista interfejsów dotyczących standardu POSIX jest jednak nawet pomimo jego ogromnej długości, możliwe jest, że jest niedobór. POSIX nie ogranicza się do wyzwań systemowych, definiuje również standardy do skorupy systemów operacyjnych (półek, inaczej - interfejsy wiersz poleceń), Narzędzia systemowe, takie jak "awk" lub "echo", biblioteki systemowe i wiele innych rzeczy.

Standard POSIX pojawił się w formie projektu Richarda Pokalmana w 1985 r. I był dalej urządzony jako IEEE STD 1003.-1998. Jak widać z nazwy, 1998 był rokiem oficjalnej publikacji. Od tego czasu zwolniono dużą liczbę dodatków i rozszerzeń dla Posix, które stopniowo zamienia się w całą rodzinę standardów, formalnie znany jako IEEE 1003, uznany za międzynarodowy, przy oznaczeniu SO / IEC 9945, po prostu nazywany Posixem Standard rodzinny.

System operacyjny nie jest wcale niezbędny do bycia kompatybilnym POSIX lub jeszcze bardziej posiadającym certyfikat POSIX, jednak umożliwia programistom tworzenie aplikacji, narzędzi i platform, bez przepisywania kodu raz na czas, ale tylko uzupełnić i łączą się z gotową do -koniec. Nie trzeba również napisać kod kompatybilny z POSIX w ogóle, ale znacznie poprawia przenośność projektów między systemami operacyjnymi. Oznacza to, że możliwość napisania kodu zgodnego z standardem POSIX jest wartościowy sam w sobie, a na pewno bardzo przydatny do kariery. Duże projekty, takie jak GNOME lub KDE, przylegają do standardu POSIX, co gwarantuje ich pracę na różnych systemach operacyjnych. Podsystem POSIX jest zaimplementowany nawet w ostatnie problemy Okna. Linux, jak wiesz, obsługuje większość połączeń systemowych związanych ze standardem POSIX, a także dużym rozszerzeniem, zwanym "Standardową bazą Linux", która jest przeznaczona do łączenia dystrybucji Linuksa pod względem obsługi kodu źródłowego i danych binarnych .

Mam nadzieję, że rzuciliśmy światło do pytania "Co to jest posix". Mieć interesujące informacje na ten temat? Podziel się nim w komentarzach.

POSIX i OS RV: Próba systematyzacji

Sergey Zolotarev, Nikolai Gorbov

Celem tego artykułu jest próbę dokonania pewnej jasności w historii rozwoju standardu POSIX w odniesieniu do systemów operacyjnych w czasie rzeczywistym (OS RV).

Jako wprowadzenie: Dlaczego potrzebujesz standaryzacji interfejsu programowania?

Jednym z najważniejszych właściwości standardu POSIX jest to, że określa "znormalizowany interfejs programowania", który deweloperzy złożonego oprogramowania i systemów sprzętowych powinny przestrzegać programistów. Twórcy tych systemów są zmuszeni stawić czoła takim wymaganiom jako krótki czas wejścia na rynek (ze względu na sztywną konkurencję), minimalizując koszty i przyspieszenie zwrotu inwestycji. Jednocześnie udział wydatków Liona spowodowany spowolnieniem procesu rozwoju jest związane z faktem, że programowani muszą "wymyślić rower", ponownie i ponownie wdrażać funkcjonalność, która od dawna dostępna. Ale można to uniknąć przez:

  • kod ponownego użycia z poprzednich i równoległych projektów;
  • przeniesienie kodu z innego systemu operacyjnego;
  • przyciąganie deweloperów z innych projektów (w tym za pomocą innego systemu operacyjnego).

Wszystko to jest możliwe dzięki zastosowaniu systemu operacyjnego ze standardowym API. Ponadto, jeśli w pierwszym przypadku organizacja wystarczy, aby mieć pewną normę wewnętrzną (która jest szczególnie charakterystyczna dla marki OS), a drugie dwa przypadki są po prostu wymagające dostępności ogólnie przyjętych standardów - na przykład, posix.

Tak więc, przy użyciu systemu operacyjnego POSIX jako platformy dla swoich projektów, deweloper jest w stanie przenieść gotowy kod na poziomie kodu źródłowego, jak z przeszłych lub równoległych projektów oraz z projektów innych firm. Nie tylko znacząco zmniejsza czas rozwoju oprogramowania, ale także poprawia jakość, ponieważ sprawdzony kod zawsze zawiera mniej błędów.

Kto jest kim w rozwoju Posix

I zacznijmy od bardzo standardowego POSIX, ale w celu zamawiania rolę organizacji zaangażowanych w działanie nad tym.

Pierwszym uczestnikiem jest Ieee. Instytut Inżynierów Elektryk i Elektronicznych, Instytut Inżynierów Elektryk i Elektroniki), Publiczne Stowarzyszenie Non-Zysk Specjaliści. IEEE prowadzi swoją historię od 1884 r. (Formalnie - od 1963 r.), Łączy 380 000 członków indywidualnych z 150 krajów, publikuje trzecią część literatury technicznej dotyczącej korzystania z komputerów, zarządzania, technologii elektrycznych i informacyjnych, a także ponad 100 magazynów, popularne w środowisku profesjonalistów; Ponadto Stowarzyszenie jest rocznie ponad 300 głównych konferencji. Ieee uczestniczył w rozwoju ponad 900 istniejących standardów (www.ieee.ru/ieeee.htm). Obecnie Instytut ten jest zaangażowany w przygotowywanie, zatwierdzenie, zatwierdzenie, wydawanie standardów, ale w swoim formalnym statusie nie ma uprawnień do zaakceptowania takich dokumentów jako standardów międzynarodowych lub krajowych. Dlatego termin "standardowy" w zrozumieniu IEEE powinien być rozumiany jako "specyfikacja", który jest bardziej odpowiedzialny za status dokumentów podjętych przez Stowarzyszenie. Zgodnie z IEEE uczestniczy w programach wielu organizacji międzynarodowych i regionalnych - IEC, ISO, ITU (Europejskie Instytut Telekomunikacji Telekomunikacyjnej Standarizacji elektrotechnicznej) oraz w programach krajowych, takich jak program takiej organizacji, jak ANSI.

IEEE obejmuje PASC (Przenośne Komitet Standardów Aplikacji) - Komitet Stowarzyszenia, który rozwija rodzinę standardów POSIX (www.pasc.org/). Wcześniej Pascc był znany jako Komitet Techniczny ds. Operacji.

Drugi uczestnik pracy - Ansi. (American National Standards Institute, American National Standards Institute) - prywatna organizacja non-profit, która zarządza i koordynuje w Stanach Zjednoczonych w sprawach normalizacyjnych. Zatrudnia tylko 75 osób, ale członkowie ANSI to ponad 1000 firm, organizacje, agencje rządowe i instytucje (www.ansi.org). Ansi reprezentuje Stany Zjednoczone w dwóch głównych organizacjach międzynarodowych standaryzacji - ISO i IEC.

Trzeci uczestnik - Iso. Międzynarodowa Organizacja Normalizacji, Międzynarodowa Organizacja Standardizacji). Został utworzony w 1946 r. Decyzją Komitetu koordynacji norm i Zgromadzenia Ogólnego ONZ i oficjalnie rozpoczął pracę 23 lutego 1947 r. (Www.iso.org). ISO jest siecią krajowych instytucji normalizacyjnych z 146 krajów (jeden kraj jest jednym członkiem ISO) z Sekretariatem Środkowym w Genewie (Szwajcaria). Normy ISO są opracowywane w komitetach technicznych, którego pierwszy wynik jest projektem międzynarodowym standardowym dokumentem (DIS), obracając się po kilku dopasowaniu w wersji końcowej Międzynarodowej Standard (FDIS). Po tym kwestia zatwierdzenia tego dokumentu jest przeznaczona do głosowania; Przy pozytywnym wyniku staje się standardem międzynarodowym.

Wreszcie, - IEC. Międzynarodowa Komisja Elektrotechniczna, Międzynarodowa Komisja Elektrotechniczna - IEC), założona w 1906 r. IEC przygotowuje i publikuje międzynarodowe standardy dla wszystkich technologii elektrycznych, elektronicznych i powiązanych (www.iec.ch/). Od 1 listopada 2004 r. Krajowe komisje 64 krajów były ważnymi członkami tej Komisji. IEC publikuje również zalecenia, które wychodzą w języku angielskim i francuskim oraz wykonywać status międzynarodowych standardów. Opierają się na standardach regionalnych i krajowych. Komitety techniczne (TC) są odpowiedzialne za przygotowanie standardów w różnych dziedzinach działań IEC, a także zaangażowane są również komitety krajowe zainteresowane działalnością TC.

IEC jest kluczową organizacją w przygotowaniu międzynarodowych standardów technologii informacyjnej. Obszar ten ma wspólny komitet techniczny w sprawie technologii informacyjnej - JTC 1 utworzonego w 1987 r. Zgodnie z Umową między IEC i ISO. JTC1 ma 17 podkomitetów, którzy nadzorują cały rozwój - z oprogramowania do programowania języków, grafiki komputerowej i obrazów edycji, połączenia sprzętu i metod bezpieczeństwa.

Przygotowanie nowych standardów IEC obejmuje kilka etapów (wstępnych, etapów dostaw, przygotowawczych, etapie komitetu technicznego, etap żądania, zatwierdzenia, publikacji). Jeśli planuje się, że dokument IEC będzie tylko specyfikacją techniczną, a nie międzynarodową normą, zmieniona wersja dokumentu jest wysyłana do Centralnego Urzędu do publikacji. W celu rozwoju ostatecznego projektu standardu międzynarodowego (FDIS) podano cztery miesiące. Jeśli zatwierdzono wszystkich członków Komitetu Technicznego, przechodzi do Centralnego Urzędu Publikowania bez etapu zatwierdzania FDIS. Następnie FDIS spada do komisji krajowych, aby zatwierdzić go w ciągu dwóch miesięcy. FDIS jest uważany za zatwierdzony, jeśli więcej niż dwie trzecie komisji krajowych głosowało na niego, a liczba głosów negatywnych nie przekracza 25%. Jeśli dokument nie zostanie zatwierdzony, jest wysyłany do zmiany komitetów technicznych i podkomitetów. Standard musi być publikowany nie później niż dwa miesiące po zatwierdzeniu FDIS.

Kilka kolejnych organizacji związanych z rozwojem i przyjęciem standardów POSIX.

Otwarta grupa. - Międzynarodowa organizacja standaryzacji oprogramowania, która łączy prawie 200 producentów i społeczności użytkowników pracujących w dziedzinie technologii informacyjnej (www.opengroup.org/). Otwarta grupa została utworzona w 1995 roku, łącząc dwa poprzedniki: X / Open and Open Software Foundation (OSF). Open Group specjalizuje się w opracowywaniu metodologii certyfikacji oprogramowania i testowania zgodności z określonymi wymaganiami. W szczególności otwartą grupę jest certyfikowany dla obszarów takich jak platforma COE, Corba, LDAP, Standardowa baza standardowa Linux, Ramy interoperacyjności szkół (SIF), S / Mime Gateway, specyfikacja pojedynczego UNIX, specyfikacje protokołu aplikacji bezprzewodowej (WAP) i wreszcie Rodzina Posix Standardy (www.opengroup.org/certification/).

Austin Common Standards Group Revision (CSRG) - Zjednoczona grupa robocza techniczna utworzona w grupie ISO 2002 ISO, IEC i Open, aby utworzyć i utrzymywać najnowsze wersje standardu 1003.1, które zostaną utworzone na podstawie ISO / IEC 9945-1-1996, ISE / IEC 9945-2-1993 , IEEE STD 1003.1-1996, IEEE STD 1003.2-1992 i specyfikacja pojedynczego UNIX (www.opengroup.org/press/14nov02.htm).

Krajowy Instytut Standardów i Technologii (NIST) - Agencja Federalna przestrzegała Administracji Technologii Departamentu Commerce (www.nist.gov/Public_affairs/geneal2.htm), założona w Stanach Zjednoczonych w 1901 r. Zadaniem NIST jest rozwój i propaganda standardów i technologii w celu poprawy jakości produktu. NIST zawiera laboratorium technologii informacyjnej (ITL), jednym z wyników działań, które są federalne standardy przetwarzania informacji (federalne standardy przetwarzania informacji - FIPS, www.opengroup.org/testing/fips/general_info.html). NIST / ITL oferowany w 1991 r. Początkowy zestaw testów dla certyfikatu POSIX pod FIPS PUB 151-1 1990.

Co to jest posix?

Formalnie termin POSIX. proponowany przez Richarda Stallmana (Richard Stallman) jako skrót P.ortowy. O.zarabiać S.interfejs Systemu dla ONZ Ix. (Przenośny interfejs systemów operacyjnych dla UNIX). Posix został opracowany dla systemów operacyjnych podobnych do UNIX (ich pierwsze wersje liczą od początku lat siedemdziesiątych) w celu zapewnienia przenośności aplikacji na poziomie kodu źródłowego.

Wstępny opis interfejsu został opublikowany w 1986 roku, wtedy nazywał się IEEE-IX (wersja UNIX IEEE). Jednak nazwa zmieniła się szybko, zmieniając się do Posix, a ta nowa wersja została użyta w następującej publikacji (W 1986 r.) 1990 POSIX został przyjęty w 1990 r. Specyfikacje POSIX definiują standardowy mechanizm interakcji między programem aplikacji a systemem operacyjnym i obecnie obejmuje ponad 30 standardów pod auspicjami IEEE, ISO, IEC i ANSI.

W swojej historii, POSIX minęło wielki sposób, podczas gdy wiele razy zmieniło oznaczenia specyfikacji, ich konkretnych treści, procedur i logistyki ich weryfikacji. W ciągu ostatniego czasu wystawiono kilka edycji standardu POSIX w różnych organizacjach międzynarodowych.

Historia rozwoju standardowego 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.

Redakcja wydana w 1988 r. Została poddana recyklingowi i stała się podstawą dalszych redaktorów i dodatków. Został zatwierdzony jako międzynarodowy standard ISO / IEC 9945-1: 1990.

1993.

Nadchodzi redakcja 1003,1B-1993.

1996.

IEEE STD 1003.1B-1993, IEEE STD 1003.1C-1995 i 1003.1I-1995 r., Ale główna część dokumentu pozostała niezmieniona. W 1996 r. Edycja IEEE STD 1003.1 została również zatwierdzona jako międzynarodowa norma ISO / IEC 9945-1: 1996.

1998.

Jest pierwszy standard "w czasie rzeczywistym" - IEEE STD 1003.13-1998. Jest to ekspansja standardu POSIX dla wbudowanych aplikacji w czasie rzeczywistym.

1999.

Postanowiono podjąć istotne zmiany w głównym tekście standardu w ciągu ostatnich 10 lat, w tym związku ze standardem 1003,2 (powłoki i narzędzia), ponieważ były to oddzielne standardy. PASC postanowił zakończyć zmianę podstawowego tekstu po zakończeniu standardów IEEE 1003.1A, 1003.1D, 1003,1 g, 1003.1j, 1003.1Q i 1003,2b.

2004.

Ostatnie dzisiaj Rada Redakcyjna 1003,1 została opublikowana 30 kwietnia i została wydana pod auspicjami Grupy Rewizji Wspólnej Standardów Austin. Wprowadzono zmiany w Radzie Redakcyjnej 2001 r. Formalnie, Redakcja 2004 r. Jest znana jako IEEE STD 1003.1, 2004 Edition, standardowe specyfikacje podstawowe Grupy IEEE, wydanie 6 i obejmuje IEEE STD 1003,1-2001, 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 RV OS

W przypadku systemów operacyjnych w czasie rzeczywistym, siedem standardowych specyfikacji są najważniejsze (1003.1a, 1003.1j, 1003,1c, 1003.1d, 1003.1j, 1003,21), ale tylko trzy były szeroko wspierane w komercyjnym OS:

  • 1003.1a (definicja systemu OS) Określa podstawowe interfejsy systemu operacyjnego, zarządzania zadaniami, sygnałami, funkcjami i urządzeń i urządzeń do plików, grup użytkowników, przenośników, buforów FIFO;
  • 1003,1b (rozszerzenia w czasie rzeczywistym) Opisuje rozszerzenia w czasie rzeczywistym, takie jak sygnalizacja w czasie rzeczywistym, dyspozytor priorytetowy, timery, synchroniczne i asynchroniczne wejście, semafory, pamięć współdzielona, \u200b\u200bwiadomości. Początkowo (do 1993 r.) Ten standard został wyznaczony jako POSIX.4.
  • 1003,1c (wątki) Definiuje funkcje wsporcze strumieniowe (wątki) - kontrola przepływu, atrybuty strumienia, mutaxes, wysyłanie. Pierwotnie wyznaczony jako POSIX.4A.

Oprócz tych standardów następujące normy są ważne dla RV, które zostały wdrożone w ramach projektu STD 1003.1-2001:

  • IEEE 1003.1D-1999. Dodatkowe rozszerzenia czasu rzeczywistego. Początkowo wyznaczony jako POSIX.4B;
  • IEEE 1003.1J-2000. Ulepszona (zaawansowana) rozszerzalność w czasie rzeczywistym;
  • IEEE 1003.1Q-2000. Rysunek kalkowy.

Procedura certyfikacji

Aby spełnić standardowy standard, system operacyjny musi być certyfikowany zgodnie z wynikami odpowiedniego zestawu testowego. Od wyglądu Posix zestaw testowy podlegał formalnemu i rzeczywistym zmianom.

W 1991 roku NIST opracował program testowy POSIX w FIPS 151-1 (http://poss.ieee.org/regauth/posix/posix-a.fm5.pdf). Ta opcja testowania była oparta na IEEE 1003.3 "Standard dla metod testowych do pomiaru zgodności z POSIX" Draft 10, 3 maja 1989 r. W 1993 r. Nist absolwent z programu testowego dla FIPS 151-1 i rozpoczął program do FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm). FIPS 151-2 Dostosowany "Technologia informacyjna - Przenośny interfejs systemu operacyjnego (POSIX) - Część 1: Interfejs programu aplikacji systemu (API)," ISO / IEC 9945-1: 1990 standard. Zestawy testowe dla FIPS 151-2 opierały się na IEEE 2003.1-1992 "Standard dla metod testowych do pomiaru zgodności z POSIX".

NIST wyróżnia dwie metodologie certyfikacji: samodzielne certyfikacja (samo certyfikacja) i certyfikacja akredytowana w laboratoriach testowych IEEE (akredytowane laboratoria testowe POSIX - APTL). W pierwszym przypadku firma prowadzi testowanie niezależnie, ale zgodnie z planem zatwierdzonym w NIST. W drugim przypadku testowanie przeprowadza się przez niezależne laboratorium przy użyciu automatycznych zestawów testowych. Dwie laboratoria APTL zostały akredytowane: Mindcraft (www.mindcraft.com) i wieloletnie (www.peren.com).

W 1997 r. NIST / ITL ogłosił zamiar zakończenia certyfikacji dla FIPS 151-2 na koniec bieżącego roku (oficjalnie - 31 grudnia 1997 r.), Jednocześnie Otwarta Grupa ogłosiła, że \u200b\u200bweźmie udział 1 października Rok Usługi Certyfikacji zgodnie z FIPS 151-2, na podstawie programu NIST / ITL. Te same funkcje od 1 stycznia 1998 r. Zakłada Stowarzyszenie Normalizacyjne IEEE (IEEE-SA), a także oparte na FIPS 151-2.

W 2003 r. IEEE-SA i Otwarta Grupa ogłosiła początek nowego wspólnego programu do certyfikacji ostatnich wersji Posix, począwszy od IEEE 1003.1 ™ 2001. Teraz Grupa Open ma kilka testów, które obejmują 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 jest uważany za certyfikowany przez POSIX, jeśli przekazał pełną procedurę certyfikacji, zgodnie z wynikami testu, spełnia ona wszystkie prezentowane wymagania i jest wymieniony w oficjalnym rejestrze certyfikowanych produktów.

Zestawy testowe obejmują:

  • VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - zestaw testów zgodności dla 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 Profil PSE54 (wielofunkcyjny czas w czasie rzeczywistym);
  • VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - zestaw testów zgodności dla interfejsów systemu IEEE STD 1003.1-2003 (tylko obowiązkowe części);
  • VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vsCPCTS2003.htm) - zestaw testów zgodności dla IEEE STD 1003.1-2003 (powłoki i narzędzia - tylko części obowiązkowe).

Ponadto Open Group opracował testy dla standardów Posix RealTime i Embedded Posix Standards Profil. Zestaw testów dla Posix Realtime (www.opengroup.org/testing/testsuites/Realtime.html) zawiera następujące testy:

  • Ieee Posix 1003.1B-1993 / 1003.1I-1995 Rozszerzenie realtime i IEEE Posix 1003.1.2003 Edycja;
  • IEEE STD POSIX 1003.1C-1995 Nici (Pthreads) Extension i IEEE Posix 1003.1.2003 Edition;
  • IEEE POSIX 1003.1D-1999 Dodatkowe rozszerzenie realtime i IEEE Posix 1003.1.2003 Edition;
  • Ieee Posix 1003.1J-2000 Advanced RealTim Extension i IEEE Posix 1003.1.2003 Edition;
  • Ieee Posix 1003.1Q-2000 Trace i IEEE Posix 1003.1.2003 Edycja i IEEE Posix 1003.1.2003 Edition;

Zestaw testów profili w Embedded Posix (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 Przedłużenie realtime (1430 testów);
  • IEEE STD Posix 1003.1c-1995 Nici (Pthreads) Przedłużenie (test 1232);
  • IEEE POSIX 1003.13-1998 Profil 52.

Trochę o zamieszaniu w terminologii

W odniesieniu do grupy standardów POSIX w języku angielskim, a nie jednym, ale aż do trzech warunków. Niestety, są one podobne w wartości i są często tłumaczone w równym stopniu, co przynosi pewne zamieszanie. Terminy to:

  • kompatybilność (dosłownie "kompatybilność");
  • zgodność (dosłownie "zgodność");
  • sonformance (dosłownie "spójność").

Pierwszy termin zastosowany do POSIX nie jest formalnie zdefiniowany. Drugi oznacza, że \u200b\u200borganizacja jest producentem oprogramowania niezależnie oświadcza, że \u200b\u200bten produkt (w pełni lub częściowo) spełnia następujące normy NIST-PCTS. Trzeciarzysty oznacza, że \u200b\u200bprodukt oprogramowania przekazał ustawiony system testowy lub za pomocą akredytowanego laboratorium lub w grupie otwartej i ma to potwierdzenie dokumentalne (tzw. Oświadczenie o zgodności). Dalej w tekście artykułu wszędzie będą oryginały warunków do wykluczenia dwuznaczności.

Certyfikowany OS RV.

Jeśli przestrzegasz ścisłych zasad wymagających, aby dane o certyfikowanym systemie OS RV zostały opublikowane w oficjalnym rejestrze i testowaniu przeprowadzono pod względem zgodności, teraz są tylko dwa certyfikowane OS RV (dane są podane w porządku chronologicznym):

Lynxos V.3. (Produkt firmy Lynx Systemy w czasie rzeczywistym, które są teraz nazywane Lynuksworks, Inc., www.lynoxworks.com) jest przeznaczone do opracowywania wbudowanych systemów działających w trudnych producentów w czasie rzeczywistym, producentów sprzętu kompletnego i telekomunikacyjnego, W szczególności producenci systemów pokładowych stosowania wojskowego. Rozwój może być przeprowadzany zarówno w systemie docelowym (samodzielnie), jak i na komputerze narzędziowym (host), gotowy do zaprojektowania do pracy w systemie docelowym (Cel). Lynxos V.3 jest certyfikowany według standardu spójności (zgodności) POSIX na platformie Intel i PowerPC. Informacje te można znaleźć na stronie internetowej IEEE http://standard.ieeeee.org/regauth/posix/osix2.html. Lynxo jest certyfikowany przez Mindcraft Posix 1003.1-1996, który jest akredytowanym Laboratorium Testowania Posix IEEE Posix dla testu ABIDS PIPS 151-2. Numer dokumentu potwierdzający certyfikat: Plik odniesienia: IP-2LYX002, plik referencyjny: IP-2LYX001.

Integralność V.5. (Produkt oprogramowania firmy Green Hills, www.ghs.com) jest certyfikowane dla spójności (zgodności) przez POSIX 1003.1-2003, interfejsy systemowe do architektury PowerPC w lipcu 2004 r. (Http://posixCertified.ieee.org/ Wybierz_product. tpl). Zestaw testów VSX-PCT 2003.

System operacyjny POSIX i QNX

QNX V.4.20 (Developer - Firma QNX Software Systems, www.qnx.com) Certyfikowane pod kątem zgodności (zgodność) przez POSIX 1003.1-1988 dla platformy Intel przez Datafocus włączony. Testowanie przeprowadzono 13 września 1993 r., Data wydania dokumentu - 1 listopada 1993 r. Zestaw testów NIST PCTS 151-1, wersja 1.1.

QNX Neutrino (wersja 6.3) jest zgodna (spełnia) następne standardy rodziny POSIX (www.qnx.com/download/download/8660/portowal.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).

Systemy oprogramowania QNX, twórca QNX Neutrino planuje również certyfikację (zgodność) QNX neutrino zgodnie z niektórymi z tych standardów; Prace są zaplanowane na 2005 r. (Www.qnx.com/news/pr_959_1.html).

Literatura

  1. Instrukcja obsługi standardów IEEE. IEEE, październik 2004 r.
  2. Kevin M. Ogeland. Posix w czasie rzeczywistym, programowanie systemów wbudowanych, 2001.
  3. IEEE / ANSI Standard 1003.1: Technology informacyjne - (POSIX) - Part1: Aplikacja systemowa: interfejs programu (API).
  4. Galmeister, B. O. Programowanie dla prawdziwego świata, POSIX.4 Sebastopol, CA: O'Reilly & Associates, 1995.
  5. Krajowy Instytut Normien i Technologii, PCTS: 151-2, Posix Test Suite.
  6. POSIX: certyfikowany przez IEEE i otwartą grupę. Certyfikowana polityka. Grupa Open, 21 października 2003 r., Revision 1.1.