Re: Debian e firmware proprietario
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alessandro Pellizzari ha scritto lo scorso 11/01/2009 11:17:
> Il giorno dom, 11/01/2009 alle 09.46 +0100, Davide Prina ha scritto:
>
>> se così fosse, allora con un solo driver si potrebbero gestire i
>> firmware di tutti gli hardware tra loro "simili" (per esempio le
>> webcam). Inoltre conoscendo come colloquiare con un firmware, allora si
>> potrebbe colloquiare con qualunque altro "simile" ... ma ciò non è
>> affatto vero, basta vedere l'esempio delle schede video (tra ATI e
>> Nvidia ad esempio) o delle webcam ...
>>
>> In realtà ogni firmware ha un'interfaccia diversa ed è il driver che si
>> occupa di creare un'interfaccia comune per i programmi che usano quel
>> dato tipo di hardware, in modo che anche cambiando l'hardware e quindi
>> anche il driver si avrà che il programma continua a funzionare
>> correttamente.
>
> Sono vere entrambe le cose.
>
> Riprendo il tuo esempio delle ATI. C'e` un firmware (OpenBIOS) su ogni
> scheda ATI degli ultimi anni che permette a un driver
> (xserver-xorg-video-ati e ...-radeonhd) di supportare tutte le schede
> ATI dalla X300 alla HD4870X2. Questo perche` il firmware espone al
> driver una serie di API (o meglio, di registri) comuni, ma poi imposta i
> "veri" registri delle schede in modo diverso.
>
> L'hardware e` molto diverso tra scheda e scheda, ma il driver (almeno in
> 2D) non "vede" differenze. Per il 3D non c'e` ancora questo firmware,
> perche` le caratteristiche variano troppo velocemente per fare una API
> stabile.
>
Ancora piu' complesso: il problema delle radeonhd non e' legato alla
licenza del firmware - ATI ha dichiarato e dimostrato piu' volte di
voler aprire specifiche e codice firmware - quanto ai moduli IP
utilizzati nelle nuove GPU.
E qui ritorniamo al problema ciclico: dove finisce il firmware e dove
inizia l'hardware? Anche senza arrivare ai compilatori di silicio e alle
logiche FPGA che implementano un core IP proprietario, anche un
alimentatore che usa un microcontrollore implementa via software
funzioni fino a pochi anni fa realizzate mediante circuiti analogici.
Quando io progetto un dispositivo del genere, posso anche rilasciare il
codice C con una licenza "libera", ma dal punto di vista funzionale
equivale a rilasciare l'hardware con una licenza libera.
Sebbene esista qualche esempio in questo senso (vedi baloon), a mio
parere non ha molto senso `fissarsi` sulla licenza del firmware, almeno
non piu' di quanto si sia disposti a fare per la licenza dell'hardware
su cui gira tutto il sistema.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQEcBAEBAgAGBQJJa4APAAoJECVi+PFMdzdC0mkIAJm0qGXLJmlwDOuCCQ/CRpnu
BNajZev35WA7VWqp7ixlXO10+eLexGadcAXtMtMtwxMULOKs0scX+3U7jXEsz9mn
k/Tj3GVF7Ji6Q8SX1SsV6cxMWsuaAUTKR/FLX2e9qBdW2yd2z4VLUngv2t8hb0lJ
wbW6qTbv1DvL+tr4SPjauatTvCK7P/yiTQNJX9dG6ViXFUVwsRLp7IuFgaPXm+Pj
wZbnKKNLNAKnXpr9rygnlFQHruDNisQG5afpBoPz+zuA85Aq6Sr9PcMnKsoB44co
+QO6l4f6V5JSoE1dTCHXEVq9xK1O2y496VXG7kJo5vtRfE3xUCa+w18bojm6pTo=
=T+fu
-----END PGP SIGNATURE-----
Reply to: