Blog IT, Blog Marketing

Alternatywne systemy operacyjne Część 4 – QNX i jego architektura

Alternatywne systemy operacyjne Część 4 – QNX i jego architektura

Przemysław Pintal , 01.03.2020 r.

Drzewiej bywało

Nie liczac BeOS a pozniej Haiku

Nie licząc BeOSa, a później Haiku w które się na kilka lat zaangażowałem, to największe wrażenie spośród systemów operacyjnych wywarło na mnie QNX.

Zobacz video

Około dwudziestu lat temu, do płyty CD jednego z czasopism komputerowych dołączono obraz dyskietki 1,44 MiB z systemem operacyjnym. Zupełnie mi nieznany, lecz posiadał on GUI i komplet niezbędnych programów użytkowych, typu menedżer plików i przeglądarkę WWW, toteż wiedziony dziecięcą ciekawością sformatowałem jakąś dyskietkę, wgrałem obraz czy luźne pliki i dokonałem rozruchu na swoim Celeronie 466 MHz i 64 MiB RAMu. Wtedy oniemiałem... Była to kampania marketingowa, mająca pokazać potencjalnym programistom systemów wbudowanych, jak QNX zachowuję się w ograniczonym w zasoby środowisku i ile jest w stanie wycisnąć programista systemowy, jakby soku z pomarańczy, za sprawą sztuki programowania (jak w książkach Knutha).

Business Development Manager - Dział Sieci i Bezpieczeństwa Sieciowego

Gliwice
Aplikuj
Neutrino Desktop

Najbardziej doniosła w skutkach okazała się jego wydajność, tym samym wywołując we mnie szok kulturowy, skoro używało się wtedy Windowsa 98 i 2000, na ogół na powolnych maszynach. Była to wersja demonstracyjna QNX 4 i występowała w dwóch wersjach. Na jednej łączyło się z globalną siecią z pomocą katrty sieciowej, a na drugiej za sprawą modemu. Niestety nie posiadałem w domu połączenia z internetem, więc pozostało mi przesuwać okna i ubolewać nad marnym losem użytkownika Windowsa, którego, w sumie, trzymały tam tylko gry. Dzisiaj wiem, że przeglądarka nosiła nazwę Voyager i obsługiwała HTML 3.2 i JavaScript (ale bajer!). Ostatnią wersją, jaką dane było mi ujrzeć, okazała się 6.2.1 i najbardziej przypadła mi do gustu od strony wizualnej. Wersja siódma, jaką wydano trzy lata temu, wygląda już jak Gnome3 albo MacOS X. Mnie brakuje w niej tego sznytu lat 90.

Zobacz też: Alternatywne systemy operacyjne. Część 3 - MenuetOS i KolibriOS.

Matki przeciwko Kanadzie

QNX jest produktem firmy założonej w Ottawie, w 1980 roku, przez dwóch studentów Uniwersytetu Waterloo, Gordona Bella i Dana Dodge'a. Odbyli oni wtedy kurs programowania systemów czasu rzeczywistego i mikrojąder, studiując przy tym przenośny system czasu rzeczywistego Thoth. Pierwotnie ich system nosił nazwę QUNIX (Quick UNIX, miało to sugerować, że są równie dobrzy co od dawna rozwijany UNIX), jednakże nazwa okazała się zbyt oczywista (sic!) i AT&T wymusiło na nich zmianę, toteż zdecydowali się na markę - QNX Realtime Operating System. Jakiego to pisali na procesory Intela 6809 i 8088, przylutowane do płyty głównej własnego autorstwa. Ich firma zwała się jeszcze wtedy Quantum Software Systems, a niedługo później przemianowali ją na QNX Software Systems, nim ostatecznie została wykupiona przez BlackBerry. Pierwszym komputerem na jakim działał QNX wcale nie było urządzenie wbudowane, ale komputer wykorzystywany w edukacji państwowej prowincji Ontario - Unisys ICON (posiadał on procesor Intela 80186 i był opakowany niby Commodore PET).

Zobacz też: Alternatywne systemy operacyjne. Część 2 - ReactOS.

