QNX operativni sistem - tekst objavljen u PCPress

Ово је оригинални текст који је са неким мањим изменама објављен у часопису PCPress, у летњем двоброју 2008 (број 146).

QNX Operativni Sistem

Ugrađeni računarski sistemi1) su danas u najširoj primeni: od digitalnih foto aparata, mobilnih telefona pa do upravljačkih sistema na avionima i satelitima. Ovi sistemi su u proteklih nekoliko decenija, od jednostavnih kontrolera sa specifičnim softverom za određen upravljački zadatak prerasli u kompleksne sisteme na kojima se izvršava mnoštvo aplikacija – od kritičnih upravljačkih aplikacija do grafičkog korisničkog interfejsa. Porast broja aplikacija koje takvi uređaji istovremeno izvršavaju je neizbežno postavio zahtev za operativnim sistemom koji bi to omogućio a da pri tome ne kompromituje stabilnost i odziv sistema u realnom vremenu za sve vremenski kritične zadatke. U ovom tekstu će biti predstavljen jedan takav operativni sistem, Neutrino RTOS2) kanadske firme QNX Software Systems.

Autor: Aleksandar Ristovski

O QNX Software Systems

QNX [1] je kanadska firma osnovana početkom 80-tih godina, kada su njeni osnivači Gordon Bel i Den Dodž primenili stečeno znanje sa fakulteta o RTOS i napravili komercijalan proizvod. Sa vremenom je kompanija rasla i u periodu od oko 27 godina od firme sa dva zaposlena prerasla u kompaniju od nekih 300 zaposlenih i mrežom kancelarija za podršku i prodaju na više kontinenata.

Evolucija

QNX-ov prvi ozbiljan komercijalan uspeh je bio napravljen operativnim sistemom koji se zvao „QNX4“. Već sa QNX4 QNX je nudio dobru podršku za različite vrste perifernih uređaja, ali još uvek bio ograničen na Intelove 32-bitne x86 procesore i platforme bazirane na njima. Podrška multiprocesorskim sistemima nije postojala, a programski interfejs je bio specifičan za QNX4. Ipak, veliki uspeh ovog operativnog sistema je obezbedio važno mesto QNX kompanije u svetu ugrađenih računarskih sistema i utabao put za sledeći veoma uspešan operativni sistem za rad u realnom vremenu nazvan Neutrino.

Neutrino operativni sistem je bio prirodna evolucija QNX4 operativnog sistema. Stratezi QNX kompanije su pravilno procenili da su osnovni sputavajući faktori za dalji rast bili ograničena podrška savremenih procesora i nestandardni programski interfejs. Tako je odlučeno da osnovne novine u Neutrino operativnom sistemu budu podrška za još četiri procesorske familije: SuperHitachi (SH4), Mips32, PowerPC i Arm, kao i standardizacija programskog interfejsa na osnovu POSIKS3) standarda.

Arhitektura jezgra

QNX operativni sistemi spadaju u red mikro-jezgarnih operativnih sistema. Svi procesi se izvršavaju u zasebnim zaštićenim korsničkim adresnim prostorima što je obezbeđeno hardverskim menadžmentom memorije (MMU). Komunikacija izmedju procesa se vrši razmenom poruka4).

Mikro-jezgarna arhitektura je u QNX operativnim sistemima implementirana veoma rigorozno: u zaštićenom režimu rada se izvršava samo mikro-jezgro, dok sve drugo, uključujući drajvere, fajl sistem, protokole, pa čak i proces menadžer radi svaki u svom zasebnom korisničkom adresnom prostoru. To praktično znači da svaka od tih komponenti može da se zaustavi, zameni i ponovo startuje bez zaustavljanja rada mikro jezgra - mogućnost kojom malo drugih mikro-jezgarnih operativnih sistema mogu da se pohvale.

Jedna od najvažnijih karakteristika operativnog sistema jeste strategija raspoređivanja niti izvšavanja5). QNX jezgro nudi raznovrsne strategije raspoređivanja izvršavanja programskih niti što je takođe jedna od karakteristika Neutrina. Osim uobičajenih, postoje i patentirane strategije kao što je adaptivno raspoređivanje po particijama6) koji obezbeđuje visoku odzivnost sistema čak i u slučajevima u kojima jedna od niti visokog prioriteta greškom uzima preveliki procenat procesorskog vremena [3].
Danas takođe veoma važna je i podrška višeprocesorskim sistemima a Neutrino RTOS tu podršku nudi na bazi simetričnih multiprocesorskih sistema (SMP) [5].
Podrška razvoju aplikacija

