Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 68

Newsletter 68

by Z98 on 2010-01-22
translated by Gabriel ilardi on 2010-01-22

ARWINSS, la terza volta andrà bene, forse

C'è stato un crescendo di speculazioni sul cosa sia ARWINSS, a cosa serva, e cosa faccia, nonostante diverse indicazioni da parte di Aleksey Bragin. Le speculazioni hanno raggiunto il punto dove persone con informazioni parziali facevano affermazioni come se fossero vere quando spesso e volentieri queste erano incorrette. ARWINSS non intende 'sostituire' l'attuale sottosistema Win32. Esiste come uno sforzo parallelo per rimediare alle limitazioni correnti dell'attuale sottosistema Win32 applicando un design diverso invece che duplicando quello Windows NT. Inoltre, ARWINSS è legato solo al sottosistema Win32, che è solo parte del progetto è non rappresenta il sistema operativo nel suo complesso. Quindi frasi come ReactOS fa un 'reset' o 'ricomincia' sono a dir poco molto esagerate. Col passare del tempo i meriti o demeriti tecnici di ARWINSS saranno evidenti in tanto i lavori su tutti i due continueranno, ma non c'è niente che possa escludere uno piuttosto che l'altro. In questo modo forniamo una visione strategica di alto livello di ARWINSS e fortunatamente mettiamo in chiaro che non stiamo rimescolando il progetto ed il design di ROS.

Per quanto riguarda ARWINSS stesso, l'implementazione è basata sull'architettura che usa attualmente Wine. Ci sono diversi strati in Wine, la maggior parte del codice riutilizzabile si trova sopra un driver user mode che astrae il sistema grafico sottostante. Ci vuole un driver a parte per ogni sistema grafico nel quale si vuole usare Wine e attualmente esiste un driver X11 chiamato winex11 assieme ad un driver Quartz che è in fase di sviluppo. Non esisteva un driver per il sistema grafico Win32, sarebbe stato ridondante. ARWINSS tuttavia lo implementa, si chiama winent, è funge come strato tra le diverse DLL di Win32 che implementa Wine e il componente lato kernel del sottosistema Win32, Win32k. Tradizionalmente tali DLL farebbero chiamate a Win32k tramite syscalls, ma come abbiamo detto precedentemente l'implementazione Wine si aspetta uno strato intermedio. In più, il driver user mode solo gestiva la comunicazione con il sistema grafico e certi altri servizi o risorse delle DLL di cui aveva bisogno Wine venivano forniti da wineserver. Fortunatamente, la maggior parte delle funzionalità che forniva wineserver erano già state implementate in ReactOS quindi Aleksey ha reindirizzato le chiamate che facevano le DLLs a librerie e funzioni di ReactOS. La presenza di winex11 in certi diagrammi e anche nel repositorio hanno portato a certe persone a pensare che ReactOS stesse cercando di usare X Window.  Tuttavia, come detto precedentemente, winex11 esisteva già ed è stato semplicemente trascinato dietro come parte dell'importazione iniziale. Certamente non viene usato in ReactOS ed è stato effettivamente sostituito dal driver winent che Aleksey ha scritto. Quindi nessuno degli sviluppatori che hanno lavorato in ARWINSS ha avuto alcuna idea riguardo X Window e l'attenzione fatta a X11 è stata una sorpresa visto che non aveva niente a che fare con il loro lavoro.

Bisogna chiarire un'altra cosa riguardo la differenza tra ARWINSS e Wine in Unix. Siccome il Sistema X è sempre stato in user mode, la comunicazione con esso richiedeva una specie di RPC (remote procedure call) e per diverso tempo X Window offriva poco per velocizzare o minimizzare queste chiamate. Comparandola con una syscall tra user mode e kernel mode, questa era un'operazione piuttosto costosa. Questi vincoli influiscono negativamente sulle prestazioni di Wine ma in ReactOS il driver winent esegue semplicemente chiamate di sistema in modalità kernel Win32k.

Progressi nella gestione della memoria

Il lavoro nel branch Cache Controller di Art Yerkes' ha visto dei progressi importanti durante gli ultimi mesi, Art ha reimplementato e semplificato diversi componenti. Una di queste parti era il bilanciatore, che decide quali pagine devono essere scritte sul disco. Un altro componente legato è lo scrittore di pagine modificato, che Art è riuscito a far funzionare semplificando il blocco delle risorse fatto durante le operazioni di paging. Quando il gestore delle pagine le deve liberare per poter fare spazio per nuovi dati (mpw), cercherà di trovare pagine che non siano state modificate, oppure non "sporche", così che non debba realizzare operazioni di I/O sul disco per poter liberarle. Un modo per contribuire a ciò è liberare queste pagine mentre il sistema è inattivo per minimizzare il numero di pagine sporche presenti, che è proprio quello che fa mpw. Tuttavia, previamente questo non funzionava in ReactOS per via di una teoria affascinante ma molto complessa per gestire le sincronizzazioni durante le operazioni di memoria.