Istnieje pewna konfuzja w nazewnictwie wersji. Należy sobie uzmysłowić, że prace nad QUNIXem miały miejsce w 1981 roku, kiedy to zaprezentowano go „znajomym”, dwa lata później było gotowe coś na kształt bety QNX. W 1984 roku ukazał się QNX 1.0, a w 1987 ważna z punktu widzenia rozwoju wersja 2.0 – przeniesiono do QNX stos TCP/IP i PPP z 4.3 BSD, ale sieć działała tylko na karcie firmy Arcnet. Rok 1990 to QNX 4.0 i wprowadzenie zgodności z POSIX. Pięć lat później, w 1995, podjęto prace nad QNX/Neutrino 1.0, tj. nowym kernelem w którym wszystko, łącznie ze sterownikami, jest procesem, a te otrzymują odrębnie wydzieloną przestrzeń w pamięci wirtualnej, toteż awaria sterownika nie pociągnie za sobą systemu, nie trzeba go uruchamiać od nowa, tylko ów program należy zrestartować.

qnx momentics

W czerwcu 2002 roku świat ujrzał pakiet oprogramowania QNX Momentics. Na jego zestaw składały się kernel Neutrino, środowisko graficzne Photon microGUI i zintegrowane środowiska programistyczne (IDE), choćby właśnie Momentics który dał nazwę ogółowi albo Tornado II czy oprogramowanie RAD – PhAB.

Zobacz też: Alternatywne systemy operacyjne. Część 1 - Haiku
Photon microGUI

Integralną częścią QNX Momentics stanowią także narzędzia GNU i biblioteki, szczególnie te pogrupowane w pakiety BSP.

Pakiety BSP-QNX

Zawierają one kody źródłowe, biblioteki, obrazy flash, jak i kreatory w stylu makefile, które usprawniają budowanie obrazu z systemem, a w razie czego obcięcie z dowolnych elementów, w celu optymalizacji na końcówkach.

Najnowsze wydanie QNX 7.0 miało miejsce w 2017 roku i obsługuje 64-bitowe architektury ARM i x86, utrzymując przy tym wersje 32-bitowe, kiedy linia wydań 6.x (2001 rok) pokrywała więcej platform : ARM, MIPS, PowerPC, SH-4, StrongARM, XScale, x86. Oprócz tego aktualne wydanie zapewnia programistom standardy C11 i C++14.

Zobacz też: Standard C++20 został sfinalizowany. Zwięzłe omówienie popularniejszych nowości
QNX-Screen

Usunięto także Photon microGUI, w jego miejsce wprowadzono podsystem graficzny Screen. Było to podyktowane potrzebą zapewnienia GUI zdolnego do kompozycji, akceleracji OpenGL ES 2.0 i oczekiwanego przez rynek frameworku Qt, oprócz zdolności do pisania GUI w HTML5.

Zobacz video

Gdyby GNU/Hurd miało innego projektanta

Kernel Neutrino w QNX stanowi mikrojądro czasu rzeczywistego które zarządza grupą kooperujących ze sobą procesów. Przypomina to bardziej drużynę graczy o równej randze niźli hierarchię. Dokonują one między sobą interakcji poprzez koordynujące je jądro. Neutrino zachowuje się jak magistrala programowa do której włączają się i odłączają, zależnie od potrzeby, moduły systemu. Do prerogatyw kernela należy:

  • Obsługa (services) wątków poprzez operację (primitives) ich tworzenia w POSIX.
  • Obsługa sygnałów, analogicznie przez POSIX.
  • Usługa przesyłania-danych (message passing) – wytyczanie trasy wszystkich wiadomości pomiędzy wątkami w całym systemie.
  • Usługa synchronizacji także za pomocą prymitywów synchronizacji POSIX.
  • Usługa planisty. Mikrokernel planuje wykonanie wątków wykorzystując ku temu odmienne strategie czasu rzeczywistego zawarte w POSIX (strategie FIFO i Round-Robin, nadto sporadyczne szeregowanie).
  • Usługa związane z czasem – system posiada bogaty zestaw funkcji związanych z funkcjami czasu.
  • Usługa zarządzania procesami. Mikrojądro wraz z menedżerem procesów współtworzą jednostkę procnto. Tamże sam menedżer procesów jest odpowiedzialny za zarządzanie procesami, pamięcią i przestrzenią nazw ścieżek.

Kernel Neutrino

