Sistemi Dell con Linux preinstallato: parliamone

Salve a tutti,
prima si parlava di driver open source per le schede Wireless Intel.

Magari ho frainteso io, però le cose non stanno proprio così: è vero che il driver è open, ma il firmware della periferica no. E, guardacaso, il driver open è piuttosto piccolo, mentre il firmware è decisamente più corposo... ho la sensazione che il vero driver risieda nel firmware, mentre il driver open sia solo un'interfaccia verso di esso.

Sebbene anche io preferisca sicuramente che i driver siano open, non vedo quale sia l'enorme problema per linux: semplicemente non li si inserisce nella distribuzione e si lascia la briga all'utente di scaricali e installarli. Sapendo, ovviamente, che quel driver viola la liceza del kernel stesso e che quindi, in caso di problemi, il responsabile non sarà certo linux, ma il driver.

Rispondendo a ilsensine, personalmente credo che le case produttrici di chip grafici non vogliano rilasciare il codice dei driver perchè nei driver stessi potrebbero esserci avanzate routine di compressione delle texutre, di ottimizzazione dei triangoli, di rimozione delle superfici nascoste, di sfruttamente delle estensioni SIMD, ecc.. Insomma, immagino che non tutte le feature sbandierate dai produttori siano realmente al 100% integrate nell'hardare, ma magari qualcosa è implementato anche lato software (nel driver). Se le cose stanno davvero così e decidessero comunque di rilasciare i driver open, stai pur certo che brevetterebbero tutto il brevettabile. E una situazione del genere (software open ma brevettato) mi piacerebbe ancora meno che avere il driver closed.

Comunque, lo ribadisco, personalmente preferirei di gran lunga driver open!

Discorso micro/mono kernel: la possibilità che un driver scritto male crashi un sistema monolitico è reale, ma in passato i microkernel avevano seri problemi di performance. Sono stati risolti?

Sono due righe che ho scritto così di "getto", magari ho detto delle inesattezze... nel caso perdonatemi!

Ciao.

Mi autoquoto... così magari potete confermare / smentire quello che ho scritto!

Magari ho frainteso io, però le cose non stanno proprio così: è vero che il driver è open, ma il firmware della periferica no.

E, guardacaso, il driver open è piuttosto piccolo, mentre il firmware è decisamente più corposo...

Rispondendo a ilsensine, personalmente credo che le case produttrici di chip grafici non vogliano rilasciare il codice dei driver perchè nei driver stessi potrebbero esserci avanzate routine di compressione delle texutre

di ottimizzazione dei triangoli, di rimozione delle superfici nascoste, di sfruttamente delle estensioni SIMD, ecc..

Insomma, immagino che non tutte le feature sbandierate dai produttori siano realmente al 100% integrate nell'hardare

When I am forced to sign NDAs to get hardware specs, the hardware IP "revealed" is inevitably something that some other company has done before, and done better. NDAs and closed specs are IMO only used by vendors to save face, when their hardware design is stupid, and their errata innumerable.

Avevo perso il tuo post...

Esatto, e con ciò? L'uso di firmware è comunissimo. Il firmware risiede anche negli hard disk, nei lettori cd-rom, nei dispositivi USB, ecc.
La differenza è che il firmware (anche se "iniettato" dal driver) fa parte integrante del dispositivo che ti viene venduto, non viene eseguito sul tuo computer. E' estremamente comodo per chi fa l'hardware, in quanto molto più flessibile di soluzioni "hardcoded" in hardware o in ROM.
Visto che il firmware collabora con l'hardware per creare il dispositivo completo (nota: "creare", non "utilizzare"!) posso essere d'accordo che rilasciare il firmware vuol dire divulgare dettagli importanti sul dispositivo.

Vuole semplicemente dire che il firmware è fatto bene, e mostra al driver una interfaccia di controllo pulita e semplice da usare.
nb un driver in kernel space ___deve___ essere piccolo. Se è "grande", c'è qualcosa che non va

S3TC. Ne abbiamo già una implementazione libera grazie.

Non vogliamo sapere come le hanno realizzate nei loro driver, vogliamo solo conoscere abbastanza dettagli sull'hardware per implementarle ex novo.

Ma _sicuramente_ non lo sono, e non c'è nulla di male a dirlo.
A meno che non c'è qualcos'altro da tenere "segreto", e qui quoto Jeff Garzik -- uno che di driver ne ha fatti parecchi:

