modprobe - insmod linux
¿Cuándo debería escribir un módulo de kernel de Linux? (10)
Algunas personas quieren mover el código del espacio de usuario al espacio del kernel en Linux por algún motivo. Muchas veces la razón parece ser que el código debería tener una prioridad particularmente alta o simplemente "el espacio del núcleo es más rápido".
Esto me parece extraño. ¿Cuándo debería considerar escribir un módulo kernel? ¿Hay un conjunto de criterios?
¿Cómo puedo motivar a mantener el código en el espacio de usuario que (creo) pertenece allí?
El código que se ejecuta en el kernel accede a la memoria, a los periféricos, a las funciones del sistema de formas diferentes al código del espacio de usuario y, por lo tanto, tiene la capacidad de ser más eficiente. Por no mencionar las restricciones de seguridad reducidas para el código kernel. Sin embargo, todo esto tiene un costo, como aumentar la posibilidad de abrir el kernel a amenazas de seguridad, bloquear el sistema operativo, complicar la depuración, etc.
Hay razones muy limitadas para poner cosas en el kernel. Si está escribiendo controladores de dispositivos, está bien. Cualquier aplicación estándar: nunca.
Los inconvenientes son enormes. La depuración se hace más difícil, los errores se vuelven más frecuentes y difíciles de encontrar. Puede comprometer la seguridad y la estabilidad. Es posible que deba adaptarse a los cambios del kernel con mayor frecuencia. Resulta imposible realizar el acceso a otros sistemas operativos UNIX.
Lo más cerca que he llegado al kernel fue un sistema de archivos personalizado (con mysql en el fondo) e incluso para eso usamos FUSE (donde la U significa espacio de usuario).
No estoy seguro de que la pregunta sea correcta. Debería haber una buena razón para mover las cosas al espacio del kernel. Si no hay ningún motivo, no lo hagas.
Por un lado, la depuración se hace más difícil, y el efecto de los errores es mucho peor (crash / pánico en lugar de simple coredump).
Como regla general. Piense en lo que quiere saber y si eso es algo que vería en un libro o clase de desarrollo de sistema operativo, entonces tiene una buena oportunidad de pertenecer al kernel. Si no, manténgalo fuera del kernel. Si tiene una muy buena razón para romper esa regla, asegúrese de tener suficiente conocimiento para saberlo usted mismo o de que esté trabajando con alguien que tenga ese conocimiento.
Sí, puede sonar duro, pero esto es exactamente lo que quise decir, si no lo sabe, entonces esté casi seguro de que la respuesta es no, no lo haga en el kernel. Mover su desarrollo al espacio del kernel abre una lata de gusanos gigantes que debe estar seguro de poder manejar.
Regla de oro: haga todo lo posible para mantener su código en el espacio de usuario. Si no crees que puedes, dedícale tanto tiempo investigando alternativas al código del kernel como lo harías al escribir el código (es decir, mucho tiempo), y luego intenta de nuevo implementarlo en el espacio del usuario. Si aún no puede, investigue más para asegurarse de que está haciendo la elección correcta, luego muévase con cautela hacia el kernel. Como han dicho otros, hay muy pocas circunstancias que dicten la escritura de módulos del kernel y la depuración del código del núcleo puede ser bastante infernal, así que manténgase alejado a toda costa.
En cuanto a las condiciones concretas que debe comprobar al considerar la escritura de código kernel-mode, aquí hay algunas: ¿Necesita acceso a recursos de muy bajo nivel, como las interrupciones? ¿Su código define una nueva interfaz / controlador para el hardware que no se puede construir sobre la funcionalidad actualmente exportada? ¿Su código requiere acceso a estructuras de datos o primitivas que no se exportan desde el espacio del kernel? ¿Está escribiendo algo que será utilizado principalmente por otros subsistemas del kernel, como un programador o sistema VM (incluso aquí no es del todo necesario que el subsistema sea kernel-mode: Mach tiene un fuerte soporte para localizadores de memoria virtual de modo de usuario , entonces definitivamente se puede hacer)?
Si su gente quiere realmente alta prioridad, determinismo, baja latencia, etc., el camino correcto es usar alguna versión en tiempo real de Linux (u otro sistema operativo).
Consulte también las opciones de kernel prioritarias, etc. Exactamente lo que debe hacer depende de los requisitos, pero poner el código en los módulos del kernel probablemente no sea la solución adecuada, a menos que esté conectando hardware directamente.
Si solo necesita menor latencia, mayor rendimiento, etc., probablemente sea más barato comprar una computadora más rápida que desarrollar código de kernel.
Los módulos Kernel pueden ser más rápidos (debido a menos conmutadores de contexto, menos sobrecarga de llamadas al sistema y menos interrupciones), y ciertamente se ejecutan con muy alta prioridad. Si desea exportar una pequeña cantidad de código bastante simple al espacio del kernel, esto podría estar bien. Es decir, si se encuentra que un pequeño fragmento de código es crucial para el rendimiento, y es el tipo de código que se beneficiaría si se lo coloca en modo núcleo, entonces puede justificarse colocarlo allí.
Pero se debe evitar mover grandes partes de su programa al espacio del kernel a menos que todas las otras opciones estén completamente agotadas. Aparte de la dificultad de hacerlo, el beneficio de rendimiento no es muy grande.
Básicamente, estoy de acuerdo con rpj. El código debe estar en espacio de usuario, a menos que sea REALMENTE necesario.
Pero, para enfatizar su pregunta, ¿qué condición?
Algunas personas afirman que el controlador debe estar en el kernel, lo que no es cierto. Algunos controladores no son sensibles al tiempo, de hecho, muchos controladores son así.
Por ejemplo, el enmarcador, el temporizador RTC, los dispositivos i2c, etc. Esos controladores se pueden mover fácilmente al espacio del usuario. Incluso hay algunos sistemas de archivos escritos en el espacio del usuario.
Deberías moverte al espacio del kernel donde está la sobrecarga, ej. cambio de kernel de usuario, se vuelve inaceptable para que su código funcione correctamente.
Pero hay muchas formas de lidiar con esto. Por ejemplo, / dev / mem proporciona una buena forma de acceder a su memoria física, tal como lo hace desde el espacio del kernel.
Cuando la gente habla sobre ir a RTOS, generalmente soy escéptico. En estos días, el procesador es tan poderoso, que la mayoría de las veces, el aspecto en tiempo real se vuelve insignificante.
Pero incluso, digamos, estás tratando con SONET, y necesitas hacer una conmutación de protección dentro de los 50 ms (en realidad, incluso menos, ya que las restricciones de 50 ms se aplican a todo el anillo), aún puedes hacer el cambio muy rápido, si tu el hardware lo admite.
Muchos de los enmarcadores en estos días pueden brindarle un soporte de hardware que reduce la cantidad de escrituras que necesita hacer. Su trabajo básicamente responde a la interrupción lo más rápido posible. Y Linux no está nada mal. La latencia de interrupción que obtuve fue de menos de 1 ms, incluso si tengo un montón de otras interrupciones ejecutándose (por ejemplo, IDE, ethernet, etc.).
Y si eso aún no es suficiente, entonces tal vez su diseño de hardware es incorrecto. Algunas cosas son mejores en el hardware. Y cuando dije hardware, me refiero a ASIC, FPGA, procesador de red u otra lógica avanzada.
Si haces esa pregunta, entonces no deberías ir a la capa kernel. Básicamente, solo preguntarse significa que no es necesario. El momento del cambio de contexto es tan insignificante que no importa de todos modos en estos días.
Otra razón para no mover el código al espacio del kernel es que cuando lo utilice en situaciones comerciales o de producción, deberá publicar ese código debido al acuerdo GPL. Una situación en la que muchas compañías de software no quieren entrar. :)