Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 56

Newsletter 56

by Z98 on 2009-04-09
translated by Gabriel ilardi on 2009-04-10

USB

Il supporto USB ha una storia strana in ReactOS. Lo sforzo originale comportava il porting dello stack USB Cromwell di Linux, Aleksey Bragin aveva speso un po' di tempo cercando di farlo funzionare. Alla fine è stato abbandonato per adottare un altro progetto, uno stack USB sviluppato per NT4 da un programmatore in Cina. Questo però era incompleto e aveva diversi bug, e l'autore non lo supportava più quindi Aleksey aveva cercato di sistemarlo in una certa misura. Si era allacciato un driver per mouse USB con degli hack ma non funzionava in modo affidabile, come possono attestare diverse persone che hanno cercato di usarne uno in ROS. Recentemente Aleksey è tornato sul codice per aggiungere un driver per tastiera USB e pensava di applicare lo stesso hack che aveva usato per il driver del mouse USB per farlo funzionare in qualche modo. Tuttavia, è voluto andare un po' oltre e ha cercato di controllare i LED della tastiera, cosa che coinvolge metodi di comunicazione leggermente diversi dai colpi di tasti o movimenti del mouse. Aleksey ha scoperto che il driver USB analizzava il descrittore della configurazione fornito dalla periferica in modo sbagliato e dopo essersi consultato con un membro del team di Haiku che lavora sullo sviluppo USB ha risolto il problema. Questo ha reso possibile la rimozione dell'hack inserito previamente per il driver del mouse. I driver USB si appoggiano sui driver normali di tastiera e mouse, e questo significa che questi devono essere caricati prima dei driver USB. Il supporto per le periferiche USB nei driver normali era stato implementato da Hervé Poussineau. Aleksey ha semplicemente messo insieme i pezzi del puzzle per avere un sistema quasi funzionante.

Nonostante ReactOS abbia adesso un driver per tastiera e mouse USB, è da sottolineare che gli stessi sono stati disegnati per lo stack USB attuale. L'USB in NT5 ha due stack uno Pnp e l'altro HID che sono completamente diversi da quanto abbiamo in ReactOS. Prima di poter considerare l'implementazione di driver USB che seguano il design NT5+, ci serve uno stack USB che lo segua. Questo sarebbe per avere la compatibilità con driver terzi, poiché è possibile fornire la funzionalità di base che ci si aspetta dall'USB usando lo stack attuale in ReactOS.

Networking

Art Yerkes e Cameron Gutman hanno lavorato un bel po' per cercare di migliorare lo stack di rete implementando funzionalità mancanti. C'era una questione con siti SSL che non funzionavano per un problema di corruzione di memoria. Un vettore di indirizzi IP viene gestito e usato da due funzioni, AfdGetPeerName e AfdGetSockName. Art crede che i siti che ne fanno uso dell'SSL potrebbero chiamare qualsiasi delle due funzioni diverse volte per verificare i certificati, cosa che aveva esposto il bug. Con il problema risolto, adesso è possibile usare la pagina di login di gmail così come applicazioni come Thunderbird che si appoggiano sull'SSL per la sicurezza.

Art e Cameron affrontano diverse sfide mentre lavorano sul codice di rete rispetto agli altri. Il problema è che l'interfaccia di rete, è per tanti versi sovradimensionata, con varie strutture che hanno nomi simili ma hanno membri leggermente diversi. Il caso specifico sarebbero le strutture TDI_ADDRESS_INFO, TDI_ADDRESS_INFORMATION, e TRANSPORT_ADDRESS. Il presupposto alla base di tutto ciò era che un protocollo potrebbe restituire diversi indirizzi ad una richiesta, cosa che non è la norma in un sistema di rete. Poiché tutte queste fanno parte dell'interfaccia definita, non le possono cambiare e devono rivedere il codice per assicurarsi che venga usata la struttura di dati adeguata e il membro corretto di detta struttura. La cosa che è più incasinata ancora è che a volte le differenze tra le strutture di dati non importa, il che significa che potrebbe funzionare in una situazione e in un'altra no. Indipendentemente da ciò, il loro lavoro si è ridotto.

Infrastruttura di testing

Christoph von Wittich aveva fatto funzionare i test wine automatizzati tempo fa e Alwyn Tan, un membro della community aveva creato una GUI temporanea per vedere e confrontare i risultati tra le revisioni. Colin Finck ha lavorato su una soluzione più permanente che ha anche più caratteristiche. La nuova interfaccia web permette la comparazione tra 5 build diverse o solo vedere i risultati che sono cambiati. Inoltre, il buildbot usato per compilare ed eseguire i test è stato aggiornato. Il programma rosautotest è stato scritto da Colin per poter essere riavviato nel caso in cui ReactOS andasse in crash. In aggiunta agli sforzi di Stefan Ginsberg per scavalcare i test che si sa mandano ReactOS in crash, adesso possiamo essere certi che ROS andrà avanti lungo tutta la suite di test anziché fermarsi dopo un crash. Per quelli di voi che volete giocare col test manager, si trova attualmente nel server di test su questo indirizzo.