Pensavo che questo fosse valido solo per le periferiche con firmware non eccessivamente corposi... quindi anche il firmware della scheda di rete wireless intel non viene eseguito sul processore della macchina host ma direttamente sul chip del dispositivo? Mmm, non so... ho "paura" che nel file del "firmware" in realtò risieda un bel pezzo di software che viene eseguito sulla macchina (a mo' di quello che si faceva con i Winmodem). E' solo un'impressione però, tu sicuramente sei molto più informato di me...

Non mi riferivo solo al "semplice" S3TC. Ad esempio, da parecchi anni le schede ATI (o, meglio, i driver ATI) analizzano le texture per capire se è possibile applicare il brilineare invece del trilineare puro senza un impatto visivo notabile...

Sono di nuovo d'accordo con te, ma immagino che sia proprio questo che le case come ATI e NVIDIA non vogliano mollare: la possibilità, anche remota, di capire appieno come funziona l'accoppiata hardware/software, forse temendo che qualche concorrente ne tragga spunto per migliorare il suo prodotto.

Non sta a noi dire quanto deve essere "grande" il firmware Intel. Evidentemente hanno preferito puntare molto più sul firmware e semplificare molto l'hardware.
Riguardo i winmodem, come funzionavano i modem _veri_? O con un hw molto complesso per fare le modulazioni, o con un firmware apposito, o con una combinazione dei due. Il discorso è lo stesso.
Anzi, visto che i winmodem non sono altro che scadenti schede audio, è incredibile come vengano tenute segrete le quattro fesserie che possono fare. Alcuni lo hanno capito, e oggi abbiamo i driver ALSA liberi per i winmodem Intel e VIA. La logica di modulazione viene effettuata in userspace da un demone proprietario; purtroppo non ne sono mai stati fatti di liberi per la modulazione V90.

Ok quindi è una pura ottimizzazione software nei loro driver. Non serve questa informazione per realizzare il driver.

...e la r200? Ho già raccontato la sua storia, devo ripeterla?

Si, è vero, ma nei Winmodem il "modem emulato" girava appunto sul processore host. A questo punto, che differenza fa se a girare è un driver o un firmware?

Ah, quindi basterebbe pubblicare anche un driver, diciamo, "castrato".

Ehm, veramente questa me la sono persa... ti dispiacerebbe farmi un piccolo sunto e/o indirizzarmi a qualche link sull'argomento?

Comunque, se non ricordo male, le specifiche di R200 furono rilasciate ben dop o che R300 (un chip completamente diverso) fece il suo debutto...

Il driver è un programma che gira sul tuo processore e nel tuo sistema operativo linux; il firmware gira sul dsp del dispositivo che è un mondo a parte.
In termini pratici, puoi prendere l'hardware (compreso il suo firmware) e portarlo dalla tua linux box x86 su uno scatolotto con processore ARM, e farlo funzionare ugualmente. Non puoi invece riciclare un driver closed source. Inoltre, un driver closed source non di rado ti pone vincoli sulla versione del kernel, la sua configurazione, ecc. Insomma, ti impedisce di esercitare la libertà che un sistema operativo libero di dovrebbe garantire.

Sei fissato con questa storia di "pubblicare il driver"
NON VOGLIAMO che pubblichino una sola riga di codice, ci basta sapere come creare un driver da zero.

Non c'erano specifiche per l'r200. Poi "qualcosa" (una compagnia che era disposta a PAGARE per avere driver liberi) "convinse" ATI a divulgare delle specifiche. Di fronte ai $$$, tutte le fesserie sulla IP andarono a farsi benedire. Ah e ovviamente nvidia non trasse nessun vantaggio dal driver r200 libero.


Non so quando è stato rilasciato l'r300; la notizia ufficiale che era finalmente possibile realizzare il driver libero per l'r200 è stata data l'8/6/2002.
E comunque ad oggi la ATI non ha rilasciato nulla sull'r300, con tutto che ormai è hw obsoleto e stanno tirando fuori schede DX10 (il driver esistente è frutto di reverse engeenering). Cosa stanno difendendo _oggi_ sull'r300?

Ecco, è proprio il fatto che il firmware di intel giri sul DSP non mi convince molto. Sicuro che non giri sul processore host, dialogando poi con il chip wireless?

C'è qualche modo di verificarlo?

ho preso l'esempio dei Winmodem perchè accadeva un po' proprio questo: un driver girava sul processore host e, a computazione finita, dialogava con il DSP di turno (il chip audio).

Per curiosità, sai dirmi dove reperire le specifiche di R200? Grazie!

Si, è vero, ma nei Winmodem il "modem emulato" girava appunto sul processore host. A questo punto, che differenza fa se a girare è un driver o un firmware? Forse che il firmware gira in userspace e il driver in kernel space (chiedo per capire meglio, non sono polemico eh!)?

Sì, sicuro.

Non è un programma per linux

In quel caso c'è un driver proprietario in kernel space, o un demone proprietario in user space. Un programma per linux, insomma.


Le ha la Tungsten Graphics, sotto NDA, quindi non può divulgarle a terzi.