Développeur : LLVM 2.2 : Un concurrent pour GCC ?
Posté par patrick_g (page perso, ). Modéré le 18 février 2008.
LLVM n'est pourtant pas tout à fait comparable au compilateur GCC. En effet GCC est un projet complet et monolithique car Richard Stallman a choisi explicitement de ne pas le rendre modulaire afin de ne pas permettre a des programmes propriétaires de s'interfacer avec lui.
LLVM au contraire est placé sous licence BSD et a choisi une conception très modulaire afin d'être réutilisé au maximum par tous. Il se limite à des fonctions d'optimisation et de génération de binaire ; il ne peut analyser lui-même le code source des programmes à compiler (c'est le projet Clang qui est prévu pour ça).
Il sera intéressant de voir ce qui va se passer sur le long terme dans l'écosystème du libre et si LLVM va être capable d'attirer des développeurs utilisant actuellement GCC.
![[en]](../images/en.png)
Les nouveautés de LLVM 2.2 (631 hits)-
Tutoriels pour LLVM (529 hits)
-
Clang (356 hits)
> Lire la dépêche (173 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #906610.
Run by 
Cette page a été générée par Templeet en 0.0996s (dont 0.0085 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re:
> LLVM au contraire est placé sous licence BSD et a choisi une conception très modulaire afin d'être réutilisé au maximum par tous.
> De plus la licence GPL de GCC garantit aux divers contributeurs que leur code ne pourra pas être "propriétarisé" par un concurrent. Cela explique que nombre de firmes (IBM, Red Hat ou Novell pour n'en citer que quelques unes) financent largement le développement de GCC.
Tu ne crois pas que tu fais une contradiction ?
En passant, Linux est modulaire mais est très strict. La modularité de Linux en outrepassant la licence GPL est quasi uniquement pour les drivers. Il n'y a pas et n'aura pas de système de fichier proprio distribué avec Linux par exemple. Idem pour la VM, la pile tcp/ip, etc.
Donc gcc pourrait très bien être modulaire sans que son objectif de rester libre soit remis en cause. Il ne faut pas mélanger ces deux questions.
Globalement, ça commence à me chauffer les oreilles ces critiques ou remises en cause de gcc. Gcc est libre, s'il y a des problèmes techniques (et non politique, gcc doit rester libre et non être un truc proprio-friendly) il y aura un fork. Il y a déjà eu un fork de gcc ! C'était egcs (repris par quasiment toutes les distributions Linux).
S'il y a un vrai problème avec gcc, il y aura fork (comme c'est arrivé avec egcs). Pour l'instant il n'y a pas le début d'un ambrillon d'amorce de fork. Donc gcc n'est pas remise en cause. Qu'il y ait des concurrents à gcc, ne remet pas en cause gcc. Gnome a des concurrents (KDE, XFCE), ça ne remet pas en cause Gnome. Linux a des concurrents (*BSD, OpenSolaris), ça ne remet pas en cause Linux. Le libre n'interdit pas la diversité, fort heureusement. Le libre ce n'est pas dicter un produit pour tout le monde.
Enfin, c'est une petite erreur de mettre en concurrent "open source" et logicie libre. La GPL garantit que c'est et ça reste du logiciel libre. Une licence open source ne c'est pas le cas.
Enfin quel remise en cause ? Le but de gcc en prenant la licence GPL, n'est pas être le compilateur le plus populaire de la planète. Le but est d'être libre ET totalement libre (avoir un compilateur sans dépendre d'éléments proprio). Gcc est libre (comme depuis des années), donc gcc (sous GPL) a rempli cet object.
Que gcc soit aujourd'hui populaire est un "effet de bord".
Si gcc devient moins populaire par l'arrivée de solution plus proprio-friendly (open source mais pas free software), ça ne remet aucunement en cause gcc. Ce qui pourrait remettre en cause gcc, c'est l'arrivé d'un compilateur logiciel libre (sous GPL typiquement) et qui devient plus populaire que gcc (comme c'est arrivé avec egcs (que ça soit un fork de gcc ou non ne change rien).
Souvent les gens pensent que la BSD va amener des contributions des boites commerciales. Le choix de la BSD est souvent fait pour ça. Mais en moyenne ce n'est pas ce qu'on voit. On voyait ça il y a de nombreuses années, ce n'est plus le cas aujourd'hui.
Contrairement aux idées reçues (je ne dis pas ça pour patrick_g) la GPL est souvent appréciée par les boites commerciales. Elle est détestée par les boites qui veulent faire du proprio (MS déteste la GPL et aime la BSD). Une boite commerciale n'est pas toujours une boite qui veut faire du proprio. On peut se réjouir de constater que c'est de moins en moins le cas. On peut se réjouir de voir que logiciel libre n'est pas l'ennemi des boites commerciales.
Avec gcc (via la licence GPL) on a la garantit que gcc restera libre. Ce n'est pas le cas de llvm. Même si llvm devient meilleur que gcc, je resterai sous gcc.
[^]Re: Re:
Avec gcc (via la licence GPL) on a la garantit que gcc restera libre. Ce n'est pas le cas de llvm. Même si llvm devient meilleur que gcc, je resterai sous gcc.
Et alors qu'est ce qui t'empeche de faire un fork de llvm en gpl ? (à part la mauvaise foi)
[+] [^]Re: Re:
combien de langage et/ou d'architecture supporte par llvm?
Vu que ce projet est un projet apple je soupconne que en dehors des architectures concernant leur matos il y aura pas grand chose.
[^]Re: Re:
llvm n'est pas un projet apple, c'est un projet d'origine académique qui a beaucoup interessé apple (qui a du coup embauché chris lattner, qui etait à l'origine du projet)
[+] [^]Re: Re:
> Et alors qu'est ce qui t'empeche de faire un fork de llvm en gpl ?
Tu n'as pas le droit.
Soit t'es de mauvais foi, soit t'y connais rien en licence.
[^]Re: Re:
developpe un peu alors, pour l'édification des masses.
[+] [^]Re: Re:
Seul le détenteur du copyright peut modifier la licence.
[^]Re: Re:
c'est un peu différent en fait, on peut relicencier le logiciel sous une autre licence, mais le code qui est déja en BSD restera en BSD. C'est un peu comme si le logiciel était en double licence sur certaines parties du code.
[^]Re: Re:
C'est un peu comme si le logiciel était en double licence sur certaines parties du code.
Les parties de code issues de LLVM ne sont pas sous double licence. Elles restent en BSD. Le nouveau code par contre peut être en GPL.
Mais je n'appelle pas ça "un fork de LLVM en GPL".
Si on veut créer un "LLVM" GPL, il faut réécrire tout le code BSD, et ce n'est donc plus un fork.
[^]Re: Re:
Les parties de code issues de LLVM ne sont pas sous double licence. Elles restent en BSD. Le nouveau code par contre peut être en GPL.
Mais je n'appelle pas ça "un fork de LLVM en GPL".
Dans ce cas, le logiciel sera sous GPL, donc, à mon avis, on peut appelé ca un fork de LLVM en GPL.
[^]Re: Re:
En fait si j'ai bien compris la licence Illinois Open Source License/NCSA (licence de LLVM), le code source initialement développé sous cette licence doit rester sous cette licence puisque cette derniere stipule que le code doit conserver les conditions de la licence ainsi que son texte.
Si l'on y ajoute du code sous GPL, le travail combiné est sous GPL, mais le code source d'origine NCSA doit rester sous cette licence. Donc la distribution du logiciel sous forme binaire peut se faire sous GPL si la documentation associée au logiciel cite le copyright du code original sous licence NCSA.
Dans ce cas, faire un logiciel propriétaire doit répondre aux mêmes exigences.
Donc pour résumer, comme le dis PsychoFox, on peut bien faire un fork en GPL si le logiciel (travail combiné) contient du code source en GPL, le code source sous licence NCSA doit garder son copyright original (et la doc du logiciel doit citer ce copyright).
[^]Re: Re:
Oui, ca a toujours été comme ca pour toutes les licences de type BSD, c'est juste que beaucoup de gens ici font un raccourci un peu trop rapide en parlant de "changement" la licence : de toutes facons, tu ne peux pas dire a la place de l'auteur du code qui a sorti son soft sous BSD "Non, maintenant tu n'a plus le droit de faire ci ou ca" ; c'est son code !
Enfin, au final, comme le version de départ du fork GPL sera toujours dispo, et que les modifs sont apportées sous GPL, on peut dire que l'ensemble est GPL puisqu'on aura pas le droit de faire autre chose de la GPL si on dérive du code modifié. Et si on dérive du code original, il est toujours sous BSD, ce n'est pas parce que quelqu'un a fait un fork GPL que ca change quoi que ce soit au projet d'origine. Donc en partant de celui-ci, tu fais toujours "ce que tu veux" (i.e. on neglige souvent de parler de la citation requise par les BSD, mais c'est vu, je pense, comme un inconvéniant "mineur" quand on fait du proprio, par exemple).
[^]Re: Re:
> de toutes facons, tu ne peux pas dire a la place de l'auteur du code qui a sorti son soft sous BSD "Non, maintenant tu n'a plus le droit de faire ci ou ca" ; c'est son code !
Oui j'ai bien conscience de ca. Ce que je disais plus haut etait simplement pour le cas suivant:
- le projet A est sous NCSA
- le projet B rajoute du code GPL au code BSD et distribue le tout sous GPL.
- les fichiers copié depuis le projet A dans le projet B doivent rester sous licence NCSA, même dans le SVN du projet B.
Bien évidemment, on est d'accord que les fichiers sous licence NCSA du projet A restent sous licence NCSA tant que le contributeur ne modifie pas cette licence. Mais même dans ce cas, a-t-il le droit de demander au projet B de modifier la licence du code copié? Je crois qu'en France, les droits moraux lui en donneraient le droit, mais quid des US?
[^]Re: Re:
Souvent les gens pensent que la BSD va amener des contributions des boites commerciales. Le choix de la BSD est souvent fait pour ça.
Je pense que c'est plus souvent parce que le développeur accepte une utilisation et une distribution très libérale de son code. Et c'est tout.
Mais en moyenne ce n'est pas ce qu'on voit. On voyait ça il y a de nombreuses années, ce n'est plus le cas aujourd'hui.
D'ailleurs Yahoo!, Juniper, Cisco, NetASQ, NetApp, Isilon, Google ou IronPort (pour ne citer que celles que je connais pour utiliser FreeBSD et contribuer à divers niveaux au projet en retour) font semblant d'utiliser *BSD par bonté d'âme.
Sincèrement je pense que globalement t'as une idée très réduite de l'état d'esprit des développeurs *BSD ainsi que des situations dans lesquels ils sont utilisés.
vjm
[^]Re: Re:
Il n'y a pas et n'aura pas de système de fichier proprio distribué avec Linux
FS proprio pour linux:
http://linuxdevices.com/news/NS3780930308.html
Bien sur comme les drivers de CG, il ne sera pas distribué directement linké (car cela ne serait pas légal) mais quand même...
Pour en revenir à GCC, dans le cadre d'un projet j'ai eu besoin de personnaliser le code généré par un complateur C-->x86, j'ai essayé avec GCC, mais le temps qu'il faut pour se retrouver dedans... du coup j'ai opté pour TCC (je n'avais pas connaissance de LLVM à l'époque).
Une architecture plus modulaire aurait quand même été sympa.
[^]Re: Re:
> FS proprio pour linux:
> http://linuxdevices.com/news/NS3780930308.html
Où tu vois que c'est proprio ?
Il ne l'ont pas diffusé (du moins j'ai vu). On en sait rien. T'as vu la licence ?
> Bien sur comme les drivers de CG, il ne sera pas distribué directement linké (car cela ne serait pas légal) mais quand même...
Où t'as vu ça ?
ça dit :
Datalight has ported its commercial flash filesystem to Linux.
Ce n'est pas proprio. commercial != proprio.
RHEL est une distribution commerciale, mais pas proprio. Tu fais la différence ?
[^]Re: Re:
Ce n'est pas proprio. commercial != proprio.
Ô merci grand vizir de m'éclairer ainsi :-)
Sinon, exact on n'en sait rien, mais bon, si tu avais un peu l'habitude de travailler avec linux dans l'embarqué, tu serais qu'il y a peu de chance.
Tu veux parier ta couille gauche qu'il sera libre lorsqu'il sera diffusé ? X-D
[^]Re: Re:
Question: supposons que quelqu'un livre un logiciel proprio sous forme de code source qui doit s'interfacer avec un logiciel sous GPL (cas qui nous intéresse ici), mais sans le livrer avec le logiciel sous GPL, par exemple sous forme de patch.
Lorsque le client combine le patch propriétaire avec le logiciel sous GPL l'ensemble devrait être couvert par la GPL, n'est ce pas? Dans quelle mesure le client pourrait (ou ne pourrait pas) demander a l'éditeur du patch propriétaire de lui fournir les sources?
En écrivant ça, je me rend compte que ce cas couvre aussi bien ce filesystem proprio que les modules binaires de NVidia par exemple. La différence fondamentale étant que les modules du noyau sont considérés différemment par Linus Torlvalds que les filesystem qui font partie intégrante du noyau (sauf s'ils sont utilisés via FUSE, mais les perfs en prennent un coup je pense).
Que savez vous a ce sujet?
[^]Re: Re:
Il faut bien faire attention que le respect de la GPL est liée à la distribution. Celui qui livre le patch propriétaire n'a rien distribué sous GPL, puisqu'il ne distribue que son patch. C'est le client qui prend la décision de linker le tout. Le binaire qu'il obtient au final n'est alors pas distribuable lui, puisque le client ne serait pas en mesure de fournir l'ensemble sous license GPL ou compatible.
C'est exactement ce que fait NVIDIA, il te file un fichier objet, un fichier C qui interface le ficher objet avec le noyau, et c'est à toi de finir le travail de compilation/linkage. De cette manière, jamais NVIDIA ne distribue un module du noyau déjà tout pret, il distribue d'un coté un fichier C sous GPL, de l'autre un blob binaire sur lequel ils ont le copyright. Ce n'est bien sur absolument pas dans l'esprit de la GPL, mais c'est légal (je pense, je ne suis avocat).
Que ca soit un module pour un FS ou un module pour une CG, ca ne change rien, linus ne considère pas différement les 2, un module linké dynamiquement avec le noyau, n'est pas légalement distribuable.
[^]Re: Re:
Petit oublie ^^
Que ca soit un module pour un FS ou un module pour une CG, ca ne change rien, linus ne considère pas différement les 2, un module linké dynamiquement avec le noyau, n'est pas légalement distribuable.
Si le module contient du code sous license incompatible avec la GPL bien sur.
[^]Re: Re:
Merci pour l'explication.
> Il distribue d'un coté un fichier C sous GPL, de l'autre un blob binaire.
J'ai téléchargé le fichier et je ne trouve aucune trace du fichier C en GPL. Je pense qu'il n'y en a en fait même pas besoin.
Par contre les distributions qui inclue le driver NVidia avec le noyau linux deviennent alors hors la loi, non?
J'ai regardé pour Ubuntu, et en fait, il semble que le driver est téléchargé a la demande, donc ils sont ok puisque encore une fois c'est l'utilisateur qui installe lui même le driver.
Bref, je comprends maintenant mieux l'opposition de RMS a la modularisation de GCC, même si je ne suis pas d'accord avec elle.
[^]Re: Re:
J'ai téléchargé le fichier et je ne trouve aucune trace du fichier C en GPL. Je pense qu'il n'y en a en fait même pas besoin.
Si si je t'assure ^^ (il y en a même plusieurs), c'est juste que le fichier .run que tu télécharges sur le site de nvidia est une archive auto-extractible qui exécute ensuite automatiquement la compilation.
De toute facon, ils n'ont pas trop le choix, pour pouvoir charger un module dans le noyau, il faut qu'il ait été compilé avec les mêmes headers que ton noyau et le même compilateur (à une vache près), vu le nombre de distribs/versions du noyau/versions du compilateur, c'est plus simple de laisser l'utilisateur finir la compilation localement que de faire 72 paquets différents.
Et ils n'ont d'autant pas le choix que comme je l'ai dit précédemment, un module près à être chargé, donc complètement linké, ne pourrait être distribué légalement s'il n'est pas 100% compatible GPL. Aucune échappatoire à cela.
Par contre les distributions qui inclue le driver NVidia avec le noyau linux deviennent alors hors la loi, non?
Oui.
J'ai regardé pour Ubuntu, et en fait, il semble que le driver est téléchargé a la demande, donc ils sont ok puisque encore une fois c'est l'utilisateur qui installe lui même le driver
Encore une fois ce n'est pas une question de qui installe quoi volontairement, c'est une question de qui distribue quoi. Il n'est pas légal de distribuer un programme/module/... qui utiliserait à la fois du code GPL et du code incompatible GPL, même si la personne à qui cela ait distribué est d'accord. Je ne connait pas Ubuntu mais je parie que le module n'est pas tout pret à être chargé dans le noyau juste après le téléchargement et qu'au minimum il reste le phase de linkage à faire sur le pc de l'utilisateur.
[^]Re: Re:
>> J'ai téléchargé le fichier et je ne trouve aucune trace du fichier C en GPL. Je pense qu'il n'y en a en fait même pas besoin.
> Si si je t'assure ^^ (il y en a même plusieurs), c'est juste que le fichier .run que tu télécharges sur le site de nvidia est une archive auto-extractible qui exécute ensuite automatiquement la compilation.
En fait, Je me suis mal exprimé. Quand je disais qu'il n'y en a pas besoin, je ne parlais pas du fichier C en lui même qui n'est qu'un adaptateur pour le blob binaire. Ce que je voulais dire c'est que ce fichier ne me semble même pas avoir besoin d'être sous GPL pour que le processus décrit marche sans enfreindre la GPL.
> Je ne connait pas Ubuntu mais je parie que le module n'est pas tout pret à être chargé dans le noyau juste après le téléchargement et qu'au minimum il reste le phase de linkage à faire sur le pc de l'utilisateur.
En regardant sur le wiki d'Ubuntu la procédure a suivre pour installer manuellement le driver proprio d'ATI, j'ai des doutes sur ce qu'ils font (a moins qu'apt-get soit capable de compiler du code): https://help.ubuntu.com/community/BinaryDriverHowto/ATI
C'est pas pour les dénoncer, mais plutôt pour comprendre comment ils contournent le problème.
[^]Re: Re:
Pour la partie Xorg (DRI), étant sous licence X11 (~MIT), ya pas de problème.
C'est la partie Kernel (DRM) qui elle ne doit pas pouvoir être distribué déjà linkée.
Je me trompe p-e mais je vois pas comment on pourrait distribuer un module proprio pour linux tout pret à être chargé.
Encore une fois je ne connait pas ubuntu, mais apt doit bien etre capable d'exécuter des scripts de pre/post install ?
[^]Re: Re:
$ wget http://security.ubuntu.com/ubuntu/pool/restricted/l/linux-re(...)
--11:14:32-- http://security.ubuntu.com/ubuntu/pool/restricted/l/linux-re(...)
=> `linux-restricted-modules-2.6.24-7-generic_2.6.24.8-7.19_i386.deb'Résolution de security.ubuntu.com... 91.189.88.37
Connexion vers security.ubuntu.com|91.189.88.37|:80... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: 10 490 246 (10M) [application/x-debian-package]
100%[===================================>] 10 490 246 415.87K/s ETA 00:008
11:15:06 (366.55 KB/s) - « linux-restricted-modules-2.6.24-7-generic_2.6.24.8-7.19_i386.deb » sauvegardé [10490246/10490246]
$ dpkg-deb -x linux-restricted-modules-2.6.24-7-generic_2.6.24.8-7.19_i386.deb .
$ find lib/
lib/
lib/linux-restricted-modules
lib/linux-restricted-modules/2.6.24-7-generic
lib/linux-restricted-modules/2.6.24-7-generic/fglrx
lib/linux-restricted-modules/2.6.24-7-generic/fglrx/firegl_public.o
lib/linux-restricted-modules/2.6.24-7-generic/fglrx/libfglrx_ip.a.GCC4
lib/linux-restricted-modules/2.6.24-7-generic/fglrx/fglrx.mod.o
lib/linux-restricted-modules/2.6.24-7-generic/ath_hal
lib/linux-restricted-modules/2.6.24-7-generic/ath_hal/ah_os.o
lib/linux-restricted-modules/2.6.24-7-generic/ath_hal/i386-elf.hal.o
lib/linux-restricted-modules/2.6.24-7-generic/ath_hal/ath_hal.mod.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/nv-kernel.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/nv.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/nv-vm.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/os-agp.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/os-interface.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/os-registry.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_legacy/nvidia.mod.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia
lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nv-kernel.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nv.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nv-vm.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia/os-agp.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia/os-interface.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia/os-registry.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nv-i2c.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia/nvidia.mod.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nv-kernel.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nv.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nv-vm.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/os-agp.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/os-interface.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/os-registry.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nv-i2c.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nvacpi.o
lib/linux-restricted-modules/2.6.24-7-generic/nvidia_new/nvidia.mod.o
lib/modules
lib/modules/2.6.24-7-generic
lib/modules/2.6.24-7-generic/madwifi
lib/modules/2.6.24-7-generic/madwifi/wlan.ko
lib/modules/2.6.24-7-generic/madwifi/wlan_acl.ko
lib/modules/2.6.24-7-generic/madwifi/wlan_ccmp.ko
lib/modules/2.6.24-7-generic/madwifi/wlan_scan_ap.ko
lib/modules/2.6.24-7-generic/madwifi/wlan_scan_sta.ko
lib/modules/2.6.24-7-generic/madwifi/wlan_tkip.ko
lib/modules/2.6.24-7-generic/madwifi/wlan_wep.ko
lib/modules/2.6.24-7-generic/madwifi/wlan_xauth.ko
lib/modules/2.6.24-7-generic/madwifi/ath_rate_onoe.ko
lib/modules/2.6.24-7-generic/madwifi/ath_rate_amrr.ko
lib/modules/2.6.24-7-generic/madwifi/ath_rate_sample.ko
lib/modules/2.6.24-7-generic/madwifi/ath_pci.ko
lib/firmware
lib/firmware/2.6.24-7-generic
lib/firmware/2.6.24-7-generic/acx
lib/firmware/2.6.24-7-generic/acx/1.0.9
lib/firmware/2.6.24-7-generic/acx/1.0.9/tiacx100usb
lib/firmware/2.6.24-7-generic/acx/default
lib/firmware/2.6.24-7-generic/acx/default/tiacx100r11
lib/firmware/2.6.24-7-generic/acx/default/tiacx100
lib/firmware/2.6.24-7-generic/acx/default/tiacx100r0D
lib/firmware/2.6.24-7-generic/acx/default/tiacx111c17
lib/firmware/2.6.24-7-generic/acx/default/tiacx100r15
lib/firmware/2.6.24-7-generic/acx/default/tiacx100usb
lib/firmware/2.6.24-7-generic/acx/default/tiacx111c19
lib/firmware/2.6.24-7-generic/acx/default/tiacx111c16
lib/firmware/2.6.24-7-generic/acx/1.9.8.b
lib/firmware/2.6.24-7-generic/acx/1.9.8.b/tiacx100r15
lib/firmware/2.6.24-7-generic/acx/1.9.8.b/tiacx100r0D
lib/firmware/2.6.24-7-generic/acx/1.9.8.b/tiacx100
lib/firmware/2.6.24-7-generic/acx/1.9.8.b/tiacx100r11
lib/firmware/2.6.24-7-generic/acx/1.2.0.30
lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111
lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111r17
lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111c16
lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111r16
lib/firmware/2.6.24-7-generic/acx/1.2.0.30/tiacx111c17
lib/firmware/2.6.24-7-generic/acx/1.0.7
lib/firmware/2.6.24-7-generic/acx/1.0.7/tiacx100usb
lib/firmware/2.6.24-7-generic/acx/0.4.11.4
lib/firmware/2.6.24-7-generic/acx/0.4.11.4/tiacx111c16
lib/firmware/2.6.24-7-generic/acx/1.2.1.34
lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111
lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111r17
lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111c16
lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111r16
lib/firmware/2.6.24-7-generic/acx/1.2.1.34/tiacx111c17
lib/firmware/2.6.24-7-generic/acx/1.7.0
lib/firmware/2.6.24-7-generic/acx/1.7.0/tiacx100r0D
lib/firmware/2.6.24-7-generic/acx/1.7.0/tiacx100
lib/firmware/2.6.24-7-generic/acx/1.7.0/tiacx100r11
lib/firmware/2.6.24-7-generic/acx/readme.txt
lib/firmware/2.6.24-7-generic/acx/0.1.0.11
lib/firmware/2.6.24-7-generic/acx/0.1.0.11/tiacx111c16
lib/firmware/2.6.24-7-generic/acx/2.3.1.31
lib/firmware/2.6.24-7-generic/acx/2.3.1.31/tiacx111c16
lib/firmware/2.6.24-7-generic/acx/2.3.1.31/tiacx111c19
lib/firmware/2.6.24-7-generic/acx/2.3.1.31/tiacx111c17
lib/firmware/2.6.24-7-generic/acx/0.4.11.9
lib/firmware/2.6.24-7-generic/acx/0.4.11.9/tiacx111
lib/firmware/2.6.24-7-generic/acx/0.4.11.9/tiacx111c16
lib/firmware/2.6.24-7-generic/acx/0.4.11.9/tiacx111r16
lib/firmware/2.6.24-7-generic/dvb-fe-or51132-qam.fw
lib/firmware/2.6.24-7-generic/dvb-fe-or51132-vsb.fw
lib/firmware/2.6.24-7-generic/dvb-fe-or51211.fw
lib/firmware/2.6.24-7-generic/dvb-ttpci-01.fw
lib/firmware/2.6.24-7-generic/dvb-usb-avertv-a800-02.fw
lib/firmware/2.6.24-7-generic/dvb-usb-dib0700-1.10.fw
lib/firmware/2.6.24-7-generic/dvb-usb-dibusb-5.0.0.11.fw
lib/firmware/2.6.24-7-generic/dvb-usb-dibusb-6.0.0.8.fw
lib/firmware/2.6.24-7-generic/dvb-usb-dtt200u-01.fw
lib/firmware/2.6.24-7-generic/dvb-usb-umt-010-02.fw
lib/firmware/2.6.24-7-generic/dvb-usb-vp702x-01.fw
lib/firmware/2.6.24-7-generic/dvb-usb-vp7045-01.fw
lib/firmware/2.6.24-7-generic/dvb-usb-wt220u-02.fw
lib/firmware/2.6.24-7-generic/dvb-usb-wt220u-fc03.fw
lib/firmware/2.6.24-7-generic/dvb-usb-wt220u-zl0353-01.fw
$ dpkg-deb -e linux-restricted-modules-2.6.24-7-generic_2.6.24.8-7.19_i386.deb .
$ cat postinst
#!/bin/sh
case "$1" in
configure)
lrm-manager --kver=2.6.24-7-generic
;;
esac
$ head /sbin/lrm-manager
#!/bin/sh
# Note that this script is not only /sbin/lrm-manager, but it also
# ends up being the postinst for nic-restricted-modules. Take care
# when adding features to make sure they'll work in d-i's busybox
# If you wish to disable the link-on-boot feature for certain modules,
# please see /etc/default/linux-restricted-modules-common for details.
set -e
Le .deb contient les .o que lrm-manager link au moment du postinst.
Les .ko sont les modules madwifi GPL, seul ath_hal est proprio.
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: Re:
Merci pour tes réponses Sigmatador et merci pour la démonstration inico.