Pored jezgra, QNX nudi i čitav niz softverskih paketa za podršku različitim platformama8). Tu je i niz programa za POSIKS kompatibilno okruženje, kao i razvojni alati. Razvojni alati su bazirani na GNU kompajleru (gcc) [4] i debageru (gdb) [5] čije prilagođene varijante dolaze sa razvojnim alatima. Grafičko razvojno okruženje za razvoj aplikacija "Momentics" bazriano je na Eclipse platformi i njenoj CDT ekstenziji [7]. Iako je teoretski moguće programirati u različitim programskim jezicima, najčešće se aplikacije razvijaju u C i C++. Java virtuelna mašina je takođe dostupna.

Ugrađeni računarski sistemi često nemaju nikakav prikaz (tzv. "bezglavi" uređaji) ali nisu retki sistemi od kojih se traži bogata grafika. Za takve primene QNX nudi Foton9), svoju grafičku platformu, a odskora i grafički sistem baziran na Adobe Flash. Foton je dosta siromašan u poređenju sa uobičajenim desktop grafičkim okruženjima na koje ste navikli, ali je svejedno simpatičan i zadovoljava većinu potreba u ugrađenom računarskom svetu. Nova inicijativa sa Adobe Flash je veoma interesantna: umesto da nudi grafičku platformu opšte namene po ugledu na desktop računare (Foton), QNX je odlučio da ponudi mogućnost razvoja kompletnog grafičkog okruženja u Adobe Flash-u [8]. Ovo ima i te kako smisla ako se pogleda u kakve uređaje Neutrino ide: na primer, mobilnom telefonu verovatno ne treba standardna grafička komponenta prozorskog okvira, paleta aplikacija i slično. Mnogo je verovatnije da će dizajner uređaja želeti da napravi svoju sopstvenu varijantu korisničkog interfejsa sa lepim animacijama i jedinstvenim izgledom, a Adobe Flash upravo to omogućava. Da stvar bude bolja, znanje koje su programeri stekli programirajući "action script" za veb stranice mogu gotovo direktno da primene i ovde.

Otvoren izvorni kod i otvoreni razvoj

Prošle godine, krajem 2007-me, QNX je napravio interesntan potez. Otvorio je svoj izvorni kod koji se sada može pregledati i skinuti preko Interneta. Za nekomercijalne primene je besplatan što znači da ga može koristiti svako za učenje i evaluaciju. Ova činjenica se rado koristi po fakultetima širom sveta gde se Neutrino koristi u raznim istraživačkim projektima.

Osim otvorenog izvornog koda, QNX je takođe "otvorio" svoj razvoj. Tako na interesnim grupama [2] možete uživo pratiti šta se događa, koji bagovi su ispravljeni, o kakvim novinama se razmišlja i slično. Možete čak i da učestvujete u diskusijama ukoliko ste zaintersovani.

Ipak, primena u komercijalnim proizvodima nije besplatna i podleže uobičajenim poslovnim obavezama a u skladu sa licencom. Cena za komercijalne proizvode varira u velikom rasponu, plaća se po isporučenom uređaju6) a obavezna je i kupovina razvojnog okruženja. Ovo razvojno okruženje se takođe može skinuti sa Interneta i podleže sličnoj licenci kao i izvorni kod, odnosno za nekomercijalnu upoterbu i u akademske svrhe je besplatan.

Za entuzijaste
Za one zainteresovane da se bliže upoznaju sa Neutrinom, sve što je potrebno za početak je brza Internet konekcija. Na stranicama interesnih grupa možete naći veze na potrebne fajlove za instalaciju [11]. Registracija korisničkog naloga je obavezna, ali besplatna. Uobičajeno je da se za razvoj ("host") koriste Windows ili Linux mašine, ali je moguće raditi i direktno na Neutrinu. Ja, konkretno, koristim uglavnom Windows ili Linux za razvoj a kao ciljnu mašinu koristim ili VirtualPC [9] ili VMWare [10] virtuelnu mašinu. Za uputstvo za instalaciji i brzi početak, pogledajte [12].


