Pregunta de arranque del sistema operativo básico

Question

Tengo alguna pregunta un poco básica para el proceso de arranque de una computadora y la parte donde el gestor de arranque llama al sistema operativo.

Así que sé que el BIOS copia los primeros 512 bytes de una unidad de arranque en la memoria y ejecuta el código, así que ese es el bloque de arranque.

• Pero, ¿cómo hace ese pequeño ensamblador para iniciar bootloader los comandos del sistema operativo?
• ¿El cargador de arranque continúa en ejecución y aún actúa como un "transmisor" entre el software y el hardware? ¿O el control está completamente dado al sistema operativo?
• ¿Por qué todos los cargadores de arranque están escritos en ensamblador?
• ¿Y por qué tiene que volver de C++ a C cuando escribe un sistema operativo?

Saludos, lamas

Answer 1

1) El gestor de arranque normalmente contiene unas sencillas instrucciones para cargar aún más los datos del disco y para ejecutarlo.

2) No,

3) Para reducir al mínimo el espacio que ocupan.

4) No es así.

Answer 2

Pero, ¿cómo hace ese pequeño ensamblador para iniciar bootloader los comandos del sistema operativo?

Como no se puede hacer mucho en 512 bytes de código (aunque, de hecho, un gestor de arranque no es estrictamente limitada a 512 bytes), un gestor de arranque sería por lo general no mucho más que cargar un bloque más grande del código de un disco en la RAM y luego ejecutarlo.

¿El gestor de arranque continúe funcionando y todavía actúa como un "transmisor" entre el software y el hardware? ¿O el control está completamente dado al sistema operativo?

creo que una vez que el código del gestor de arranque ha hecho su trabajo, y saltó al código adicional que se ha cargado en la memoria, que puede entonces ser anulado, puesto que ya no es necesario.

¿Por qué todos los cargadores de arranque están escritos en ensamblador?

supongo que esto es principalmente por una razón: Si se escribe un cargador de arranque en un lenguaje de alto nivel, el código producido muy probablemente se basaría en una especie de biblioteca de tiempo de ejecución, que contiene las funciones esenciales. Esos, sin embargo, a menudo no son necesarios para un gestor de arranque, y por lo tanto, inflarían el tamaño del código.

Y ¿por qué tiene que volver a partir de C++ a C al escribir un sistema operativo?

No es estrictamente necesario. Es solo que el código C está más cerca de la máquina que C++. Con C++ no siempre se puede adivinar qué código se producirá y si será tan eficiente como se desee.

Edité: También he escuchado el argumento de que algunos desarrolladores de sistemas operativos se adhieren al lenguaje C porque hay menos opciones en diferentes paradigmas de programación y estilos que p. Ej. en C++. Por lo tanto, es más fácil trabajar para un equipo con la base de código común, ya que todos escribirán un código más "similar". (Dado que no he estado involucrado en ningún desarrollo de código abierto o sistema operativo, no puedo juzgar por la experiencia si esta es una declaración válida o no).

Answer 3

Para responder a su última pregunta: Los kernels no necesitan estar escrito en C. Pero hace que sea mucho más fácil a la hora de tratar de asignar memoria.

C++ tiene muchos casos diferentes en los que puede obtener memoria asignada implícitamente para variables temporales, etc., que no siempre son evidentes en la inspección del código. Esto hace que escribir un kernel sea más difícil, ya que debe evitar asignar memoria en algunos contextos.

Sin embargo, no impide por completo escribir un kernel en C++. Hay formas de evitar esto

Answer 4

El cargador de bootstrap carga el sistema operativo desde el disco.

Es por eso que se llama cargador de arranque: se levanta en las correas de arranque cargando el sistema operativo del disco desde el disco antes de que haya ningún sistema operativo de disco para cargar nada desde el disco.

Cuando se carga el sistema operativo, toma el control y el cargador se descarta.

