¿Por qué necesitamos un gestor de arranque?

¿Por qué necesitamos un gestor de arranque?

Después de iniciar el BIOS, o algo similar que sirva como firmware, hasta donde yo sé, el control pasa al gestor de arranque.

¿Por qué el BIOS no puede cargar el kernel del sistema operativo directamente?

Además, el manual de GRUB dice:Brevemente, un cargador de arranque es el primer programa de software que se ejecuta cuando se inicia una computadora.. ¿No es el BIOS el primer programa que se ejecuta?

Respuesta1

Un BIOS necesitaría saber cómo cargar un kernel, y esto haría que el BIOS fuera demasiado complicado: imagine un BIOS que necesita saber cómo cargar los diferentes sistemas operativos disponibles, cómo pasarles parámetros del kernel, etc.

Por lo tanto, sólo inicializa el hardware y salta a un lugar conocido donde está almacenado el gestor de arranque; luego, se le pasa el control.

DeLos fundamentos de Unix e Internet:

Quizás se pregunte por qué el BIOS no carga el kernel directamente; ¿por qué el proceso de dos pasos con el cargador de arranque? Bueno, el BIOS no es muy inteligente. De hecho, es muy estúpido y Linux no lo usa en absoluto después del arranque. Fue escrito originalmente para PC primitivas de 8 bits con discos pequeños y, literalmente, no puede acceder a una cantidad suficiente del disco para cargar el kernel directamente. El paso del cargador de arranque también le permite iniciar uno de varios sistemas operativos desde diferentes lugares de su disco, en el improbable caso de que Unix no sea lo suficientemente bueno para usted.

En cuanto a que el BIOS sea el primer programa que se ejecuta: (deWikipedia)

El software BIOS está integrado en la PC y es el primer código que ejecuta una PC cuando se enciende ("firmware de arranque").

Pero un firmwareessoftware. Así que supongo que el manual de GRUB es al menos confuso en esa parte; el gestor de arranque puede verse como el primerousuario definidopieza de software que se ejecuta en la computadora.

Respuesta2

La razón es la flexibilidad. Es posible que tenga varios sistemas operativos diferentes en un disco duro (Windows, Linux, etc.) o que tenga varias versiones diferentes del mismo sistema operativo. Por lo tanto, es mejor tener un fragmento de código independiente del sistema operativo que sepa dónde reside cada sistema operativo instalado en el disco duro, cómo cargar cada uno de ellos, cuál cargar, si presentar un menú o no, etc. un gestor de arranque.

BIOS carga y ejecuta código ubicado en una ubicación predefinida en un disco duro (primer sector). A este código lo llamamos cargador de arranque, pero técnicamente, si instaló Windows en un disco duro en blanco, Windows también instala este código, por lo que puede llamarlo parte de Windows, especialmente porque el cargador de arranque de Windows no puede cargar ningún otro sistema operativo además de Windows.

Con respecto al primer programa de software que se ejecuta cuando se inicia una computadora: la distinción entre firmware y software es bastante escasa y el proceso de inicio de la computadora moderna es muy complicado. BIOS en sí mismo tampoco es un programa monolítico, sino varias etapas distintas encadenadas. Sin embargo, el gestor de arranque es el primero.modificable por el usuariocódigo que se ejecuta. Esta es la primera pieza de código que el usuario puede dañar, borrar, infectar con un virus, etc. Así que supongo que, aunque técnicamente BIOS es el primer software que se ejecuta, el gestor de arranque es el primero en el sentido de que si la computadora no arranca, el usuario necesita para comprobar si está bien.

Respuesta3

¿Por qué el BIOS no puede cargar el kernel del sistema operativo directamente?

Tres razones:

  • El BIOS en la plataforma de PC original cuando se introdujo en 1981 estaba destinado a funcionar en la misma función que en el sistema operativo CP/M: es decir, una fina capa de abstracción para un par de dispositivos y un simple gestor de arranque de disco. CP/M tenía otra capa llamada "BDOS" que manejaba el sistema de archivos. DOS era similar a CP/M en muchos aspectos, ya que era el sistema operativo de moda en ese momento y estaba estructurado de manera similar. La BIOS estaba destinada a manejar aspectos específicos del hardware de la plataforma, una función que cumplen ahora los controladores en los sistemas operativos.

  • La noción de un sistema de archivos separado del sistema operativo aún no se ha arraigado.

  • En esta época, la RAM y la ROM eran recursos caros y escasos. La PC IBM 5150 original se podía obtener con tan solo 16 KB de RAM (referencia). El tamaño de ROM de este sistema era de 48K y incluía un intérprete BÁSICO. En aquella época tampoco existía un sistema de archivos estándar.

Dado que DOS creció hasta convertirse en el sistema operativo más popular para esta plataforma, y ​​posteriormente Windows, que funcionaba con esta configuración, nadie pensó en ampliar el BIOS de esta manera para incluir una capacidad real de carga de arranque.

No estoy seguro de las capacidades de UEFI: es posible que tenga una capacidad de carga de arranque real que Windows no utiliza por una razón u otra (Windows insiste en usar su propio administrador de arranque cuando lo instala). Otros firmware que no son de BIOS, como U-Boot y los de muchos teléfonos y enrutadores, cargan y ejecutan kernels directamente. No ha habido una razón técnica para esto desde que las BIOS comenzaron a tener espacio en la ROM para hacer más cosas.

información relacionada