Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 71

Newsletter 71

by Z98 on 2010-04-22
translated by Gabriel ilardi on 2010-05-07

Stack USB NT

L'architettura USB previa a Vista era iniziata con un driver di livello molto basso (usbport). Questo driver era quello che creava oggetti di periferica per ogni controller USB e riceveva gli I/O Request Packets (IRP). A seconda dal tipo di standard del controller USB, usbport chiamava uno dei tre driver di aiuto, usbehci, usbohci, e usbuhci. Quello che in realtà mandava quegli IRPs era usbhub, questi componenti costituiscono i livelli più bassi dello stack USB. La maggior parte dei driver USB distribuiti dalle compagnie si appoggiano sopra questi e traggono vantangio di una libreria di supporto chiamata usbd. Senza i livelli più bassi, i driver USB clienti non funzioneranno, ed è questo che intendono gli sviluppatori quando dicono che i driver attuali USB hanno qualche hack.

Michael Martin ha lavorato per implementare questi componenti di livello più basso. Al momento ha scritto un driver di base usbehci e fa il testing in XP sostituendolo all'originale. Michael sta riutilizzando qualche codice dei pvdrivers che fanno parte di Xen, anche se c'è un limite per la quantità di codice utile per componenti di livello così basso. Praticamente nessuno ha bisogno di implementare qualcosa di simile quindi la maggior parte del lavoro deve essere fatto da capo. Al momento Michael ha avuto qualche successo riuscendo a fare interagire il gestore PnP di XP con il suo driver, ma siccome il driver usbehci è solo un singolo pezzo dello stack, ci vorrà più tempo per avere uno stack più completo.

Tools di Build

Quando fa il build degli oggetti, il compilatore GCC aggiunge un trattino in basso all'inizio della firma delle funzioni, e il linker se lo aspetta. Questo però impedisce il linking con oggetti generati con il compilatore C/C++ di Microsoft, cosa che Timo Kreuzer ha voluto sistemare per il suo ramo x64. C'è un flag di configurazione, -fno-leading-underscore, che non glielo fa fare a GCC, ma deve essere passato anche al linker e tutte le librerie usate devono essere compilate con questo flag. ReactOS fa uso di diverse librerie precompilate C++ nel motore di build e loro non erano originariamente compilate con questo flag. Per risolvere completamente la questione, visto che binutils e GCC stesso non si comportavano correttamente neanche con il flag inoltrato, ci sono volute ulteriori patch per questi tools. Kai Tietz del progetto MinGW-w64 ha aiutato a risolvere il problema, di modo che Timo Kreuzer ha potuto rimuovere gli hack che aveva inserito per compensarlo.

Oltre a lavorare nella riorganizzazione degli header, Amine Khaldi ha lavorato diligentemente con Clang e LLVM per compilare ReactOS. Ci sono al momento una serie di bug in Clang che ne impediscono la compilazione, questo rapporto qui funziona come una raccoglitore per i bug che Amine ha trovato fin'ora. Al momento sono stati risolti due e Amine è rimasto in contatto continuo con gli sviluppatori di Clang riguardo alle altre questioni. Comunque sia, è bene avere più opzioni per compilare ReactOS quindi è sempre una buona cosa. C'è stata anche qualche discussione nelle mailing list di Clang/LLVM riguardo l'aggiunta di supporto per structured exception handling, cosa che sarebbe molto utile per ReactOS a lungo termine, perché il compilatore Microsoft è uno dei pochi che implementa SEH. Senza supporto SEH di alcun tipo, usare Clang e LLVM per compilare ReactOS sarà impossibile. Portare la libreria SEH scritta da KJK::Hyperion sarebbe anche un'opzione, anche se il porting sarebbe più o meno una riscrittura perché il meccanismo per raggiungere SEH sarebbe diverso con Clang e LLVM.