Korisne Internet adrese

[1] QNX početna stranica http://www.qnx.com
[2] QNX stranica za intersnu grupu http://community.qnx.com (besplatna registracija potrebna za pristup izvornom kodu)
[3] POSIKS standard http://www.unix.org/single_unix_specification/ (besplatna registracija obavezna), http://en.wikipedia.org/wiki/POSIX
[4] GCC - kompajler http://gcc.gnu.org/
[5] GDB - debager http://sourceware.org/gdb/
[6] Eclipse platforma http://www.eclipse.org/
[7] QNX SMP TDK: http://photon.qnx.com/download/download/9421/smp_tdk.pdf
[8] QNX i Adobe Flash: http://www.qnx.com/news/pr_2609_1.html
[9] Virtual PC - besplatan ali dostupan samo za Windows http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx
[10] VMWare - http://www.vmware.com/
[11] QNX Momentics - http://www.qnx.com/products/getmomentics/
[12] Uputstvo za instalaciju i početak: http://www.qnx.com/developers/docs/6.3.2/momentics/quickstart/about.html

Fusnote

1) engl. Embedded systems
2) engl. Real Time Operating System - operativni sistem za rad u realnom vremenu
3) eng. POSIX - Portable Operating System Interface
4) engl. Message Passing
5) engl. Thread Scheduling
6) engl. Adaptive Partition Scheduling
7) engl. Runtime
8) engl. Board Support Package
9) engl. Photon

LaTeX и ћирилица

Коначно сам, уз помоћ Страхиње Радића, успео да генеришем ћирилични текст из латекса.

Још увек није савршено јер немам "babel" модул (не знам тачно из ког разлога), па сам морао да искоментаришем ту линију.

\documentclass{article}
\usepackage[utf8x]{inputenc}
\usepackage[T2A]{fontenc}
% \usapackage{babel}
\begin{document}
АБВГДЂ % наравно, сачувано као УТФ-8
\end{document}

Следећи корак, генерисање хтмл-а из латекса. Постоји програм, latex2html који на жалост не ради код мене, али верујем да могу да га оспособим. Крајњи циљ је да пишем ове чланке за вебник (блог) у латексу а онда генеришем одговарајући хтмл. Треба "потрефити" стилове како бих могао да користим ".css".

О том у неком следећем издању.

Форматирање изворног кода за вебник

После дужег тражења одговарајућег алата за форматирање изворног кода који се појављује у вебнику, коначно сам нашао задовољавајуће решење.

Користим "GNU source-highlight" http://www.gnu.org/software/src-highlite/ .

Са командне линије радим ово:

$ source-highlight --no-doc --css=code.css test.c

где је садржај code.css овакав:

body {  background-color: white;  }

/* the color for context lines (when specified with line ranges) */
.context {  color: gray; }

.keyword { color: blue; font-weight: bold; }
.type { color: darkgreen; }
.usertype, .classname { color: teal; }
.string { color: red; font-family: monospace; }
.regexp { color: orange; }
.specialchar { color: pink; font-family: monospace; }
.comment { color: brown; font-style: italic; }
.number { color: purple; }
.preproc { color: darkblue; font-weight: bold; }
.symbol { color: darkred; }
.function { color: black; font-weight: bold; }
.cbracket { color: red; }
.todo { font-weight: bold; background-color: cyan; }

/* line numbers */
.linenum { color: black; font-family: monospace; }

/* Internet related */
.url { color: blue; text-decoration: underline; font-family: monospace; }

/* other elements for ChangeLog and Log files */
.date { color: blue; font-weight: bold; }
.time, .file { color: darkblue; font-weight: bold; }
.ip, .name { color: darkgreen; }

/* for Prolog, Perl */
.variable { color: darkgreen; }
.italics { color: darkgreen; font-style: italic; }
.bold { color: darkgreen; font-weight: bold; }

/* for LaTeX */
.underline { color: darkgreen; text-decoration: underline; }
.fixed { color: green; font-family: monospace; }
.argument, .optionalargument { color: darkgreen; }
.math { color: orange; }
.bibtex { color: blue; }

/* for diffs */
.oldfile { color: orange; }
.newfile { color: darkgreen; }
.difflines { color: blue; }

