Kernel Traffic #139 For 29 Oct 2001

Il a eu beaucoup de confusion sur l-k (mailling liste linux kernel) à propos de MODULE_LICENSE et EXPORT_SYMBOL_GPL. Je vais essayer de faire simple.

Pas besoin de me mettre en copie de toutes vos discussions, aussi cela ne m'intéresse pas de connaître votre point de vue sur la GPL.

MODULE_LICENSE

MODULE_LICENSE() permet aux développeurs du noyau de repérer,"marquer", les modules dont le code source n'est généralement pas disponible. Cela signifie que seuls les fournisseurs du module sont à même de débogguer les problèmes, aussi envoyer vos rapports de boggues à eux, pas sur la l-k. La chaîne indiquant avec précision que le source est libre, est en cours d'élaboration

Un module sans licence doit être considéré comme propriétaire. Tous les modules n'ont pas encore un MODULE_LICENSE() mais ce sera bientôt le cas. Pour le code qui n'est pas en standard dans les sources du noyau, c'est au fournisseur du source de préciser la licence. Je recommande que les modules binaires aient une description du style :-

MODULE_LICENSE("Propriétaire. envoyer les boggues à martin.dupont@quelquepart")

Modutils "marque" le noyau comme corrompu dès lors qu'un module sans un MODULE_LICENSE() compatible GPL est chargé, en informant de la chaîne de licence associée, ainsi les utilisateurs savent où rapporter les boggues. Oops informe également du statut corrompu/marqué du noyau. Les développeurs du noyau peuvent alors décider si ils s'occupent ou non d'un rapport de boggue. Fin de l'histoire.

Quelqu'un fit alors la remarque suivante : qu'en est-il de la liaison de code propriétaire avec le noyau ?. Si on compile puis lie avec le noyau du code que l'on de distribue pas, croyez moi ou non, il y a une faille dans la GPL Rien ne peut vous empêcher de contruire votre propre noyau avec des modules binaires, pour les boggues se sera votre problème, et vous ne pourrez pas redistribuer le résultat.

EXPORT_SYMBOL_GPL

Certains développeurs du noyau n'aiment pas fournir une interface à leur code, pour ensuite voire leur interface utilisée par des modules binaires. Ils voient cela comme de l'appropriation de leur travail. Que vous soyez ou non d'accord avec ce point de vue n'a pas d'importance, la personne à qui appartient le copyright d'un code source décide de la manière dont son code peut être utilisé.

EXPORT_SYMBOL_GPL() permet aux nouvelles interfaces d'être définies comme accessibles uniquement aux modules compatibles GPL. Cela n'a pas de rapport avec la notion de "corruption"/marquage du noyau, c'est basé évidemment sur les chaînes de MODULE_LICENSE().

EXPORT_SYMBOL_GPL() peut seulement être utilisé pour les nouveaux symboles exportés. Linus l'a dit, "I believe the phrase involved killer penguins with chainsaws for anybody who changed existing exported interfaces." (NDT pour la traduction c'est plus cher..., ca doit être du genre : le premier qui touche à l'exportation des interfaces sera envoyé au pôle nord :) puis bouffé par les manchos. :), bref ne l'utilisez que pour les nouveaux symboles quoi !! )

Les appels systèmes ne sont pas touchés et ne peuvent l'être. Quiconque pense autrement n'a rien compris à la GPL. Les appels système permettent aux programmes d'accéder au noyau, personne n'a jamais prétendu qu'un programme uniquement fourni en binaire n'ait pas le droit d'utiliser les appels systèmes.

... et si quelqu'un pense que remplacer

int foo(void *bar);
et
EXPORT_SYMBOL(bidon);

par

int __foo(void *bar, int baz);
static int foo(void *bar)
{


return __foo(bar, 0);


}
et
EXPORT_SYMBOL_GPL(__foo);

vous sauvera de la vengeance des manchos (cf plus haut), gardez à l'esprit que vous ne vous en tirerez pas comme cela. (NDT : traduction perso, mais l'esprit y est...)

La licence BSD (no advert licence) n'est pas considérée comme compatible GPL pour le noyau. Seule une licence double BSD/GPL ne "marque pas" le noyau, parce que le code est aussi disponible en GPL. Un module utilisant du code basé sur la licence "no avt" BSD, sera marqué.

