Newsgroup: it.comp.os.linux.development
Titolo: un filtro per i driver

Vorrei avere una conferma dagli sviluppatori Linux italiani a
proposito di una idea che da lungo tempo mi ronza in testa...
Sarebbe possibile creare un modulo per il kernel, una sorta di
estensione, per poter sfruttare i device drivers realizzati per altri
sistemi operativi?
In fin dei conti, per il poco che so, un driver non fa altro che
generare degli interrupts: si potrebbe realizzare un ambiente di
emulazione per, ad esempio, Windows, che "convinca" il driver di
lavorare su quella tal piattaforma per generare la sequenza di
interrupts, e farlo comunicare con il kernel vero (quello Linux)
attraverso un "filtro" che interpreti gli interrupts del driver e gli
ritorni le risposte del dispositivo hardware...
Si puo' fare? E' opinabile una cosa del genere? O e' impossibile?
Perche'?
Grazie :-)

 Grazie :-)
Prego
matic

 Perche'?
I dettagli non li conosco, ma so che c'e' un modulo ndiswrapper che fa
proprio questo, anche se e' limitato ai soli driver network, NDIS appunto.
I dettagli qui:
http://ndiswrapper.sourceforge.net/
HTH
-- 
Mario "Reliant" Pascucci
http://ilpettegolo.altervista.org/

 
Tanto quanto questo -> 
http://www.jankratochvil.net/project/captive/
 ,
il noto driver per partizioni NTFS ottenuto con un miscuglio di Wine,
ReactOS e il driver ufficiale per Windows...
Quel che mi chiedevo era se e' possibile creare un wrapper
"universale", che possa andar bene un po' per tutto. Indubbiamente
comunque c'e' da conoscere per bene la struttura interna tanto di
Linux quanto del sistema operativo cui si vogliono "rubare" i
drivers...
L'idea iniziale era quella di sfruttare i controller per Darwin,
kernel piuttosto supportato (essendo alla base di MacOS X) e pur
sempre Unix-like, dunque forse un po' meno diverso da quello Linux che
non il core di Windows.

 sistemi operativi?
E` tecnicamente possibile, e viene gia` fatto. Ci sono pero` 2 grossi
problemi. Il primo e` tecnico: se ci sono problemi (ie. crash) ti
attacchi al tram. Il driver e` binario e quindi gli sviluppatori non
possono sapere cosa sta facendo ed il produttore quasi sicuramente non
fornira` supporto per una tale configurazione[1]. L'altro e` piu`
ideologico; se esiste un wrapper (magari anche non perfettamente
funzionante) il produttore dell'hardware e` meno motivato a scriverne
una versione per linux e puo` liquidare eventuali pressioni con un
"usate il wrapper".
Luca
[1] Anche un driver closed-source ma per linux e` meglio: in questo caso
il produttore dovrebbe fornire assistenza.
-- 
Home: 
http://kronoz.cjb.net
Non ho ancora capito se il mio cane e` maschio o femmina:
quando fa la pipi` si chiude in bagno


A questo avevo pensato anche io: succede un po' la stessa cosa con i
videogiochi e Wine (e/o WineX), ma credo che in ogni caso un wrapper sia
meno efficiente di un driver nativo e dunque non sia molto gratificante ne'
per l'utente che si trova con la periferica si funzionante ma rallentata ne'
per il produttore che si vede calare la quota di mercato in quanto il suo
dispositivo risulta meno performante di un altro che dispone di un
controller ad hoc.
Diciamo che questo dovrebbe essere un compromesso, onde evitare le solite
lamentele (tipiche degli utonti desktop) sul fatto che manca il driver di
questo o quello e allo stesso tempo per favorire coloro che rilasciano
driver nativi...
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 un controller ad hoc.
Mah, non so. Se l'utente cerca un periferica affidabile dovrebbe cercare
qualcosa di supportato nativamente (io lo faccio dove possibile). Una
periferica che non ha driver per linux oggi di certo non ha una grossa
quota nel mercato linux ;)
Luca
-- 
Home: 
http://kronoz.cjb.net
"New processes are created by other processes, just like new
 humans. New humans are created by other humans, of course,
 not by processes." -- Unix System Administration Handbook

 non il core di Windows.
Se ne e' parlato da qualche parte, anche se non ricordo dove
francamente. Visto il design di IOKit (scritto tra l'altro in un subset
di c++) bisognerebbe prima wrappare i vari layer che lo compongono e poi
concentrarsi sul driver specifico. Non mi pare una strada percorribile.
ciao
Alessandro


