Nei piani futuri di Research In Motion c'è QNX

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwfiles.it/news/nei-piani...qnx_33902.html

Research In Motion potrebbe in futuro abbandonare lo sviluppo di BlackBerryOS in favore di QNX

Click sul link per visualizzare la notizia.

[Opteranium]

ma qnx non era il s.o. che gira sulle centrali nucleari, lo shuttle e robot chirurgi?

ora anche i tablet?

[pabloski]

la cosa divertente è che c'è gente ( non qui su hwupgrade per fortuna ) che afferma candidamente e con convinzione che sistemi come qnx non sono general purpose

evidentemente questa gente dovrebbe ritornare a scuola

comunque sia era logico che sarebbe finita così...qnx è un sistema operativo molto molto più avanti rispetto alla massa....nel mondo open ci vorrebbe una cosa del genere, speriamo che haiku smuova un pò le acque

[Fulvi0]

che amarcord QNX

impossibile dimenticare la demo su floppy... un S.O. con interfaccia grafica in un dischetto. C'era di che far stupire gli amici

[an-cic]

Originariamente inviato da Fulvi0

che amarcord QNX

impossibile dimenticare la demo su floppy... un S.O. con interfaccia grafica in un dischetto. C'era di che far stupire gli amici

di quanto tempo fà parli?

se andiamo molto indietro negli anni ce n'erano anche altri con interfaccia grafica che si caricava da dischetto!!!

ammetto che fino alla presentazione del playbook non avevo mai sentito parlare di qnx, ma stò dando un occhiata in giro e sembra molto interessante.

[checo]

Originariamente inviato da Opteranium

ma qnx non era il s.o. che gira sulle centrali nucleari, lo shuttle e robot chirurgi?

ora anche i tablet?

gira dove gira ci fossero app adatte all'uso domestico sarebbe pure general

[eeetc]

Originariamente inviato da Fulvi0

impossibile dimenticare la demo su floppy... un S.O. con interfaccia grafica in un dischetto. C'era di che far stupire gli amici

Come non quotarti!

[JackZR]

Spero fondano i due progetti invece di scartare completamente il vecchio.

[s0nnyd3marco]

Originariamente inviato da pabloski

la cosa divertente è che c'è gente ( non qui su hwupgrade per fortuna ) che afferma candidamente e con convinzione che sistemi come qnx non sono general purpose

evidentemente questa gente dovrebbe ritornare a scuola

comunque sia era logico che sarebbe finita così...qnx è un sistema operativo molto molto più avanti rispetto alla massa....nel mondo open ci vorrebbe una cosa del genere, speriamo che haiku smuova un pò le acque

Perdonami, ma dire che qnx sia un sistema general purpose non e' corretto. Qnx e' un os realtime nato per sistemi embeded o dedicati all'automazione industriale. Mi spieghi a che servono le estensioni realtime ad un pc domestico?
Haiku non e' un os realtime, ma come il defunto beos, puntava molto alla multimedialita'. E sinceramente non credo che al team di sviluppo di haiku possa fregare qualcosa di entrare in quel mondo.
Se cerchi strumenti opensource per il realtime ce ne sono parecchi: uno di questi e' rtai.

Poi mi spieghi cosa intendi quando dici che qnx e' piu' avanti rispetto alla massa?

[niko717]

Originariamente inviato da s0nnyd3marco

Perdonami, ma dire che qnx sia un sistema general purpose non e' corretto. Qnx e' un os realtime nato per sistemi embeded o dedicati all'automazione industriale. Mi spieghi a che servono le estensioni realtime ad un pc domestico?
Haiku non e' un os realtime, ma come il defunto beos, puntava molto alla multimedialita'. E sinceramente non credo che al team di sviluppo di haiku possa fregare qualcosa di entrare in quel mondo.
Se cerchi strumenti opensource per il realtime ce ne sono parecchi: uno di questi e' rtai.

Poi mi spieghi cosa intendi quando dici che qnx e' piu' avanti rispetto alla massa?