W przeciwieństwie do wątków, mikrokernel sam z siebie nigdy nie planuje wykonania. Procesor wykonuje kod w mikrojądrze wyłącznie jako rezultat wywołania jądra, jego wyjątku lub w odpowiedzi na przerwanie systemowe. W QNX komunikacja międzyprocesowa składa się z wysłania komunikatu od jednego procesu do drugiego i oczekiwaniu na odpowiedź. Jest to pojedyncza operacja zwana MsgSend. Następnie ów komunikat zostanie przekopiowany przez jądro z przestrzeni adresowej procesu który jest nadawcą do analogicznej u odbiorcy. Kiedy proces wyczekuje owej informacji, wtenczas kontrola jednostki centralnej zostaje przekazana z pominięciem planisty procesora. Wbrew mniemaniom powyższa praktyka nie skutkuje utratą kolejności po stronie procesora. Ścisła integracja przekazywania komunikatów (message passing) i harmonogramowania CPU, jest niespotykana w systemach UNIX i Linux, mimo że jest to kluczowy mechanizm odpowiadający za sensowność QNX. Ponadto brak tejże subtelności odpowiada za straty na wydajności w innych mikrojądrach tak, jak we wczesnych wersjach jądra Mach. Wszelkie operacje w podsystemie I/O i działania przeprowadzane na systemie plików i w sieciach podlegają tej samej implementacji!

Spedytor Międzynarodowy 5500 - 8500 PLN

Praca zdalna
Aplikuj

Sterowniki urządzeń nie znajdują się w jądrze, w efekcie debugując je nie debugujemy jądra. QNX obsługuje wieloprocesorowość (SMP, AMP, BMP), koligację procesorów i APS (adaptive partition schedulers). Ostatnie zezwala na wykonanie się wybranych wątków w czasie rzeczywistym lub tych od których inne posiadają wyższy priorytet, skoro gwarantuje im minimalny dostęp do czasu procesora. Nawet w okolicznościach przeciążenia systemu.

Powyższe stanowi zaledwie ogólnikowy wstęp do dokumentacji QNXa, ale daje już pewien ogląd sytuacji.

Porzucenie desktopu

Firma stojąca za rozwojem QNX (obecnie BlackBerry), tylko przez kilkuletnie interwały, w swojej niemalże czterdziestoletniej historii, była zainteresowana desktopem. Niestety BlackBerry zlikwidowało licencję hobbystyczną i jest skupione na rozwiązaniach wbudowanych, we wszelkich gałęzachi przemysłu, a nie tylko na oprogramowaniu pokładowym samochodów. Uważam, że jest to niezwykle tragiczne zjawisko bowiem nie posiadamy na rynku alternatywy za którą stałby biznes tj. zapewniłby spokojny rozwój i nie rodził frustracji wśród użytkowników wieloletnim czekaniem na wdrożenia oczywistych funkcji, jak akceleracja 3D, z powodu szczupłych sił zmuszonych stanąć w obliczu kompleksowych zadań z zakresu inżynierii oprogramowania.

haiku-desktop-full

Najbliższym odpowiednikiem dla QNXa, w przypadku desktopu, jest Haiku, skoro jest wyjątkowo rozwinięte (już dekadę temu wzbiło się ponad hobby) i cechuje się dojrzałym kodem źródłowym, a jego scheduler posiada tryb low_latency. Jednakże za Haiku stoi tylko jedna i to niszowa firma - TuneTracker Systems. Zajmują się oni dostarczaniem oprogramowania i komputerów do lokalnych rozgłośni radiowych.

Najnowsze oferty pracy:

Polecane wpisy na blogu IT:

Szukasz pracownika IT?

Dostarczymy Ci najlepszych specjalistów z branży IT. Wyślij zapytanie

Wyrażam zgodę TeamQuest Sp. z o.o. na przetwarzanie moich danych osobowych w celu marketingu produktów i usług własnych TeamQuest, w tym na kontaktowanie się ze mną w formie połączenia telefonicznego lub środkami elektronicznymi.
Administratorem podanych przez Ciebie danych osobowych jest TeamQuest Sp. z o.o., z siedzibą w Warszawie (00-814), ul. Miedziana 3a/21, zwana dalej „Administratorem".
Jeśli masz jakiekolwiek pytania odnośnie przetwarzania przez nas Twoich danych, skontaktuj się z naszym Inspektorem Ochrony Danych (IOD). Do Twojej dyspozycji jest pod adresem e-mail: office@teamquest.pl.
W jakim celu i na jakiej podstawie będziemy wykorzystywać Twoje dane? Dowiedz się więcej