Necesito escribir un módulo kernel que no sea un controlador de dispositivo. Ese módulo se comunicará con algunos procesos de espacio de usuario. Como no quiero usar ioctl(), me queda la tarea de crear un archivo en el directorio/proc o crear un archivo de dispositivo en el directorio/dev.Cuándo utilizar/proc y cuándo/dev
Pregunta: ¿Cómo decido entre/proc y/dev. ¿Es solo una decisión o hay algún acuerdo no escrito sobre el uso de estos dos?
Tendrá una gran dificultad para agregar una nueva interfaz en/proc /. Los desarrolladores del kernel no están contentos de que se haya convertido en un vertedero para interfaces diversas, y a menos que realmente modifiquen algo sobre procesos a través de/proc/pid /, creo que tendrán problemas para convencer a la comunidad kernel de que lo acepte.
Un archivo de dispositivo en/dev/puede ser aceptable, incluso para módulos que no son realmente controladores de dispositivo. (por ejemplo,/dev/kvm,/dev/pts,/dev/ecryptfs,/dev/fusible,/dev/kmsg,/dev/ptmx, etc.) Sin embargo, los archivos de los dispositivos son demasiado fáciles de manipular con ioctl (), y creo que tienes razón para evitarlo si puedes.
La tendencia actual en los círculos de kernel es sysfs o sistemas de archivos personalizados. El enfoque sysfs se basa en la semántica de un solo valor por archivo, destinado a ser manipulado con echo y cat. Es maravilloso para los usuarios si funciona para ti. Los sistemas de archivos personalizados le permiten escribir interfaces muy específicas con capacidad binaria, y fs/libfs.c debería ayudarle a escribir su propio sistema de archivos para sus propias necesidades. (No conozco a nadie que haya usado configfs, pero siempre pensé que se veía limpio. ¿Tal vez se adaptaría a su módulo?)
Como Sarnold señala los objetos representados en/dev/no tienen que ser " verdaderos "dispositivos". Si su controlador expone una interfaz tipo POSIX (abrir/leer/escribir) no hay razón para no usarla. ¿Qué tipo de comunicación planea tener entre el usuario y el espacio del kernel? – stsquad
Una parte de nuestro software realiza demasiadas llamadas al sistema lo que afecta el rendimiento del sistema. Para evitar la carga de estas llamadas, planeamos moverlo al espacio del kernel. Esencialmente, la comunicación entre kernel y espacio de usuario implicará grandes transferencias de datos. Agradecería mucho si alguien puede sugerir alguna otra técnica para este problema. – binW
Es poco probable que descubra que las llamadas al sistema son significativamente más rápidas desde el espacio del núcleo, al menos, no lo suficiente como para que superen el costo adicional de copiar grandes cantidades de datos hacia y desde el espacio del kernel. Dicho esto, investigue un archivo de dispositivo de caracteres que implemente 'mmap'. – caf