Ada でいくつかのカーネル モジュールを作成しましたが、ちょっとした問題にぶつかりました。ライセンスは ac マクロとして定義されていますが、それが実際に何であるかはわかりません。c と ada モジュールの両方に GPL 互換のライセンスがある場合、GPL を必要とするすべての c 関数を c に再エクスポートするだけの適切な解決策はありますか? これを行うより良い方法はありますか?
4 に答える
この質問が冗談であるかどうかはわかりませんが、Ada でカーネル モジュールを書くことに真剣に取り組んでいるのであれば、モジュール ライセンスの設定が、必要な他のすべてのものに比べて大きな障害になるとは思えません。打つ。
いずれにせよ、モジュールのライセンスは、.ko ファイルの .modinfo セクションにある "license=GPL" のような単なる文字列です。C コードでは、__MODULE_INFO()
マクロ fromによって構築されます。このマクロは、上記のように文字列に設定され、 でタグ付けされた<linux/moduleparam.h>
の配列を作成します。char
__attribute__((section(".modinfo")))
おそらく、Ada でこれを行う類似の方法があると思います。そうでない場合は、最悪の場合、リンカー スクリプトで実行できるはずです。おそらく、.modinfo セクションの "vermagic=XXX" 部分を設定するために、何らかの方法でこれを処理する方法が既にあると思われます。
C マクロを扱うのは王道の PITA です。私は、いつの日か C プログラマーが世界中の人々に恩恵をもたらし、C プログラマーの使用をやめるという夢を持っています。
私だったら、マクロを実行して出力を確認し、Ada コードを記述して同等の結果を出力します。
Roland の回答を読んでみると、実装定義のプラグマ linker_sectionが必要になる可能性があるように思えます。
pragma Linker_Section ( [Entity =>] LOCAL_NAME, [Section =>] static_string_EXPRESSION);
LOCAL_NAME は、ライブラリ レベルで宣言されたオブジェクトを参照する必要があります。このプラグマは、特定のエンティティのリンカー セクションの名前を指定します。これは GNU C と同等
__attribute__((section))
であり、LOCAL_NAME を実行可能ファイルの static_string_EXPRESSION セクションに配置します (リンカーがセクションの名前を変更しないと仮定します)。
この問題を回避する方法として、ライセンスの部分を C のままにして、Annex B (他の言語とのインターフェイス) 機能を使用してアクセスすることはできますか?
これにより、少なくとも問題が解決され、他のモジュールに進むことができます。
せいぜい、Adaでライセンスがどのように見えるかを調べて、そのようにリバースエンジニアリングできるようになるかもしれません。
おそらく GNAT を使用しているので、プラグマ Licenseを使用して、「標準および変更された GPL に関して適切なライセンス条件を自動チェックできるようにする」ことができる場合があります。