Intresantno...
Kako stoji sa hardverskom podrskom posto rece da ga teras iz virtuelne masine?
Ono bas me zanima ;)

U principu, podrzava standardni x86 hardver, ja cu ga isprobati sledece nedelje na ATOM procesoru, mada Intel podrzava i ostale tipicne konfiguracije sa GMA adapterima...

Za vise detalja o podrsci - www.openqnx.com i www.qnx.com

QNX generalno ima slabu "siroku" podrsku za hardver, posto se QNX specijalizovao za embedded/time critical aplikacije, pa se moze videti da podrzavaju mali milion kontrolera i barebone sistema, ali zato neke "gaming" stvari verovatno nisu podrzane.

Steta, jako lep OS.

Ne znam kakva je situacija sada, ali koliko mi je poznato za komercijalnu upotrebu licenca po jediničnom sistemu je oko 8000 dolara... Bar smo mi toliko plaćali pre dok smo to koristili, a to je bilo pre nekih 4-5 godina...

Nije vise definitivno, ima vise licenci - Harman koristi QNX u njihovim in-car infotainment sistemima kao i nekim kucnim hi-end uredjajima...

Jeste da je QNX u vlasnistvu Harmana, ali su definitivno poceli da sluze i taj deo trzista (za eksterne customere), a 8K bi bila totalno nerealna cifra za vecinu uredjaja, osim mozda za Mark Levinson :)

Evo kako izgleda ;-)

- Totalni je retro, UI podseca na Motif :)
- Dolazi sa osnovnim aplikacijama za bazicni desktop rad (mail, internet)
- Dolazi i sa razvojnim alatima i dokumentacijom (Momentics)
- Fontovi koji dolaze sa sistemom su slabasni (kao sto se vidi iz Mozilla ekrana), tako da je pozeljno instalirati neke lepse
- Sistemske komande su vrlo limitirane, shell je prilicno spartanski (moj kolega Linuxas se zaprepastio ;-)

Mada, to i ne cudi posto QNX i nije namenjen za desktop (mada se ekipa sa OpenQNX.com trudi da sakupi sve sto bi trebalo da QNX ucini masinom koja moze da se koristi i za desktop rad) - u svakom slucaju, moguce je instalirati i Momentics IDE (modifikovani Eclipse) - sto znaci da je u principu sve osnovno tu, samo sto ne izgleda prilicno lepo.

Otprilike na nivou Windowsa 95 sto se korisnickog interfejsa tice (minus fontovi) - mada, neki ljudi cene jednostavnost.

Medjutim, sa druge strane, ovo je OS koji je moguce spakovati sa sve Web-Browserom u par MB (nije vise moguce strpati ga na 1.44 MB flopi - ali na nekoliko MB staje) i koji je totalni RTOS i na kome se zna koliko nanosekundi sistemska operacija moze da traje maksimalno... tako da, ima svoje prednosti u nekim segmentima :)

zanimljivo.
i ovaj menuetOS izgleda zanimljiv kao rtos.(bilo je po forumu)
http://www.menuetos.net/
http://en.wikipedia.org/wiki/MenuetOS

nešto malo drugačije
http://en.wikipedia.org/wiki/FBUI
http://home.comcast.net/~fbui/
(ovaj poslednji ima neki mini testni live cd ,nisam još isprobao u virtuelnoj)

Mislis da se QNX najvise upotrebljava kod razvoja softwera za medicinske aparate.

Instaliro sam ga dva puta u zivotu, prvi put pre 5 godina kad se ppojavila verzija koja stane na floppy (samo sam ja mislio tad da sve sto nije windows je Linux pa sam ga tako i nazvo :)) a drugi put kad sam se interesovo za RTOS. U svakom slucaju meni je GUI QNXa (Photon!?) ljepsi i bolji od gnoma i kde zajedno.

MenuetOS je pisan u modifikovanom Flat Assembleru i ograničen je samo na PC 32 i 64 bitne arhitekture. QNX ipak radi na više platformi.

Yep,

