7
votes

Définition de la licence pour les modules dans le noyau Linux

J'ai écrit des modules de noyau à Ada et j'ai frappé un peu de problème. La licence est définie comme une macro C, et je ne peux pas résoudre ce qu'il est réellement. Est-ce une solution appropriée pour simplement avoir une nouvelle ré-exportation de toutes les fonctions C nécessitant GPL si le module C et le module ADA a des licences compatibles GPL? Y a-t-il une meilleure façon de faire cela?


0 commentaires

4 Réponses :


6
votes

Je ne sais pas si cette question est une blague ou non, mais si vous êtes sérieux au sujet de la rédaction de modules de noyau à Ada, je ne peux pas imaginer que le réglage de la licence du module est une grande partie d'un obstacle par rapport à tout le reste. Vous devez avoir frappé.

Dans tous les cas, la licence de module est juste une chaîne comme "licence = gpl" dans la section .Modinfo du fichier .ko. En code C, il est construit par le __ module_info () macro de , qui crée simplement un tableau de char que est défini sur la chaîne comme ci-dessus, étiquetée avec __ attribut __ ((section (". modinfo"))) . .

Je devinerais qu'il y a probablement une manière analogue à ce faire dans ADA; Sinon, dans le pire des cas, il devrait être possible de faire avec un script de liaison. Vraisemblablement, vous avez déjà une façon de gérer cela de toute façon, de définir la partie "Vermagic = xxx" de la section .Modinfo.


6 commentaires

Pourquoi la question serait-elle une blague? J'étais aussi prêt pour tous les autres obstacles que j'ai frappés; Honnêtement, je ne m'attendais pas à ce que ce soit un vrai problème.


Parce que 1) C'est vraiment beaucoup plus facile si vous écrivez simplement votre module en C et 2), il est un peu surprenant que vous ayez pu résoudre tout ce que vous êtes assuré que vous avez frappé, puis vous êtes coincé à la suite de l'expansion non complexe. de la macro module_license ().


Il n'y a pas de bonne raison (autre que des politiques) Pourquoi on ne pouvait pas écrire un module de noyau à Ada. Je conviendrai d'abord qu'il semble d'abord surprendre que quelque chose comme apparemment fondamental que C Macros serait le plus gros obstacle d'interopérabilité, mais je l'ai vu se produire moi-même plusieurs fois. Les macros sont diaboliques.


Pas de bonne raison autre que les politiques et tous les aspects pratiques, aiment avoir à inverser l'ingénieur ces macros (et rester à jour à mesure que la mise en œuvre du module change). Et y a-t-il une bonne raison de prendre la douleur du code ada correspondant à l'impédance avec le noyau?


@Roland - Cela ressemble à une question séparée SE. Si vous voulez vraiment une réponse, vous devriez le demander de cette façon. En tant que personne qui connaît assez bien les deux langues (bien que je fasse la majeure partie de mes programmations de noyau dans les rtoses, pas Linux), ma réponse serait certainement oui. Il y a de nombreuses situations dans lesquelles il en serait facilement la peine, une fois que vous avez compris comment le faire.


J'ai des outils de vérification statiques appropriés pour ADA, je ne trouve rien de près pour c. Donc oui. Ça vaut le coup.



2
votes

Comme vous utilisez probablement GNAT, vous pourrez peut-être utiliser Licence de pragma "pour permettre une vérification automatisée des conditions de licence appropriées en ce qui concerne la GPL standard et modifiée."


1 commentaires

@Probie: Je vois ce que tu veux dire; Il ne vérifie que la compatibilité, mais cela pourrait compléter T.E.D. HREF="http://stackoverflow.com/a/11936532/230513"> Suggestion .



6
votes

Traiter avec C Macros est un pita royal. J'ai un rêve que les programmeurs d'un jour C feront le reste du monde une faveur et cesser de fumer.

Si c'était moi, j'exécuterais la macro pour voir ce qu'elle génère, puis écrivez du code ADA pour produire l'équivalent.

de la lecture de la réponse de Roland, il me ressemble à la mise en œuvre définie sur Pragma Linker_Section peut être requis.

pragma linker_section ([entité =>] Local_Name, [Section =>] static_string_expression);

nom local doit faire référence à un objet déclaré à la bibliothèque. niveau. Ce pragma spécifie le nom de la section de liaison pour le entité donnée. Il équivaut à __ attribut __ ((section)) dans gnu c et provoque la placement local_name dans la static_string_expression section de l'exécutable (en supposant que la liaison ne renomme pas le section).


0 commentaires

3
votes

comme une approche pour éviter le problème, pouvez-vous quitter la partie de licence en C et utiliser Annexe B (interface avec d'autres langues) Caractéristiques pour y accéder?

Ceci devrait contenir au moins le problème et vous permettre de passer à autre avec d'autres modules.

Au mieux, cela peut vous permettre d'examiner à ADA, quelle est la licence de la licence et de l'ingénieur inverse de cette façon.


0 commentaires