¿El kernel de Linux necesita un sistema de archivos para ejecutarse?

Mi opinión es que sí, porque toda exposición útil al mundo exterior (modo de procesador no privilegiado) requeriría primero un proceso que se ejecute en el mundo exterior. Eso requeriría un sistema de archivos, incluso un sistema de archivos temporal en RAM.

Otro ingeniero no está de acuerdo conmigo, pero parece que no puedo probar esto más allá de todos los casos (desconocidos para mí).

¿La respuesta a esta pregunta depende de la definición de 'correr'?

Esa es una pregunta bastante extraña porque no ejecuta el núcleo como ejecuta un programa. El kernel es una plataforma para ejecutar programas. Por supuesto, hay un código de configuración y apagado, pero no es posible ejecutar el núcleo por sí solo. Siempre debe haber un proceso "init" principal. Y el núcleo entrará en pánico si no está allí. Si init intenta salir del kernel, también entrará en pánico.

En estos días, el proceso de inicio es algo así como systemd. Si no se especifica lo contrario, el núcleo intentará ejecutar un programa desde una lista de ubicaciones que comiencen con /sbin/init. Vea el parámetro de inicio aquí http://man7.org/linux/man-pages/man7/bootparam.7.html en una emergencia con la que puede arrancar Linux init=/bin/bash. Pero observe cómo siempre especifica un archivo en el sistema de archivos para ejecutar.

Por lo tanto, el núcleo entrará en pánico si se inicia y no tiene un sistema de archivos porque sin uno no hay forma de cargar init.

Puede surgir cierta confusión debido a una situación de huevo y gallina donde el núcleo debe cargar los controladores para acceder a su sistema de archivos. Para evitar esto, se carga un ramdisk inicial desde una imagen en el disco que contiene controladores vitales y scripts de configuración. Estos se ejecutan antes de cargar el sistema de archivos. Pero no se equivoque, el ramdisk inicial es en sí mismo un sistema de archivos. Con un disco RAM inicial /initse llama (que se almacena en el disco RAM inicial). En muchas distribuciones, en última instancia, esto es lo que llama /sbin/init. Nuevamente sin un sistema de archivos, esto es imposible.

La respuesta dependerá de si quiere decir, literalmente, sin un sistema de archivos o si la pregunta está destinada a ser interpretada de manera un poco diferente de cómo se formula realmente. Las respuestas para pequeñas variaciones en cómo se interpreta la pregunta son:

• Ejecutar Linux sin ningún dispositivo de bloque es completamente factible y útil para algunos casos de uso especializados.
• Ejecutar Linux sin ningún sistema de archivos requerirá reescribir algunas partes del código del núcleo y es poco probable que sea un esfuerzo útil.
• Ejecutar Linux sin usar ningún descriptor de archivo requerirá mucho esfuerzo. Estoy bastante seguro de que no valdrá la pena el esfuerzo.

Las razones por las que tendría que reescribir partes del código del núcleo para hacer que un sistema funcione sin un sistema de archivos son:

• Cada hilo tiene un directorio raíz y un directorio de trabajo actual que debe apuntar a algún sistema de archivos.
• Los programas se inician mediante la execvellamada al sistema que necesita un ejecutable desde un sistema de archivos.
• El kernel crea un sistema de archivos basado en memoria durante el proceso de arranque.

Después de que un programa se haya comenzado a usar execve, es posible que desasigne el ejecutable desde el que se inició, aunque para hacerlo sin que se bloquee de inmediato, primero debe crear una asignación de memoria ejecutable que no esté respaldada por un archivo, y tiene que inicializar eso con algún código útil antes de saltar a él y desasignar el ejecutable.

Por lo tanto, un programa en modo de usuario en ejecución puede existir en un estado en el que no tiene asignaciones de memoria respaldadas por archivos y puede cerrar todos los descriptores de archivos respaldados por archivos. No puede dejar de tener un directorio raíz y un directorio de trabajo actual, pero puede abstenerse de ellos.

Entonces, aunque en este estado podría implementar el código del núcleo para extraer el sistema de archivos del programa y hacer que siga ejecutándose, no parece que sea útil. Y entrar en ese estado final sin pasar por un estado intermedio de uso de un sistema de archivos va a ser aún más trabajo sin beneficio útil.

Una configuración útil para algunos casos de uso especializados.

Evitar el uso de dispositivos de bloque puede ser útil. Durante el arranque, el kernel crea un sistema de archivos de memoria, y también puede llenar ese sistema de archivos con contenido de un cpioarchivo antes de ejecutarlo init. De esa manera, puede ejecutar un sistema completamente desde un sistema de archivos basado en memoria sin ningún dispositivo de bloque que lo respalde.

Esto puede ser útil para sistemas en los que no desea conservar ningún estado y desea que el sistema comience desde cero cuando se reinicia.

Por supuesto, el kernel y el archivo cpio tienen que existir de alguna manera en la memoria antes de que el kernel tenga el control. Cómo llegaron allí es un trabajo para el gestor de arranque. El cargador de arranque podría haber cargado los de un dispositivo de bloque a pesar de que el sistema de ejecución final no utiliza dispositivos de bloque. Pero también es posible que el gestor de arranque adquiera el núcleo y el archivo cpio sin utilizar un dispositivo de bloque, por ejemplo, iniciando a través de la red.

En Linux, casi todos los dispositivos son un archivo , por lo que debe tener un sistema de archivos para ejecutarlo.

Un kernel ES un programa, como cualquier otro. De forma predeterminada, el kernel de Linux intenta acceder al sistema de archivos, sin embargo, este comportamiento puede eliminarse trivialmente mediante la modificación del kernel (en realidad, solo una adición de una función "arch_call_rest_init ()"). Para realizar un "trabajo útil", entonces esperamos que el desarrollador pueda incluir hilos de kernel (kthreads), perhapos en un controlador personalizado, para realizar la inicialización deseada y la carga de trabajo del tipo de aplicación. El kernel de Linux ya contiene muchos kthreads, pero principalmente para realizar un trabajo auxiliar al kernel o los controladores. Las API disponibles en el contexto del núcleo son bastante diferentes de las disponibles en el espacio de usuario de Linux. Una gran fracción de la funcionalidad de llamada del sistema se volvería inútil en un escenario sin sistema de archivos.

Sí, Linux espera acceso a los sistemas de archivos de forma predeterminada. No, un kernel modificado ciertamente podría hacerse para realizar un trabajo útil sin ningún sistema de archivos. El uso práctico de Linux sin sistema de archivos es IMO bastante limitado, pero no nulo. FWIW, en el pasado muchos núcleos en tiempo real se integraron en el mismo espacio de nombres y binario que las aplicaciones RT.