QNX radi na vise platformi i daleko je bolje isprojektovan... Sam dizajn QNX-a je skolski primer dobro dizajniranog OS-a, nesto cemu bi Windows i Linux mogli da zavide (doduse, jasno je da je QNX u mnogo boljoj poziciji jer nemaju siroko trziste i teret kompatibilnosti, ali opet - QNX je bio dobro dizajniran i 80-tih ;-)

Jedina steta je sto se kompanija koja je iza njega potpuno fokusirala na embedded trziste, sam OS bi mogao biti koriscen u mnoge druge svrhe.

Inace zanimljivo, Windows NT je u pocetku bio jako slicno dizajniran QNX-u (sa malim, skoro mikrokernelom i drajverima u user-spaceu - ko se seca NT 3.5 ili cak 3.1 zna kako su drajveri mogli da crknu a da OS nastavi da radi) - medjutim, zbog velike bitnosti x86 platforme, Microsoft je polako sve vise stvari spustao u kernel nivo i smanjivao modularnost NT kernela (zato sto x86 ima jako skup context-switch)... Mada, interesantno, sada u vreme Viste se ponovo vracaju starim idejama pa su makli Audio i Print drajvere nazad u User mod :)

Što se tiče tih egzotičnih, malih, ali sa namjenom OS-eva, ja bih spomenuo SanOS koje je u najkraćem rečeno: Mali OS koji se instalira na FAT32 FS, koristi Microsoft PE format, ima Unix hijerarhiju foldera, i dovoljno implementiranih biblioteka da je moguće pokrenuti Sun HotSpot JVM, a samim tim Java Server Applications.

Više info na: http://www.jbox.dk/sanos/

Što se tiče QNX-a, ja sam prije par dana skinuo neki iso, kao QNX Momentics 6.3.2 for Windows, ali ovo je izgleda samo malo prepravljeni Eclipse. Šta trebam skinuti da bih dobio QNX OS sa onim GUI-em, bez ovog Momentics-a?

Skini QNX Momentics za QNX (ne za Windows), to je bootabilni ISO - prilikom instalacije samo reci da neces Momentics, vec samo base QNX i to je to.

Alternativa je da sam buildujes QNX, mada za probanje to nema puno smisla, ako te zanima - openqnx.com tu negde treba da bude i uputstvo.

Mozda trolujem, i idem u offtopic... ali Linux od 2.6.22 kernela ima userspace driver api.
http://lwn.net/Articles/232575/

Mozda nekog interesuje l;)

To je dobro za Linux, u principu mislim da bi svi drajveri trebalo da budu u user-spaceu izuzev nekih koji su zaista performance-critical (mozda cak ni tada).

Na zalost, idiotski pritisci na trziste su ucinili svoje, pa su vendori makli i network drajvere i TCP/IP stack u kernel-mod, kako bi dobili koji % performansi na testovima.

A time se izuzetno ugrozava bezbednost sistema, fakticki drajveri su deo kernela, i bag u drajverima znaci i krah OS-a, sto korisnici Windows-a vide kao BSOD, a korisnici Linuxa kao kernel panic.

Microsoft je neke 1995-te odlucio da graficki podsistem (win32k.sys) iz user-spacea "spusti" u kernel mode pre izlaska WinNT 4.0, zato sto su tadasnji racunari bili relativno slabi za tada novi (Win95) UI - dok su neke 2002 ili 2003 odlucili da TCP/IP stack takodje spuste u kernel mode. Tako da vecina user aplikacija zove Kernel32.dll / User32.dll i Gdi32.dll - i sve sto ti DLL-ovi rade je da preusmere API pozive u kernel mod (kroz ntdll.dll koji izvrsava context-switch i skok u kernel-mode)

Sa Win Serverom 2008 i Vistom je doslo do lepe promene, sound i print drajveri su vraceni u user-space, a iskreno - to je i bilo vrlo kriticno, jer je postojao mali milion >ocajnih< zvucnih drajvera (Creative) koji su degradirali stabilnost celog sistema.