Un cargador bootstrap generalmente se escribe en ensamblador porque es un buen equilibrio entre el control total y la legibilidad. Podría escribirse en código de máquina simple (y probablemente los primeros sí) pero es más difícil de leer. Se podría escribir en un lenguaje de bajo nivel como C, pero es difícil llegar a las rutinas de bajo nivel en el BIOS que necesita para realizar la carga, y también es difícil mantenerlo dentro de las restricciones de tamaño ya que el código compilado tiende a tener una mucha sobrecarga

Un sistema operativo generalmente se escribe en un lenguaje de bajo nivel como C (con elementos como cargadores de arranque y controladores de hardware todavía en ensamblador). Podrías escribirlo en C++ ya que se basa en C, pero eso sería en gran medida inútil ya que no usarías mucho de lo que C++ agregó. La orientación a objetos simplemente no es muy útil cuando se escribe un sistema operativo.

Answer 5

• Pero, ¿cómo hace ese pequeño ensamblador para iniciar bootloader los comandos del sistema operativo?

Sí, el gestor de arranque es pequeño, pero el BIOS no está e implementa .. siempre ha implementado .. el DOS de E/S "llamadas al sistema". Este sistema de E/S originalmente ejecutó todo el sistema de E/S del sistema operativo en el DOS y los primeros días de Windows. Ahora solo es una consola responsable de cargar el SO real que luego suministra todos sus propios controladores. Es una especie de dispositivo-controlador-biblioteca y original-IBM-PC-emulador para el cargador de arranque.

• ¿El cargador de arranque continúa funcionando y aún actúa como un "transmisor" entre el software y el hardware? ¿O el control está completamente dado al sistema operativo?

El gestor de arranque es tierno una vez que se está ejecutando el sistema operativo. Sin embargo, esta es una buena pregunta, porque en el concepto original de PC, el BIOS realizaba E/S para el sistema operativo así como para el gestor de arranque, por lo que una parte del sistema sobrevivió al cargar el sistema operativo.

• ¿Por qué están todos los cargadores de arranque escritos en ensamblador?

varias razones: fixed-address que necesitan para ser pequeño, que han restricciones de distribución, que tienen que hacer int llamadas del BIOS $ x estilo, y teniendo en cuenta su tamaño y el hecho de que algunos de ellos deben estar en Ensamblaje, no hay mucho que ganar al tomar 128 o más bytes y decir "ok, esta parte puede escribir en C, trate de no escribir más de 10 o más declaraciones".

• ¿Y por qué tiene que volver de C++ a C cuando escribe un sistema operativo?

C++ está bien hoy; Cuando los granos grandes de hoy comenzaron, las cosas eran diferentes.

Answer 6

Hay un punto importante que falta en toda la respuesta de por qué está escrito en el montaje: porque:

a. MMU todavía no está configurado,

b. no hay un proceso de cargador en ejecución para cargar los archivos binarios compilados, ya que la región de la memoria no es homogénea, algunas partes están cableadas para fines de DMA/BIO, etc., por lo que se necesitan muchos trabajos de reasignación.

Así que cuando lo escribe en conjunto, debe especificar explícitamente todas las ubicaciones de su memoria: dónde se encuentran los datos, dónde se encuentra el ejecutable, etc., y asegurarse de que estas restricciones no estén en conflicto.

Si escribe en C, gcc lo compilará en un formato estándar ABI, y hay un cargador preexistente (puede ser solo una biblioteca) para cargar el binario en la memoria. Dado que, por lo general, la memoria utilizada en binario es superior a la disponible en la memoria física, y ciertas partes de la memoria están reservadas para usos de hardware (plataforma/hardware específico), MMU es importante configurarlo antes de cargar estos binarios.

ELF carga es sólo un aspecto de la complejidad:

http://wiki.osdev.org/ELF#Loading_ELF_Binaries

Pero no hacerlo existe distribución como uClinux, que eliminan la necesidad de MMU a ser instalado:

http://www.uclinux.org/

Alguien tiene que enseñarme más sobre eso .....