/* for css */
.selector { color: purple; }
.property { color: blue; }
.value { color: darkgreen; font-style: italic; }

Затим сам исти садржај додао у шаблон блога, али без "body" линије. Уместо ње сам додао:

pre {  background-color: #EEEEFF;  }

И то је све. Још увек има простора за убрзавање овог процеса, али елементи су ту.

Assert

Волим да користим асерте. Корисни су као само документујући код али и као помоћ при развоју.

Асерти су провере истинитости одређеног израза. Уколико евалуација израза који се прослеђује макроу „assert” за резултат даје нулу, програм се прекида уз поруку о изразу, имену фајла и линији. Порука може да се разликује у зависности од компајлера и система на коме се програмира, али ће све мање-више имати одређену информацију о томе где се асерт десио.

Када се програм искомпајлира са дефинисаним макроом „NDEBUG”, асерти нестају (макро assert бива дефинисан као ((void)0) и избачен као линија без ефекта).

Током развоја, важно је користити програм компајлиран без овог макроа (односно са укљученим асертима).

Један тривијалан пример:

#include <assert.h>
#include <string.h>

int mojstrlen(const char * const p)
{
   assert(p != NULL);

   return strlen(p);
}

У примеру се види предност (и мана) овог приступа. Иако не можемо да забранимо кориснику функције да проследи NULL вредност, омогућујемо му да открије своју грешку у току развоја. Такође, само кратким погледом на функцију кориснику (програмеру) ће бити јасно да треба да обезбеди не-нул вредност.

Сама чињеница да асерти не постоје у коначном програму који се испоручује их чини адекватним само за оне случајеве који не смеју да се десе на терену, али истовремено их чине идеалним за време тестирања.

Рецимо да хоћемо да направимо робусну библиотеку и затим је дистрибуирамо корисницима од којих не можемо да очекујемо да знају да вредност показивача не сме да буде нула, онда асерт није довољан, а можда ни адекватан. У том случају би било примереније урадити нешто овако:

int mojstrlen(const char *const p)
{
   if (p == NULL)
       return 0;
    return strlen(p);
}

Као правило, ја користим асерте на функцијама које нису експортоване из библиотека, него су намењене за коришћење унутар једног програма. Како често није очигледно шта одређен логички исказ проверава, онда уз исказ додам и текст који описује проверу. У примеру горе, то би изгледало овако:

int mojstrlen(const char * const p)
{
   assert(p != NULL && !!"Pokazivac 'p' ne sme biti NULL");

   return strlen(p);
}

конст коректност 2

Интересантност о којој до данас нисам мислио. Колега ми је отворио очи. Наиме, ради се овоме: колега је послао фајл са Ц кодом на преглед. Његов код је имао функције које су изгледале отприлико овако:

/* Primer const argumenta u definiciji. */
static int foo(const int bar)
{
    if (bar > 7)
          global_bar = bar - 7;
}

На то сам ја коментарисао да обично не "губим" време декларишући формални аргумент конст, на шта ми је одговорио (потпуно исправно) да је у дефиницији конст врло корисна, за разлику од декларације.

Конст формални аргумент у декларацији сам коментарисао, али ја лично никада нисам размишљао о томе да дефиниција може да дода модификатор конст формалном аргументу, а да тиме не дефинише неку нову функцију.

На пример, нека је у заглављу оваква декларација:

/* Deklaracija funkcije.  */
int funkcija(const char *);

А имплементација може овако:

/* Definicija funkcije.  */
int funkcija(const char * const ime)
{
// ...
}

Заиста, овако се кориснику функције (који обично гледа прототип декларисан у заглављу) не намеће имплементациони детаљ за њега (корисника) небитан, док се читаоцу имплементације одмах даје до знања да се вредност формалног аргумента "ime" неће мењати у телу функције. Дакле, даје читаоцу сличну информацију као и конст модификатор на локалној варијабли.

Даље је интересантно приметити да додавање конст модификатора формалном аргументу у декларацији у суштини не мења декларацију. На пример, ове две декларације декларишу исту функцију.

/* Ekvivalentne deklaracije funkcije.  */
int funkcija(const char *);
int funkcija(const char *const);

Oва друга је очигледно рогобатнија и представља једну од оних декларација у којима сам причао и у претходном чланку.