Na zalost mislim da Microsoft nece u skorije vreme vratiti network stack u userspace, zbog imbecilnih benchmark-a - verovatno jedni cekaju na druge (Win / Lin) da neko od njih prvi povuce taj potez, znaci nikad.

QNX je tu pravo osvezenje, jer QNX nikada nije zrtvovao stabilnost sistema za koji % performansi.

Inace QNX drajver se ni po cemu ne razlikuje od bilo koje druge aplikacije (tj. procesa) - jedino sto drajveri imaju I/O dozvolu (kako bi pristupali fizickom hardveru) koju moze dobti bilo koji proces koji trci kao Root i to zatrazi, i registruju se za handlovanje odredjenih hw. interapta - ono sto je interesantno, i "obicne" aplikacije mogu da rade to isto - ako bas treba (mada, to i nije dobar dizajn)

Jos jedna interesantna osobina QNX-a je koncept "adaptivnih particija" u schedulingu - recimo, mozete 10 threadova staviti u particiju 1, 10 threadova u particiju 2, i onda reci da particija 1 dobija min. 20% CPU ciklusa, a particija 2 da dobije min 50% CPU ciklusa... QNX scheduler ce se postarati da to zaista bude tako i, u slucaju velikog opterecenja, vase particije ce sasvim sigurno dobiti bar onoliko % CPU vremena koliko ste im vi odredili.

Osim ovoga gore, QNX nudi i vise modela schedulinga za thread-ove istog prioriteta - mozete koristiti "Round Robin", "FIFO" ili "Sporadic" strategije u zavisnosti od toga sta zelite da postignete. Ovakav nivo kontrole schedulera se retko vidja u drugim OS-evima.

Ovo sto si spomenuo za postotke cpu ciklusa, koliko znam Solaris radi istu stvar.

Znaci, u Solarisu mozes da assignujes koliko % cpu-a ce odredjeni proces da ima na raspolaganju, i naravno da dodjeljujes cpu affinity...doduse, ovo zadnje mozes i sa Windows-om(?) i sa Linux-om.



Imho, nema ni potrebe da tcp stack bude u userspejsu, jer savrseno radi iz kernel spejsa.
Na bug se uvjek mozes da pozivas kao razlog, medjutim, u 10 godina koliko se bavim ovim poslom.. sjecam se samo jednog kriticnog buga u tcp/ip steku, koji je krsio citav kernel (na Linuxu, ne znam za Win).

I, da dodam, QNX vjerovatno ima svoju namjenu, gdje takav dizajn i ti featursi OS-a imaju neku vrijednost.
Linux ili Microsoft, ciljaju na drugo trziste, gdje te stvari sto QNX ima, nemaju vrijednost.. t.j. nisu trazeni... ista pricha vrijedi i za Solaris.

Zapravo, TCP/IP stack bi trebalo da bude tamo gde su mrezni drajveri, kako ne bi dolazilo do nepotrebnih context switcheva. Ako su mrezni drajveri u user-modeu, i TCP stack treba da bude tamo, i obrnuto.

E, sad, mrezni drajveri su i u Windowsu i u Linuxu u kernel-spaceu zbog brzine.

Medjutim, to je strahovito zrtvovanje sigurnosti - iz prostog razloga sto mrezne drajvere danas pisu firme koje ne brinu za kvalitet vec zele da sto pre izadju na trziste sa proizvodom.

Ja sam vise puta vidjao da mrezni drajver rusi OS - pre par meseci sam video kako nepotpisani SMC drajver za neki USB LAN adapter rusi Windows XP zbog internog stack-faulta, a ne sumnjam da na Linuxu nema istih takvih slucajeva.

Mozes da zamislis koliko ima kineskih/tajvanskih/i sl... drajvera pisanih za djubre hardver, i svaki od tih drajvera moze u bilo kom momentu da srusi ceo OS (Linux / Windows)... Da ne pricamo o masi outsource-ovanih developmenta u Indiji i sl..