Originariamente il codice di gestione della memoria era relativamente semplice in ReactOS, col passare del tempo è stato introdotto più codice per gestire la sincronizzazione delle risorse e dei deadlock. Un tentativo per la gestione delle risorse è stato pageops, che rappresentava lo stato del gestore di errori mentre processava un indirizzo specifico su in un processo specifico. Art non era al corrente di nessun altro che utilizzasse pageops e il concetto potrebbe essere stato creato da David Welch, un ex guru del kernel di ReactOS. Tuttavia, l'implementazione in ReactOS aveva introdotto una grande quantità di codice duplicato nei gestori degli errori perché doveva tener traccia di cosa facevano o cosa dovevano accedere altri gestori di errori. Art ha rimosso pageops dal suo branch usando un valore sentinella per tenere lontano il codice di altri processi da aree sensibili fino alla notifica. Sebbene questo sia un modo semplicistico per gestire l'accesso condiviso, è il più diretto e più facile da mettere in funzione. In ReactOS, avere delle funzionalità ha una priorità più alta della teoria dell'ottimalità per il momento.

Un'altra modifica che ha fatto Art è legata a come il paginatore decideva quali pagine liberare e riutilizzare quando finiva la memoria. Quello che succedeva prima era che aree specifiche di memoria finivano per cannibalizzarsi a vicenda per servire le richieste. Se il sistema aveva bisogno di più spazio per pagine user per esempio, le stesse venivano liberate per servire la richiesta. Questo creava dei problemi di performance quando certe operazioni creavano paginazione costante liberando e occupando pagine che erano state appena spostate alla memoria fisica. Il paginatore nel branch di Art è molto più flessibile ed evita di trovarsi in queste situazioni.

Un altra modifica importante che ha fatto Art nel suo branch è legata al modo in cui vengono mappate le sezioni e le pagine. Le sezioni sono un'altra astrazione della memoria e sono composte di diverse pagine. Previamente, l'unico modo per determinare a quale sezione apparteneva una pagina era controllare lo spazio di indirizzi sul quale era mappata la sezione. Tuttavia, ci sono delle situazioni dove una sezione non è mappata su uno spazio di indirizzi, il che crea complicazioni quando si cerca di liberarle. Art ha trovato un modo per risolvere questo problema, identificando la sezione di cui fa parte una pagina vedendo qualche bit in una delle strutture di dati usate nella gestione della memoria.

La somma di tutti i lavori fatti ha reso il paging molto più affidabile in ReactOS, al meno nel branch di Art. Il paging è importante per gestire le situazioni dove il S.O. oppure le applicazioni usano più memoria di quella fisica presente. Precedentemente, ROS gestiva questa situazione molto scarsamente, sia a livello di performance che di integrità dei dati. Adesso Art è riuscito a far funzionare ROS in sicurezza in sistemi con 32MB. Andare più in giù sarebbe impossibile considerando le dimensioni del codice e dei dati che devono rimanere in memoria per aiutare a fare il paging, comunque non c'è proprio bisogno di provare con meno memoria, perché con risorse così limitate si potrebbe far girare solo il sistema operativo e nient'altro.

Supporto Ext2

Con il progresso ottenuto mettendo a punto il Controller della Cache, Art è riuscito anche a far fare il boot e usare una partizione ext2 a ROS. L'installatore non ha il supporto nativamente, quindi Art ha fatto il bootstrapping di ReactOS dalla partizione usando grub per caricare freeldr. Oltre al lavoro fatto da Pierre Schweitzer nella libreria di runtime di filesystem, Art ha dovuto solo fare qualche aggiunta. La cosa più semplice è stato lo stubbing di oplocks, funzionalità su cui si appoggiano i filesystem di rete. Nessun filesystem locale ne fa uso, ma Matt Wu, lo sviluppatore del driver ext2 che Art sta usando, è stato abbastanza pignolo seguendo le regole per scrivere driver di filesystem e ha fatto le chiamate per aderire alle pratiche suggerite. Questo fa del suo driver un ottimo testcase. Altre due addizioni molto più complesse sono state necessarie, compresi i blocchi di controllo della memoria e il blocco dei range. Entrambi hanno a che fare con la mappatura di blocchi di filesystem a blocchi di dischi. Servono ancora un po di modifiche di infrastruttura per poter usare il lavoro di Art e Pierre. Come abbiamo detto precedentemente, l'installatore non supporta l'uso di partizioni ext2 e il bootloader potrebbe aver bisogno di qualche ritocco. Tuttavia queste servono come trampolino di lancio, per usare filesystems più avanzati in futuro e il nuovo driver FAT in sviluppo ne trarrà vantaggio sicuramente di tutto quello che hanno fatto i due. Per ultimo, c'è da notare che la maggior parte del lavoro si trova in branch separati e non nel trunk, quindi potrebbe passare del tempo prima di vedere queste funzionalità.