ReactOS Newsletter: Newsletter 44

ReactOS Newsletter - Newsletter 44 (#44)

Sviluppo generale
Convention Linuxworld
Aggiornamento ARM
Port a 64bit

Newsletter Archive

by Z98 on 2008-08-06
translated by Gabriel ilardi on 2008-08-06

top

Sviluppo generale

C'è stato tempo fa un bug interessante che riguardava la creazione di handle. Quando si creava l'handle 4100, il sistema andava in crash. Questo si evidenziava con VLC ed è stato sistemato da Christoph von Wittich. Il problema era il risultato di un calcolo incorretto, dove del codice cercava di accedere all'indice più alto di 4099 nella prima tabella. Tali valori sono fuori portata e si suppone si trovino nella seconda e successive tabelle. Adesso, il sistema andrà in crash solo dopo la creazione dell'handle 4,186,000. Dovrebbe essere sufficiente per quasi tutto.

Aleksey Bragin ha lavorato nell'aggiungere a ReactOS un controllo di consistenza al file system. Considerando la mancanza di controlli in FAT, questa sarà un'aggiunta benvenuta. Le utility chkdsk, format, e autochk sono wrapper per DLL specifiche del filesystem come ufat.dll e untfs.dll che forniscono le attuali funzioni per formattare e controllare. Le DLL comunicano con i loro wrapper tramite fmifs.dll, la cui interfaccia è ben nota.

Oltre quelle tre utility, Aleksey ha finito anche il port di dosfsck iniziato da Steven Edwards e Mike Nordell. Questo port si trova già nel trunk e funziona, Aleksey è riuscito a far funzionare autochk e ufat.dll nella sua copia di lavoro. Apparentemente il lavoro è andato liscio quindi dovremmo vedere il loro commmit a breve.

Ultimo ma non meno importante, Timo Kreuzer ha lavorato nel correggere dei calcoli in virgola mobile nel componente kernel di Win32. Nella architettura x86, i dati nell'unità di virgola mobile non sono salvati durante lo scambio di contesto mentre si opera in kernel mode. Tuttavia, per uno strano motivo i calcoli in virgola mobile in win32k erano scritti per utilizzare la FPU. Timo ha riscritto fondamentalemnte le strutture di dati in assembler per non utilizzare la FPU ed è quasi pronto per il loro commit.

top

Convention Linuxworld

ReactOS condivide una bancarella con Haiku in Linuxworld e siamo più che lieti di condividere lo spazio con loro. Sfortunatamente, Art Yerkes è l'unico sviluppatore riuscito ad andarci perché era più vicino e ha avuto avuto il tempo. Quindi cercate di farci un salto e fargli compagnia!

top

Aggiornamento ARM

Il team di ARM ha fatto parecchio dall'ultima volta che l'ho menzionato e dato che sono l'unico che riempie il loro changelog, ho una idea molto chiara di cosa sono riusciti a fare. Hanno aggiunto una quantità considerevole di codice per preparare ReactOS per fare il boot in ARM e hanno risolto qualche problema nel processo. Il loro lavoro nel gestore di memoria è specialmente apprezzato perché è una delle parti più deboli nel codice di ReactOS. Assieme a tutti i fix che hanno fatto ci stanno facendo fare una brutta figura.

I passi che il team ARM ha fatto sono, prima assicurarsi che il codice compilasse in ARM. Dopo c'era il fatto di fare il boot, il che ha richiesto delle modifiche in Freeloader per capire ed essere eseguito nel processore e piattaforma ARM. Una volta che il kernel è stato trovato, hanno avuto bisogno di avere l'output di debug dalla porta seriale per poter vedere dove c'erano ancora problemi. A quel punto, non potevano andare molto lontano senza. Dopo qualche hack, il team ARM ha lavorato per implementare correttamente l'output di debug, non senza qualche lamentela nel percorso.

Per girare, il sistema operativo ha bisogno di gestire le sue risorse, compresi tempo del processore e la memoria. Fondamentalmente tutto il codice che gestiva le interruzioni e il timing è dovuto essere riscritto per ARM così che il SO potesse dire quando succedevano le cose o quando si supponeva dovesse fare qualcosa. Mentre per il gestore di memoria, bene, hanno fatto emergere dei bug uno dopo l'altro e non erano molto contenti al riguardo. Ma visto che li hanno sistemati, li perdoniamo.

Attualmente, il team ARM sta lavorando nel riuscire ad utilizzare la periferica di boot, in parole povere il ramdisk. Oltre a scrivere un nuovo driver per il ramdisk e risolvere qualche problema nel driver FAT e CDFS, stanno tornando dal gestore di memoria per sistemare o implementare delle funzionalità di cui hanno bisogno per far girare il disco. Ci sono stati dei reclami da allora, il che probabilmente significa che stanno facendo dei passi avanti semplificando e correggendo il codice.

Il prossimo passo, del quale hanno già fatto qualche lavoro preliminare, è riuscire ad avere su e funzionanti i sistemi dello user mode. Gli faccio un imbocca al lupo e aspetterò con ansia il lavoro futuro. Anche se significherà impiegare qualche ora nel rivedere i loro commit per aggiungerli al changelog.

top

Port a 64bit

Non fatevi troppe aspettative, perché ci sono un po' di ostacoli che dobbiamo affrontare prima che ci sia qualche progresso visibile. Timo Kreuzer sta lavorando davanti ad un ambiente di sviluppo per 64bit da un po' di tempo e ha dato sia a Samuel Serapion (in teoria l'altro scrittore delle newsletter) sia a me una copia. Sam ha iniziato il lavoro di riuscire a compilare il sistema e per adesso il kernel, freeldr, CRT, qualche driver, qualche applicazione in user mode, e tutti gli header di cui dipendono si possono compilare. La compilazione di Win32k si ferma a metà, quindi c'è ancora strada da fare. Attualmente, freeldr carica il kernel, ma fallisce poco dopo l'inizializzazione. Ci vuole del codice che non c'è proprio e non abbiamo ancora modificato il gestore di memoria per funzionare a lungo. Questo sarà definitivamente un viaggio lungo ed arduo viaggio.

top