Jednostavno, mislim da je to jako veliki rizik. Microsoft, doduse, ima onaj WHQL program, koji bi trebao da eliminise dosta bagovitih drajvera, ali ... na zalost, i taj program je kompromitovan ukoliko su u pitanju veliki igraci (ajd, cik ti ne dozvoli nekom velikom da ne izbaci proizvod)... Tako, recimo, Creative ima potpisane drajvere a mnogi od njih su bili blagi horor sto se stabilnosti tice.

Za takve stvari bih ja ipak ostavio drajvere u user-spaceu, pogotovu sto danas to nije neki veliki penal (vidi dole)



Fora je u tome sto su dizajnerska pitanja (monolitni / mikrokernel, gde treba da budu drajveri i sl...) resavana u doba kada je zaista imalo smisla drzati drajvere u kernel modu za Windows i Linux, recimo - pricamo o vremenima 486-tica koje su imale context-switcheve reda velicine nekoliko stotina mikrosekundi. Insistiranje na nekoj "cistoci" dizajna na tim sistemima je znacilo veliki gubitak performansi - setimo se Mach kernela.

Danas, na modernim sistemima, nema puno razlike u tome da li je drajver u user-spaceu ili u kernel-spaceu, a dokaz za to je odluka Microsofta da skloni sound-card drajvere u user mode, a poznato je da su bas ti drajveri jako osetljivi na latenciju pogotovu na visokim frekvencijama semplovanja...

Ne zelim da pocnem flame war i na ovoj temi, pa tako da nemoj se naci offended sad...

Im'o sam iskustva s dosta mreznih kartica, od nekih zhnj kartica za koje nikad u zivotu cuo nisam, pa do 3com, rtl.. i slicnih, vise mejnstrim kartica, t.j. poznatijih.
Sve kartice, osim jedne (3com nekakva) koje sam probao su imale GPL drajvere koji su sasvim fino radile, t.j. nikad nisam imao kernel panice na istim. Ukljucujuci i 3com third party drajver.
Ti drajveri, koji su ukljuceni u kernel su 100 % stable (osim 10gigE drajvera koji su u experimental fazi) .. ali, imao sam problema sa proprietary drajverima (neka divlja WiFi kartica). T.j. desavalo se poslije izvjesnog vremena da kernel totalno blokira, tako da... podrzavam to sto si napisao.
U SVIM slucajevima pucanja kernela, uzrok je ili los hardver, ili lose napisan drajver koji cacka nesto sto ne bi trebao.



Ne znam, meni se sound i ne cini toliko kriticnim... prije bih rekao da je grafika kriticnija. Kakva bi razlika u performansama bila kad bi graficki drajver bio u userspejsu u odnosu na kernel spejs.

Sound nije "kritican" sa stanovista usera - u smislu, nije problem da "krcne" - ali jeste kritican sa stanovista tajminga, pogotovu ako radimo sa jako velikim sempling frekvencijama.

Na danasnjim intel platformama sumnjam da bi dolazilo do velikog gubitka u performansama ako bi se efikasno resio drajverski sistem.



Imas dobro iskustvo, mada prost google search ukazuje da Linux pati od istih problema sa nekim vendorima:

http://lkml.org/lkml/2004/1/8/281
http://www.linuxquestions.org/...ic-with-ipw2200-module-385450/
https://bugs.launchpad.net/bugs/200142
http://ubuntuforums.org/showthread.php?t=588279&page=2

U principu ^ ovo gore pokazuje da losi network drajveri i te kako mogu da obore ceo sistem (BSOD - Windows, Kernel Panic, Linux)

Ne bih sad da ulazim u frekvenciju koliko se to desava na Windowsu, a koliko na Linuxu - posto bi se to zavrsilo sa potpuno besmislenim flamewarom, skoncentrisimo se na fakat da network drajver >moze< da obori Linux i Windows, i to je i te kako veliki problem sa stanovista stabilnosti.

Bio bih ipak mnogo srecniji da su mrezni drajveri u user-spaceu.

na prvom linku je test kernel 2.6.0 mislim da ne pokazuje ono sto hoces
(to jes sluzi svrsi u ovoj temi da 'pokaze' poentu ako se neko ne razume)
na drugom linku je ipw2200 drajver na 2.6.12 ,pre ulaska ipw u kernel pocev od 2.6.14?