Io una volta ho installato QNX sul mio pc, e devo dire che volevano "convertirlo" per uso domestico.... aveva supporto mp3, browser e tutte cose che sono richieste da un pc desktop. Purtroppo però alla fine ha fatto una brutta fine (io stesso l'ho subito disinstallato perchè non mi piaceva e creava solo problemi )

[jappilas]

Originariamente inviato da pabloski

la cosa divertente è che c'è gente ( non qui su hwupgrade per fortuna ) che afferma candidamente e con convinzione che sistemi come qnx non sono general purpose

il fatto è che ... non è del tutto inesatto, quantomeno sotto certi aspetti

quello che come si diceva all' inizio, rende QNX (ed altri sistemi della sua classe, tipo vxworks) adatto all' impiego nelle centrali nucleari, ma anche su robot chirurgici, elettromedicali, apparati di controllo ecc ecc, è il fatto di essere un OS realtime ovvero di supportare lo sviluppo e l' esecuzione di processi realtime - la cui caratteristica base come ogni programmatore sa, è di essere sottoposti a stringenti vincoli temporali (ad esempio sul tempo da cui un' operazione dev' essere eseguita ed entro cui dev' essere completata - e superato il quale si può parlare di fallimento)
ora, per garantire il rispetto di tali vincoli il sistema operativo dev' essere il più deterministico possibile (le latenze di system call e interrupt devono essere note, o quantomeno superiormente limitate con certezza, quantomeno per quel sistema su quell' hw), e deve mettere a disposizione delle facilities (come algoritmi di scheduling e meccanismi di sincronizzazione ad hoc) e un comportamento idonei all' esecuzione real time, su cui i progettisti di applicazioni ( il sistema di controllo della centrale dal punto di vista di neutrino - il microkernel di QNX - è nè più nè meno che un' applicazione) possano contare
ma la cosa interessante è che poi il sistema composto da applicazione realtime e kernel realtime, è tipicamente sviluppato staticamente, a partire da quest' ultimo, dalla conoscenza degli upper bound sulle latenze, e dei requisiti dell' applicazione (noti a priori, spesso e volentieri corrispondenti a variabili fisiche - tempo di apertura di una valvola, di spostamento di un attuatore, di acquisizione di un segnale a una certa frequenza eccetera) facendo attenzione, ad esempio, a che la somma delle risorse (cicli cpu, quindi timeslice) richieste da tutti i processi presenti in condizioni nominali, non superi quelle totali a disposizione (sull' hw target, ovvero su una specifica cpu - magari embedded - piuttosto che una famiglia di processori, con diverso clock, magari con diverso IPC) o magari una certa percentuale di quelle a disposizione - questo perchè certi algortmi di scheduling RT vanno in crisi se l' occupazione di risorse è maggiore del se non ricordo male, 75-80%, limite che spesso e volentieri è il sistema stesso a far rispettare, negando l' esecuzione di un processo che porterebbe l' occupazione al di sopra di esso
anche per questo un sistema RT prevede tipicamente un meccanismo di resource request che il processo usa per allocare delle risorse già note e determinate dallo sviluppatore
e già qui si nota la sostanziale differenza con un sistema general purpose, su cui tale meccanismo tipicamente, manca (in quanto effettivamente non necessario, dal momento che tipicamente quello che si cerca è proprio la saturazione - tanto, l' importante è che i task in sospeso "prima o poi" vengano eseguiti, se anche la cpu è al 100% semplicemente verranno completati in più tempo) ma su cui lo stesso sviluppo segue un approccio tipicamente opposto (e non si vede nessuno calcolare le risorse richieste a priori preoccupandosi di quanti millisecondi impiega la tale funzione ad eseguire)

ora, anche un sistema general purpose può eseguire dei task realtime ( ma a meno che le latenze del kernel non siano deterministiche, e non si giri senza paginazione su disco - che allunga i tempi di esecuzione, ma soprattutto li rende non più controllabili da chi progetta l' applicazione, motivo per cui si impone che questa giri interamente in ram - le applicazioni la certezza che le deadline non verranno sforate non la possono avere, quindi potranno essere solo task soft realtime) con un meccanismo best effort che li faccia passare prima di quelli a priorità normale e non li interrompa una volta in esecuzione - in sostanza eseguendoli a priorità maggiore del kernel stesso
questo è quello che in effetti si fa su windows, sulle versioni mainline (poi esistono progetti per il supporto più o meno completo del realtime hard) di linux e su altri sistemi general purpose
d' altra parte è anche l' unica cosa che il kernel possa fare su un sistema general purpose, ed anche l' unica che abbia senso fare, su un sistema che ha scopi, metodologie di sviluppo e comportamento di runtime radicalmente diversi da quelli di un sistema realtime
questo può in effetti operare nei contesti in cui altrimenti si userebbe un sistema general purpose (e non viceversa), ma ... eseguendo le stesse applicazioni di quest' ultimo, e non applicazioni realtime in un contesto completamente realtime (e si è visto che basta attivare la memoria virtuale e lo swap su disco per uscirne) opererebbe nè più nè meno come quest' ultimo
allora, dove starebbe il vantaggio? nella gui più reattiva?
ma per rendere più reattiva la gui non è necessario un OS realtime - che lo sia, è un pregiudizio tramandatosi a causa di sistemi non ottimizzati per il desktop e dotati di gui inefficienti - per avere una gui reattiva basterebbero meccanismi di prioritizzazione dei processi interattivi, a livello di operazioni di IO, e un threading efficiente (entrambe cose che per dire, BeOS e Haiku avevano - e soprattutto il primo è ricordato come IL sistema desktop più reattivo e leggero, eppure NON era un RTOS)

evidentemente questa gente dovrebbe ritornare a scuola

forse non vale solo per "questa gente"...

comunque sia era logico che sarebbe finita così...qnx è un sistema operativo molto molto più avanti rispetto alla massa....

più avanti, no
piuttosto, "diverso" dalla massa, per il semplice motivo che la massa è costituita da sistemi general purpose, e non RTOS

nel mondo open ci vorrebbe una cosa del genere, speriamo che haiku smuova un pò le acque

a che scopo? vuoi haiku sul suo prossimo elettrocardiografo?

[s0nnyd3marco]

Quotone per jappilas.

[grs]

jappilas ha ragione sul fatto che qnx non è general purpose, ma quando dice che non serve il real time sul desktop io sono piuttosto scettico (parlo di soft, ovvio che non serve l'hard real time, anche perché con processori più complessi dei semplici PIC ... anche per un "misero" ARM ci vuole analisi statica del codice ecc.)

Al giorno d'oggi, in qualsiasi campo dell'informatica si fa un gran parlare di QoS (networking, embedded su cellulari, ma persino sui servizi web si incomincia ...). I "giochini" sulla priorità vanno bene per la GUI, ma quando si ragiona di applicazioni multimediali, magari con input da rete (anche questa da gestire real-time per questioni di buffer ecc.) non sono più tanto sufficienti.

Inoltre, siamo al punto di complessità dell'hardware (e di conseguenza dei driver) in cui bisogna ritornare al "sogno" del microkernel e abbandonare i driver in spazio kernel. E se con l'hardware ci parla un processo, anche questo ha vincoli temporali (almeno se vogliamo un sistema che risponda in tempi ragionevoli, perché ovvio che l'hardware del PC aspetta il processore, non è un carro-ponte che non lo ferma nessuno).

Insomma, io non direi che sul desktop non ci vorrebbe il real time. Peccato che non si può ri-iniziare un OS da capo tutte le volte ...

[MaxArt]

Jappilas, mi hai dato molte più informazioni sintetiche di quante mi sarei aspettato di leggere riguardo a QNX. Grazie mille

[littlecesare]

ottima sintesi, jappilas.
A dimostrazione di tutto ciò, qnx è da anni utilizzato come s.o. host nei simulatori di volo (quelli veri), proprio per vedere garantiti i tempi di esecuzione (stringenti), e la sequenzialità, dei numerosi task.

[jappilas]

WARNING - LONG POST

Originariamente inviato da grs

jappilas ha ragione sul fatto che qnx non è general purpose,

mi dispiace dirtelo, ma hai frainteso il senso del mio discorso - o forse, possibilissimo, non mi sono spiegato bene io
il discorso non era "QNX non è general purpose" (perchè in effetti QNX può anche far girare applicazioni posix, compilate ad hoc ma "normali", non realtime, in ciò comportandosi da OS general purpose)
il punto era che il punto di forza di QNX e di un OS realtime in genere non dà benefici se non entrando in un particolare contesto, di progettazione ed esecuzione delle applicazioni, che non è più quello general purpose, ed anzi per certi versi è contrario di quello che si cerca di ottenere in ambito general purpose - ma il contesto, non il sistema operativo

ma quando dice che non serve il real time sul desktop io sono piuttosto scettico (parlo di soft, ovvio che non serve l'hard real time, anche perché con processori più complessi dei semplici PIC ... anche per un "misero" ARM ci vuole analisi statica del codice ecc.)

se sul desktop è "ovvio che non serve l' hard real time", allora sempre sul desktop non servirà (o non porterà benefici sostanziali) nemmeno un sistema la cui ragion d' essere siano i task hard realtime, come QNX...

Al giorno d'oggi, in qualsiasi campo dell'informatica si fa un gran parlare di QoS (networking, embedded su cellulari, ma persino sui servizi web si incomincia ...). I "giochini" sulla priorità vanno bene per la GUI,

attenzione che comunque io parlavo di prioritizzazione delle applicazioni gui rispetto a quelle non interattive a livello di operazioni di IO - non di priorità realtime
assegnare priorità realtime a un processo su un sistema general purpose (cosa che puoi provare anche su windows, da Task Manager) comporta una forte probabilità (a seconda principalmente del tipo di task, se compute o IO bound) di rendere il sistema meno reattivo - perchè in pratica si dice al kernel di eseguire quel processo prima di tutti gli altri e senza interromperlo (quindi, senza eseguire altre operazioni di IO che quelle richieste da lui se non quando "avanza tempo", ovvero negli sporadici momenti in cui questo è in attesa volontaria) , cosa che porta a starvation gli altri processi e il kernel stesso che può avere delle operazioni in sospeso in thread (sì anche il kernel ha dei suoi thread) a priorità minore

ma quando si ragiona di applicazioni multimediali

quando si ragiona di applicazioni multimediali la prima cosa da tenere presente è questa: i sistemi su cui è basata la totalità dei desktop attuali sono sistemi general purpose, non sistemi RT; le applicazioni multimediali in circolazione sul desktop (giochi, media player, skype, eccetera), girano (tutte, senza eccezioni) su sistemi general purpose come processi a priorità normale, non su sistemi RT - e mi pare che funzionino egregiamente

la seconda è che le applicazioni multimediali sono generalmente applicazioni il cui comportamento è funzione in un modo o nell' altro del tempo ma che non pongono stringenti vincoli temporali
tipicamente si implementa un loop che misura i milli/microsecondi effettivi trascorsi dal run precedente, lavora, e riarma un timer periodico o nel caso di applicazioni interattive si pone in attesa di eventi; in base al deltaT misurato si ricalcolano le posizioni degli oggetti sulla scena (se gioco a saturazione di fps) o si decide se ricalcolarle e rirenderizzare la scena (se si desidera un numero di fps costante, comunque ovviamente <= di quelli che il sistema può sostenere) o, se presentare un nuovo frame (se sto riproducendo video) o cosa fare dei pacchetti da elaborare ancora in coda (scartando quelli in arrivo se il loro timestamp è <= di quelli che l' applicazione è arrivata a consumare)

se non si riesce a calcolare un frame in tempo per presentarlo al prossimo 25esimo disecondo, o se si perde qualche pacchetto o .., non è la morte di nessuno - certo, si cerca di evitare che ciò accada (ad esempio ottimizzando il codice rendendo il loop più efficiente) e di minimizzare l' impatto sull' utente (ad esempio prevedendo forme di ricostruzione almeno parziale dell' informazione trasportata dai pacchetti che si possono perdere per strada o che si può dover scartare a destinazione) ma se ciò accade, non è da escludere che sia la CPU o la rete a non essere in grado di sostenere il carico computazionale...

la terza è che sebbene alcune applicazioni (magari, audio) beneficino di latenze sotto una certa soglia, una parte consistente di queste sono date dall' attraversamento dello stack sonoro (che spesso e volentieri impone l' inserimento dei campioni in una coda di una certa lunghezza) o dalla dimensione che si sceglie / si può usare per i fragment - la riduzione delle latenze applicative parte quindi dal tuning di questa o dall' uso di una API che permetta un accesso più immediato all' HW sonoro (caso tipico, ASIO), che non dall' esecuzione in modalità con priorità realtime (con il rischio di peggiorare il funzionamento del resto del sistema )

magari con input da rete (anche questa da gestire real-time per questioni di buffer ecc.)

la quasi totalità dei sistemi operativi usati in rete, da linux a windows (/server) passando per i vari *BSD ( il cui stack di rete è stato anzi storicamente ritenuto l' implementazione di riferimento), per solaris, eccetera, non sono RTOS, eppure funzionano
il loro stack di rete prende magari degli accorgimenti per ridurre la latenza di elaborazione di un pacchetto (ad esempio con code path più brevi o lock a granularità più fine), o l' impegno sulla cpu in caso di elevato volume di pacchetti (ad esempio accorpando più pacchetti per ogni passata della routine di servizio dell' interrupt), ma basta

se poi si parla di quality of service su internet / IP (cosa che peraltro è per un certo tempo stata considerata un ossimoro data la natura best effort di internet), guarda caso i due approcci che mi risultano essere stati messi in pratica fiora prevedono proprio, uno un protocollo di allocazione di banda (di modo da riservare quella sufficiente ad avere jitter e perdita di pacchetti minori possibile, durante lo streaming dei dati) - ma è un approccio poco scalabile e costringe le applicazioni a dichiarare le caratteristiche del loro traffico che devono essere note a priori, per cui si preferisce il secondo - e l' altro, una priorità maggiore assegnata ai datagram (con un campo che peraltro è rimasto ignorato per parecchio tempo )

Inoltre, siamo al punto di complessità dell'hardware (e di conseguenza dei driver) in cui bisogna ritornare al "sogno" del microkernel

che si possa, può darsi, ma che "bisogni" è una tua personalissima impressione - per quanto mi riguarda, seguo l' evoluzione dei vari kernel da abbastanza decenni da rendermi conto che quello dei microkernel in ambito mainstream resterà un sogno, almeno per molto tempo ancora...

un microkernel non è nulla di fantascientifico nè tantomeno la panacea per i problemi dei kernel attuali, ma nè più nè meno che un kernel minimale che includa lo scheduler e poco altro
soprattutto, anche un microkernel è nè più nè meno che un kernel monolitico classico, una soluzione di compromesso, solo una che privilegia la robustezza e semplicità interna a discapito di prestazioni (che calano drasticamente a causa dei context switch e della comunicazione interprocesso locale, il carico sulla quale aumenta esponenzialmente) e semplicità sistemica (che cala anch' essa, aumentando i componenti vitali spostati in userspace, che richiederanno la progettazione di api e protocolli per ciascuno, per interagire tra loro e col kernel) laddove il kernel monolitico fa l' esatto opposto
non è un caso che i microkernel abbiano avuto successo: nella ricerca, dove la loro spartanità consentiva a team di pochi sviluppatori (in taluni casi singoli) di gestirne comunque agevolmente la codebase - e nelle applicazioni dove si ricerca la massima robustezza e dove quindi poter riavviare in modo trasparente singoli componenti erratici a seguito di errori (che su un macrokernel porterebbero a crash del sistema e alla necessità di riavviare) e poter contare sul fatto che il codice privilegiato presente a runtime sia lo stretto indispensabile, val bene lo scotto di prestazioni inferiori
inferiorità prestazionale che comunque si riferisce ad un ipotetico caso di perfezione architetturale da una parte e dall' altra in cui per entrambi non via sia più margine di ottimizzazione algoritmica, possano contare sugli stessi meccanismi implementativi (sopratutto per aspetti come la IPC) e l' unica discriminante divengano i context switch (a cui il sistema a microkernel deve per forza di cose sottostare )
ma nella realtà le due tipologie di sistemi raramente adottano gli stessi meccanismi - che in alcuni casi sono accorgimenti adottati inizialmente dai microkernel per sopperire almeno parzialmente al maggiore overhead intrinseco di cui sopra, ma di cui altri kernel non hanno voluto dotarsi a volte per ragioni non tecniche (è il caso della IPC a messaggi o dei meccanismi di local procedure call ottimizzati, guarda caso adottati prima su microkernel poi mutuati da solaris -con le Doors- e da NT - con la quickLPC - ma non da linux - che ancora basa sui socket la propria IPC nativa, motivo per cui per android google è stata costretta a integrare un modulo ad hoc, e una api ad hoc)
nè le due tipologie di sistemi sono, solitamente, paragonabili sotto aspetti quali il grado di preemptability, cioè quanta parte del codice che li compone può essere interrotto in modo asincrono e quanto invece va eseguito in modalità esclusiva
premesso che certe operazioni, o l' accesso a strutture dati condivise tra più cpu, in ogni caso e su ogni sistema non possono e non devono essere scavalcate - non è difficile trovare microkernel che si dichiarino "fully preemptable" (tipicamente siginifica che si è riusciti a ridurre il codice esclusivo a singole operazioni eseguite atomicamente come singole istruzioni privilegiate o brevi sequenze "disattivazione interrupt - accesso - riattiva interrupt", e mantenere il grosso del kernel interrompibile / rientrante)
mentre è molto difficile trovare kernel preemptable tra quelli monolitici (anzi, fino a non molti anni fa era difficle trovare kernel monolitici che andassero al di là del famigerato lock globale), essendo non banale sia concepire un kernel in cui componenti di alto (filesystem) e di basso (drivers) livello lavorino concorrentemente nello stesso spazio di indirizzamento, ed essendo ancora meno banale padroneggiarne la code base nel tempio e aumentare *a posteriori* la granularità di lock

questo nonostante il beneficio apportato alla reattività del sistema dall' aumento della granularità di lock, o dal passaggio a operazioni atomiche, e dalla riduzione della syscall latency, essendo persi meno, o nessuno, eventi di input, e avendo la possibilità di elaborarli più tempestivamente rientrando prima dal kernel all' applicazione
reattività che costituisce un aspetto cruciale dell' esperienza d' uso in ambito desktop ma che paradossalmente non vedo mai quantificata (misurando ad esempio le latenze richieste nell' esecuzione di operazioni gui lo spostamento del mouse, il redraw di una finestrea , ecc ) - invece, i soli "benchmark" in circolazione si limitano a misurare il throughput e il tempo di esecuzione di programmi di compressione e transcoding ignorando bellamente tutto ciò che concerne l' interattività del sistema - motivo per cui la phoronix test suite lascia alquanto il tempo che trova...

e abbandonare i driver in spazio kernel.

in un driver (inteso come tutto il codice necessario a far funzionare un device tra più applicazioni) si può generalmente identificare una parte di comportamento centralizzato, e una parte di comportamento decentralizzato (ad esempio rispettivamente le routine di arbitraggio e creazione dei device context, e i comandi di disegno all' interno di un singolo device context, nel caso dello stack grafico)
la prima parte è anche quella che tipicamente necessita di privilegi di runtime e di debug esaustivo, visto che un suo errore può portare al blocco della macchina (diversamente ad un bug nella seconda parte in cui il peggio che si rischia è un errato disegno del contenuto della finestra, fastidioso ma non fatale) - essendo il kernel l' unico componente privilegiato attivo sul sistema nonchè "quello che arbitra le risorse hw tra i vari processi userspace", ha senso consolidarla in esso e lasciare all' esterno la parte decentralizzata (magari come libreria ad uso delle applicazioni)
nella progettazione dei microkernel si è messo da parte questo attuando una ripartizione ortogonale delle responsabilità dei singoli componenti (con il kernel che si occupa solo dello scheduling e della ipc, il file system che compete all' agente VFS, la grafica che compete all' agente grafico eccetera ), anche per evitare di "pestarsi i piedi" tra sviluppatori di parti di codice logicamente correlate, ma soprattutto per rendere il singolo componente padroneggiabile e manutenibile da pochi sviluppatori o da uno solo (come capita spesso che sia nei team di OS research di nicchia), esperto di quel particolare tipo di codice

certo, il risultato netto di ciò è che se un driver (a questo punto più "agent" o servizio, che driver) va in crash, è possibile riavviarlo - ma questo al costo, come si diceva in precendenza, di un certo overhead architetturale, mitigabile ma non eliminabile, e soprattutto con limitati vantaggi per l' utente finale (per il quale non è diverso da poter/dover riavviare la macchina a seguito di un BSOD/kernel panic, se in entrambi i casi l' applicazione grafica è chiusa / perduta prima di aver salvato i dati...) se non in particolari situazioni in cui appunto la robustezza del kernel viene prima di tutto

pensare che se con i microkernel i driver sono stati spostati all' esterno si debba imitarli supinamente per qualunque nuovo kernel senza pensare alle implicazioni e allle motivazioni all' origine dietro questa scelta, sarebbe un errore

E se con l'hardware ci parla un processo, anche questo ha vincoli temporali (almeno se vogliamo un sistema che risponda in tempi ragionevoli <...>

nel corso degli anni sono esistiti microkernel realtime e non realtime, ed anche quelli non realtime funzionavano egregiamente sull' hw per cui erano sviluppati (di nuovo su tutti, BeOS, NON RT e sviluppato in origine su dei PPC da 60 Mhz - e da tutti ricordato come l' apoteosi della reattività sul desktop)
se vogliamo un sistema che risponda in tempi ragionevoli non c'è bisogno di task realtime ( e di un kernel RT) a incapsulare dei driver usermode (che altro non fanno se non inviare comandi all' HW passando per il microkernel - le IO port o loro equivalenti sono solitamente feature della cpu che il kernel incapsula e presenta come primitive di comunicazione - e gestire gli interrupt, per i quali si registrano come handler presso il kernel per venirne notificati)
la cosa da fare è intervenire sui colli di bottiglia, a cominciare dalla comunicazione interprocesso e/o da quello per cui questa viene usata - che in effetti dopo la prima generazione di microkernel si è visto essere l' invio ad un processo di argomenti di qualche metodo e la ricezione di dati in risposta, ovvero chiamate di procedure locali (LPC)
da qui alle successive interazioni che dapprima ottimizzavano la IPC tra processi locali eliminando le copie di buffer e usando la condivisione della memoria, e in seguito (come appunto le Doors di Solaris, l' LRPC su Mach o la QUickLPC di NT) eliminavano il marshaling necessario anche sui messaggi in shared memory, passando gli argomenti sui registri o su uno stack condiviso e cedendo direttamente il controllo al processo server)

Peccato che non si può ri-iniziare un OS da capo tutte le volte ...

in effetti è un peccato, ma non tanto per il motivo che pensi, quanto perchè con il tempo si radicalizzano concezioni errate sul perchè certi sistemi sono nati e funzionano nel modo in cui funzionano - e sul fatto che se un sistema "odiato" contiene determinate soluzioni tecniche, allora non sia corretto riprenderle ...
quando spesso e volentieri meriterebbero proprio di essere applicate in un nuovo sistema, per diffonderle e diffondere la mentalità intorno ad esse