He escrito algunos módulos kernel en Ada, y me he topado con un pequeño problema. La licencia se define como una macro c, y no puedo determinar qué es en realidad. ¿Es una solución adecuada simplemente tener algo de reexportación de todas las funciones c que requieren GPL si tanto el módulo c como el ada tienen licencias compatibles con GPL? ¿Hay una mejor manera de hacer esto?Configuración de la licencia para módulos en el kernel de Linux
Tratar con C macros es un PITA real. Soñé que algún día los programadores de C harían un favor al resto del mundo y dejarían de usarlos.
Si fuera yo, correría la macro para ver qué produce, luego escribiría algún código Ada para generar el equivalente.
Al leer la respuesta de Roland, me parece que puede ser necesario el pragma linker_section definido en la implementación.
pragma Linker_Section ([Entidad =>] LOCAL_NAME, [Sección =>] static_string_EXPRESSION);
LOCAL_NAME debe hacer referencia a un objeto declarado en el nivel de biblioteca . Este pragma especifica el nombre de la sección enlazadora para la entidad dada . Es equivalente a
__attribute__((section))en GNU C y hace que LOCAL_NAME se coloque en la sección static_string_EXPRESSION del ejecutable (suponiendo que el enlazador no cambie el nombre de la sección ).
No estoy seguro de si esta pregunta es una broma o no, pero si se toma en serio escribir módulos kernel en Ada, entonces no puedo imaginar que establecer la licencia del módulo sea un obstáculo en comparación con todo de lo contrario debes haber golpeado.
En cualquier caso, la licencia del módulo es solo una cadena como "license = GPL" en la sección .modinfo del archivo .ko. En código C, está creado por la macro __MODULE_INFO() de <linux/moduleparam.h>, que solo crea una matriz de char que está configurada en la cadena como se indica arriba, etiquetada con __attribute__((section(".modinfo"))).
Supongo que probablemente exista una forma análoga de hacer esto en Ada; de lo contrario, en el peor de los casos, debería ser posible hacerlo con un script del enlazador. Presumiblemente, usted ya tiene alguna forma de manejar esto de todos modos, para establecer la parte "vermagic = XXX" de la sección .modinfo.
Como probablemente esté usando GNAT, puede utilizar pragma License "para permitir la verificación automática de las condiciones de licencia apropiadas con respecto a la GPL estándar y modificada".
como un enfoque para eludir el problema, ¿podría dejar la parte de licencia en C y utilizar Annex B (Interfaz con otros idiomas) cuenta para acceder a ella?
Esto debería contener el problema al menos, y le permite continuar con otros módulos.
En el mejor de los casos, le puede permitir examinar en Ada, cómo se ve la licencia y realizar una ingeniería inversa de esa manera.
¿Por qué la pregunta sería una broma? También estaba listo para cualquier otro obstáculo que golpee; Honestamente, no esperaba que esto fuera un problema real. – Probie
porque 1) es mucho más fácil si solo escribes tu módulo en C y 2) es un poco sorprendente que pudieras resolver todo lo demás, estoy seguro de que tocaste y luego te quedaste atascado siguiendo el no-todo-eso-complejo expansión de la macro MODULE_LICENSE(). – Roland
No hay una buena razón (aparte de las políticas) por la cual no se puede escribir un módulo kernel en Ada. Estoy de acuerdo en que al principio parece sorprendente que algo tan aparentemente básico como las macros C sea el mayor obstáculo para la interoperabilidad, pero lo he visto muchas veces. Las macros son malvadas –