treci link bi bio jedini relevantan,drajver u najnovijem kernelu na testnoj verziji 8.04
(imaju predlog resenja na linku)
cetvrti link je rtl818x koji frizira komp kad se ubaci wep *na 7.10 kernel 2.6.22 dok na 8.04
nije ubacen ovaj drajver, inace je 3d party

ako treba imam ja ovde puno te listinge sa oops-evima,pa da stavim nesto novije :D
Bas je lepo kad nesto tako napravi oops pa onda neki put pocne i da pisti :)

Ali da li cak i ako se prebace ovi drajveri u user space da ce onda da bude stabilnije?
onako laicki ,sumnjam,mislim da i iz user space moze da obori sistem.

Ne moze, iz user-spacea ne mozes oboriti moderni OS (Windows Vista, Linux, QNX...)* - jedino sto mozes je da izazoves unhandled exception koji ce OS da prikaze na ekranu i da ti ubije proces. Sa druge strane, ako je proces u kernel-modu, on je zapravo ekstenzija kernela i njegova korupcija korumpira i kernel memorijski prostor - jedino sto kernel onda moze da uradi je da izbaci poruku da je doslo do greske i da blokira procesor (to je na Windowsu BSOD, a na Linuxu Kernel Panic)

User-mode procesi nisu u stanju da izvrsavaju privilegovane instrukcije (na Intel arhitekturama se to izvodi tako sto user-mode procesi trce u tzv. "trecem prstenu" (ring3) dok kernel trci u nultom) i njihov memorijski prostor je potpuno van sisemskog, i kao takvi ne mogu da urade nista supervisor procesu (tj. kernelu)

Prost primer - probaj da iz user-mode procesa izvrsis neku privilegovanu instrukciju (recimo da uradis context switch, ili da izvrsis interapt), ili probaj da promenis neku adresu koja je u kernel-memorijskom prostoru (veca od 0x8000000), dobices "unhandled exception" ili "segfault" u zavisnosti od recnika OS-a ;-)

Dakle, i drajveri pisani u user modu ne mogu da obore sistem - mogu samo da obore sami sebe. Ko se seca Windowsa NT 3.5, recimo, sigurno je video kako se desavalo da video drajver pukne, i NT nastavi da radi.

Vidim da je Microsoft u Visti makao i USB drajvere u userland - sto je jako dobro, jer su i USB drajveri bili izvor kojekakvog zla, jer svako danas pise drajvere za kojekakve web kamere, bluetooth adaptere i sta ti ja znam...

U najgorem slucaju, ako ti pukne user-mode drajver, ostaces bez pristupa tom konkretnom uredjaju, ali ce ti OS nastaviti da radi - cak, trebalo bi da mozes i da restartujes taj drajver i da nastavis da radis kao da se nista nije desilo.

(*) Neki OS-evi, kao sto je Windows NT i njegovi derivati, omogucavaju user-mode procesima da zovu kernel rutine u ogranicenom maniru preko sistemskog DLL-a koji se zove "ntdll.dll" - ovi pozivi su pre svega korisceni od strane Win32 sistemskih rutina. NTDLL pozivi nisu dokumentovani od strane Microsofta (mada su manje-vise desifrovani po internetu) i uz pomoc tih poziva je nekada bilo moguce uraditi tzv. "privilege escalation" i ubacivanje koda u kernel memorijski prostor - time bi potencijalno user-space proces mogao da srusi sistem ili nesto jos gore, sto su koristili mnogi virusi... Danas je to jako tesko izvesti, i takvi exploiti se jako retko vidjaju i svaki kod koji to radi je cist malware

Ja potpisujem peticiju da se graficki drajveri prebace u user space. Meni nvidia satra Vistu (unisava mi omiljeni hobi napucavanja sa teroristima :D)

Lepo: evo, posle solidne pauze, poučne teme na ES Advocacy. Podseti me na The Tanenbaum-Torvalds Debate Ivan mu dođe Tanenbaum