Variazione sul tema: un wrapper Linux per Linux?
Spesso e volentieri un driver non funziona se usato su una versione del
kernel che non e' la stessa per la quale e' stato compilato: non sarebbe
possibile creare un "adattatore" che possa rappresentare quel piccolo strato
tra il driver per XYZ e il kernel XYZ.2 ?
Rimanendo sempre nell'ottica dei produttori hardware: credo che questo
potrebbe essere un incentivo al rilascio di drivers perlomeno in formato
binario, compilati ad esempio per la serie 2.6 ma utilizzabili, grazie al
"filtro", su ogni 2.6.X, senza dover impazzire nel rilasciare un binario
nuovo in occasione di ogni sottoversione o senza correre il rischio di
lasciare qualcuno sprovvisto del binario giusto...


 lasciare qualcuno sprovvisto del binario giusto...
Non sarebbe fattibile, non si puo` mai sapere cosa tocca il driver
binario. Per farti un esempio, il driver NVidia metteva le mani
direttamente nella gestione della VM (si presume per l'allocatore DRI) e
tendeva a tirare giu` il kernel un volta si` e l'altra pure.
I driver complessi come quelli delle schede video cercano di essere
self-contained (quelli ATI si portano dietro i propri driver GART) per
evitare problemi. Di solito le incompatibilita` nascono proprio per 
cambiamenti alla VM. Per questi driver, pero`, ATI ed NVidia sembrano
abbastanza attenti allo sviluppo del kernel; inoltre dietro alla scelta
"closed source" ci sono delle ragioni valide.
Per driver in cui un wrapper potrebbe sopperire alla mancanza di un
driver nativo di solito la mancanza del driver stesso e` da imputare al
disinteresse del produttore. Non penso ci siano IPs rilevanti nel driver
di una scheda di rete... Non vuoi spendere risorse per scrivere un
driver? Allora rilascia almeno le specifiche e qualche gruppo di
programmatori creera` il driver gratis...
In ogni caso l'ABI non viene sconvolta per divertimento, viene fatto
quando ci sono delle valide ragioni tecniche.
Luca
[1] Quelli opensource, ovviamente, possono essere tranquillamente
adattati.
-- 
Home: 
http://kronoz.cjb.net
Recursion n.:
	See Recursion.


Ho letto qualcosa a tal proposito in questo (
http://www.linuxdevcenter.com/pub/a/linux/2004/09/02/driver_ease.html
 )
articolo. L'idea comunque non sarebbe quella di interferire con lo sviluppo
del kernel vero e proprio (non sia mai :-) !), ma creare un modulo *esterno*
che possa, diciamo cosi', "emulare" un pezzo di kernel (Linux, Windows,
Vattelapesca...) e pilotare le risposte del driver e del core.
Da quanto mi dici capisco che il driver sia qualcosa di piu' di "un
generatore di interrupts", ma vada a lavorare proprio in stretto contatto
con il cuore del sistema e dunque sia difficilmente incastrabile all'interno
di una struttura non propria.
Eppure, dal basso della mia ignoranza, essendo piuttosto testardo, non ci
credo finche' non ci metto il naso ( :-) ): sai forse dove posso trovare un
po' di documentazione a proposito del funzionamento di driver
particolarmente complessi? Oppure, nel caso specifico, potresti segnalarmi
ove reperire i codici di driver e le specifiche di qualche periferica
particolare (come le gia' citate schede video), tanto per farmi una idea del
piano su cui lavorano?


 piano su cui lavorano?
/usr/src/linux/drivers ;) Esistono le specifiche delle radeon 7000, ma
l'ATI le fornisce solo su richiesta e non a tutti. I driver sono
comunque open source e disponibili nella tarball del kernel
(drivers/char/drm, i client sono nei sorgenti di X oppure sul sito DRI).
Le matrox dovrebbero avere specifiche pubbliche.
Per le schede recenti non c'e` nulla[1]. Comunque da un'occhiata su
dri.sf.net
.
Luca
[1] Solo un "pazzo" che sta cercando di reversare il funzionamento delle
R300 :)
-- 
Home: 
http://kronoz.cjb.net
La vasca da bagno fu inventata nel 1850, il telefono nel 1875.
Se fossi vissuto nel 1850, avrei potuto restare in vasca per 25 anni
senza sentir squillare il telefono