Cela pose un problème pour certains modules du noyau qui sont en "no advt" BSD. Le mieux serait de les passer en BSD/GPL mais cela risque d'être impossible. Comme le code est toujours disponible, on peut les changer en

"BSD sans la clause 'advertisement', le source est dans l'arborescence du noyau"

et ajouter la chaîne à la liste qui ne "marque" pas. Le code "BSD no advert" qui n'est pas dans l'arborescence du noyau peut soit passer en BSD/GPL soit être marqué, le fournisseur choisira.

Testeurs Demandés :

les correctifs pour activer un noyau totalement préemptible sont disponibles sur : http://tech9.net/rml/linux pour les noyaux 2.4.10, 2.4.12, 2.4.12-ac3, et 2.4.13-pre5.

Voilà ce que c'est:

Un noyau préemptible. Cela réduit les temps de latences.

Ce qui est nouveau:

• sync avec les dernières versions du noyau
• si HIGHMEM_DEBUG était activé, le compteur de préemption était incrémenté mais jamais décrémenté. cela aboutissait à une désactivation permanente de la préemption.
• si HIGHMEM_DEBUG n'était pas activé, HIGHMEM risquait de planter le système en raison d'un cas ou la préemption était activée sans jamais être désactivée.
• Réapplique un ancien correctif à pgalloc pour prévenir la réentrance (per-CPU data)

Les correctifs suivants permettent de détecter des variables par-CPU afin de les verouiller dans le cadre de la préemption.

Cela a déjà été rapporté auparavant.

n_tty_receive_buf() met un caractère dans la queue du tty puis fait un appel à con_flush_chars(), qui modifie tty->driver_data.

Le problème est qu'il y a un moment pendant lequel le périphérique peut être fermé (spécialement si le caractère est "^D"!), et con_close() qui va mettre à zéro tty->driver_data. D'ou un déréférencement de pointeur null.

Je ne crois pas à cette explication parce que ce n'est pas le bon timing - la lecture n'est pas faite avant que flush ne soit appelé. Aussi, ce sera très difficile de reproduire ce bug. Cela vient probablement d'ailleurs. Mais un peut de rafistolage pourra sans doute le corriger.

C'est plutôt kbuild que config qui doit être modifié. Je peux le faire facilement dans kbuild 2.5, je l'ai déjà fait autrefois. Mais cela ne marche plus lorsque vous avez des correctifs qui interfèrent entre-eux, sélectionnez une config ou l'autre et cela marche, mais sélectionnez les deux (s'ils ne sont pas exclusifs) et cela échoue.

Je n'ai pas la solution, mais le remède à l'interférence des correctifs est pire que mal que l'on tente de corriger, c'est pourquoi je n'ai pas mis mon correctif dans kbuild 2.5.

http://sourceforge.net/projects/kbuild

J'ai envoyé un courriel (NDT :un email quoi !!) au responsable il y a six mois mais je n'ai pas eu de réponse. Aussi, j'ai amélioré le correctif moi même pour fonctionner avec les version 2.4.2, 2.4.4 et 2.4.5. A un moment j'ai basculé sur 2.4.4-ac9, que j'utilise encore sans problème, mais je n'ai pas le temps de le porter sur d'autres versions.

Je ne sais pas si quelqu'un a déjà fait quelque chose de similaire. Personnellement, j'ai initialement trouvé ce correctif dans le noyau de la Mandrake 7.2 (je crois), mais je ne sais pas s'ils l'utilisent encore. Je vérifierai. Quoi qu'il en soit, si personne n'est déjà en train de le faire, je ferai de mon mieux pour le porter sur de nouveaux noyaux, également sur la série des -ac, et si j'y arrive également sur les noyaux à venir.

Comme c'est la première fois que je maintiens du code dans le noyau, je serai heureux que vous m'indiquiez des ressources qui pourront m'aider à savoir quels sont les changements intervenus dans la série des 2.4. Je me rappelle qu'il y déjà eu des modifications entre la 2.4.0 et la 2.4.4 qui ont impliqué des changements dans le code, en partie en raison de correctifs sur la gestion des fs (principalement des modifs liées aux verrous).