Nece to ici lako - da bi se napravio efikasan user-mode graficki drajver morali bi da raspisu GUI layer ponovo tako da bude u user mode-u i da ume da efikasno iskoristi graficki drajver...

To znaci raspisivanje gomile komponenti - od drajverskog interfejsa (a taman su uveli onaj WDDM), preko directX-a, opengl-a i sl... Puno posla.

Doduse, Microsoft je ipak nesto uradio po pitanju grafickih drajvera - WDDM model izoluje graficki drajver tako da neke greske u WDDM drajveru ne obaraju ceo kernel, vec samo drajver - to su vlasnici NVidia kartica sigurno imali prilike da vide kada se ekran zatamni, i video se restartuje... Doduse, to nije savrseno (cesto se nekoliko sekundi posle desi plavi ekran)



:-)

Istini za volju, mnogo toga se promenilo od te cuvene debate... QNX je ipak pokazao da mikrokernel OS ne mora biti isto sto i spori OS, a takodje cena context-switcha danas nije ni priblizno ista ceni u tom vremenu kada su carovale 386 DX masine.

Mikrokernel OS-evi nude odredjene prednosti koje su jako bitne u mission-critical aplikacijama kada jednostavno ne mozes da dopustis da OS (kernel) padne... Zato je QNX i popularan u tim okruzenjima, mada neki od njegovih konkurenata (wxWorks) ne samo da su monolitni-kernel OS-evi, nego u wxWorksu sve aplikacije dele jedan isti adresni prostor i fakticki su jedan proces! Mogu da zamislim sta se desava ako neka od tih aplikacija krene da trashuje memoriju :)

Mislim da mane mikrokernel OS-eva nisu nesto sto je odgovorno za njihovu malu popularnost u sirokoj upotrebi, firma QNX jednostanvo nikad nije ni htela da nesto vise uradi sa tim OS-om od njihovih trzista, dok su drugi vendori (Microsoft, Apple) uzeli delove dizajna Microkernel OS-eva i kombinovali ih sa monoliticnim dizajnom tamo gde je to imalo smisla na Intel platformi.

Nazalost u mom slucaju uvjek :/

I ja imam problema sa nVidia drajverima na Visti. Krene on tako da gasi monitor i ništa ne mogu raditi. Ali ja rješavam problem tako da drajvere instaliram iz safe mod-a, i onda je sve OK.

Offtopic, informacije radi... oops nije isto sto i panic.
Kad se desi panic, tu je kraj... kad se desi oops, to je indikacija da negdje u kodu postoji neki bug, pa ako ti recimo, mreza, prestane da radi... mozes da reloadujes drajver pa da nastavis da radis.

Mada, mozes ti da uradis recimo
echo "1" > /proc/sys/kernel/panic_on_oops

Pa da tako na kraju oops-a pozoves panic() syscall
i onda
echo "1" > /proc/sys/kernel/panic

Da automatski rebootujes sistem ako se desi kernel panic.

Sad, nazad na topic.
Bilo bi dobro da drajveri (pricam o mreznim) rade na vishem nivou. To bi znacajno poboljsalo stabilnost svih OS-ova... medjutim, sta bi se desilo kad bi odredjeni procesi zakucavali cpu ili uzimali cpu snagu na i/o wait-u ?

Recimo, imas 30mbps outbound traffic, puno procesa koji odradjuju neke operacije tipa SQL/Web ili ne bitno, striming... ? Dolazilo bi do varijacija i neefikasnosti mreze.

Evo ti real life example.. meni se desavalo da se toliko server zakuca, da mu se ne moze prici niti sta, ali mreza i dalje radi. I krucijelni servisi i dalje rade... sto je poprilicno handy, jer ako iznajmljujes server od the planeta, zagarantovan ti je ultra mega giga losh support i da cekas 5 sati za reboot ili tako nesto.
Sve je to moguce odraditi, ali (vjerovatno) nije lako implementirati da radi kako treba... zato vjerovatno niko i ne pokusava.

Pravilan rad mreze je krucijelan, i userland procesi ne smju da degradiraju performanse iste ni pod kakvim uslovima.
Pogotovo kad je remote odrzavanje/ili_sta u pitanju.

Pazi,

Na dobro dizajniranom OS-u to ne bi smeo da bude problem, ISR rutine obicno imaju prioritet niti 255 - sto znaci da pre-emptuju bilo koji drugi thread, osim thread-ova koji imaju prioritet 255, a to su drugi interapti.

Da li je mrezni drajver u userlandu ili u kernel-modu nema nikakve veze sa stanovista prioriteta. ISR je 255, a ISR se koristi kada stigne mrezni paket preko interapta za obradu.

Na primer, mreznom drajveru mozes setovati visok prioritet + prioritet od 255 za ISR i, takodje, recimo pod QNX-om kreirati adaptivnu particiju koja kaze da mrezni drajver mora dobiti bar 5% CPU-a ako on to zeli.

I to je to... pravilno dizajniran pre-emptive multitasking OS bi se vrlo lako izborio sa tim u momentima opterecenosti sistema.

Sa stanovista schedulinga, ne bi trebalo da bude razlike izmedju user-mode i kernel-mode procesa - jedino sto je bitno je prioritet, i da li je u pitanju ISR ili normalna funkcija.

To da, ali to pravilno dizajniran je kljucno. Prvo zato sto Linuxov (a vjerovatno ni Windows-ov) kernel nisu tako dizajnirani, da to rade... znaci trebali bi mass rewrite da urade i da onda testiraju taj kod 2 godine dok se to ne ustabili malo.

Preemtion imaju, medjutim, preemtion koji je dizajniran ovako kako jeste, nije efektivan(u svim situacijama)... i definitivno nije prepourcen na bilo kakvim production sistemima. Eventualno na desktopima i to je to.. sto znaci da se na to ne moze osloniti.

Ali kao ideja za research i rad, nije lose...

Hm hm

Mislim da sam potpuno siguran da u Windowsu i Linuxu thread sa prioritetom 255, tj. ISR ima potpuni pre-emtpion i da tu nije problem, jer su svi user-mode procesi u kojima trce aplikacije na nizem prioritetu (osim, ako nisu pisane da traze najvisi prioritet sto je losa praksa u dizajnu) - i da bi uz pazljiviji dizajn bilo moguce napraviti network stack koga nije moguce ugroziti ni iz user moda.

Ono gde jeste problem, je da ISR moze blokirati ceo sistem, ali taj problem postoji i kod QNX-a u teoriji - i na bilo kom OS-u koji se izvrsava na modernim arhitekturama procesora.

E, sad, QNX to resava na prost nacin - vecinu drajvera pise QNX ;-) Tako da mogu da garantuju da ni jedan drajver nece da blokira kernel sa ISR-om koji ne vraca kontrolu...

Obicno se to radi tako sto:

a) ISR samo scheduluje novi thread, ili setuje event i odmah vraca kontrolu kernelu, a onda u drugom threadu radi sta vec treba da radi, a u ISR-u se rade iskljucivo time-critical stvari (tipa, ako je DMA bafer prepun)

b) Na QNX-u je moguce registrovati interapt hendler ne kao ISR, vec kao event, i u tom slucaju nema nikakvog blokiranja jer kernel nikad ne daje kontrolu interapta drajveru, vec drajver dobija samo event - problem sa ovim je sto u slucaju da neki drugi proces istog prioriteta nije zavrsio (neki drugi drajver, recimo), tvoj drajver ima nepredvidljivu latenciju dok na njega ne dodje red

U Windowsu i Linuxu je to daleko teze, jer drajvere pisu svi - pa latencija nije garantovana jer, recimo, neki neposlusni drajver moze da zadrzi kontrolu nad sistemom za vreme ISR-a.

Mada, cenim da se to jako retko dogadja i na Linuxu i na Windowsu NT (Vista/XP) ako se dogadja uopste, osim ako nemas bas neki skrndelj drajve koji je pisala neka budala - vecina drajvera se pisu uz pomoc DDK-a koji ima jako lepe primere sta treba i sta ne treba raditi.