Por que precisamos de um carregador de inicialização?

Depois que o BIOS, ou algo semelhante que serve como firmware, é iniciado, o controle é passado para o gerenciador de inicialização, tanto quanto eu sei.

Por que o BIOS não pode carregar o kernel do SO diretamente?

Além disso, o manual do GRUB diz: brevemente, um carregador de inicialização é o primeiro programa de software que é executado quando o computador é iniciado . O BIOS não é o primeiro programa executado?

Um BIOS precisaria saber como carregar um kernel, e isso tornaria o BIOS muito complicado: imagine um BIOS que precise saber como carregar os diversos sistemas operacionais disponíveis, como passar parâmetros do kernel para eles, etc.

Assim, ele apenas inicializa o hardware e salta para um local conhecido onde o gerenciador de inicialização está armazenado; então, o controle é passado para ele.

De O Unix e Internet Fundamentos COMO FAZER :

Você pode se perguntar por que o BIOS não carrega o kernel diretamente - por que o processo de duas etapas com o carregador de inicialização? Bem, o BIOS não é muito inteligente. Na verdade, é muito estúpido, e o Linux não o usa após o tempo de inicialização. Foi originalmente escrito para PCs de 8 bits primitivos com pequenos discos e literalmente não pode acessar o suficiente do disco para carregar o kernel diretamente. A etapa do carregador de inicialização também permite iniciar um dos vários sistemas operacionais em locais diferentes do disco, no improvável evento em que o Unix não seja bom o suficiente para você.

Quanto ao BIOS ser o primeiro programa executado: (da Wikipedia )

O software BIOS está embutido no PC e é o primeiro código executado por um PC quando ligado ('firmware de inicialização').

Mas um firmware é um software. Então, eu assumiria que o manual do GRUB é pelo menos confuso nessa parte; o gerenciador de inicialização pode ser visto como o primeiro software definido pelo usuário que é executado no computador.

O motivo é a flexibilidade. Você pode ter vários sistemas operacionais diferentes em um disco rígido (Windows, Linux etc.) ou várias versões diferentes do mesmo sistema operacional. Portanto, é melhor ter um trecho de código independente do SO que saiba onde reside cada SO instalado no disco rígido, como carregar cada um deles, qual carregar, se deve apresentar um menu ou não, etc. um carregador de inicialização.

O BIOS carrega e executa o código localizado em um local predefinido em um disco rígido (primeiro setor). Chamamos esse código de carregador de inicialização, mas tecnicamente, se você instalou o Windows em um disco rígido vazio, esse código também é instalado pelo Windows, para que você possa chamá-lo de parte do Windows, especialmente porque o carregador de inicialização do Windows não pode carregar nenhum outro SO além do Windows.

Em relação ao primeiro programa de software que é executado quando um computador é iniciado: a distinção entre firmware / software é muito pequena e o processo de inicialização do computador moderno é muito complicado. O BIOS em si também não é um programa monolítico, mas vários estágios distintos encadeados. No entanto, o gerenciador de inicialização é o primeiro código que pode ser alterado pelo usuário . Este é o primeiro código que o usuário pode danificar, apagar, infectar com um vírus, etc. Então, suponho que, tecnicamente, o BIOS seja o primeiro software executado, o gerenciador de inicialização seja o primeiro, no sentido de que, se o computador não inicializar, o usuário precisará para verificar se está ok.

Por que o BIOS não pode carregar o kernel do SO diretamente?

Três razões:

• O BIOS na plataforma original do PC, quando foi lançado em 1981, deveria funcionar com a mesma função do sistema operacional CP / M - a saber, uma fina camada de abstração para alguns dispositivos e um simples carregador de disco. O CP / M tinha outra camada chamada "BDOS", que tratava do sistema de arquivos. O DOS era semelhante ao CP / M em muitos aspectos, pois era o sistema operacional em voga na época e era estruturado da mesma forma. O BIOS foi projetado para lidar com aspectos específicos da plataforma, uma função que os drivers nos sistemas operacionais cumprem agora.

• A noção de um sistema de arquivos separado do sistema operacional ainda não se concretizou.

• Nesse momento, RAM e ROM eram recursos caros e escassos. O IBM 5150 PC original pode ser obtido com apenas 16 K de RAM ( referência ). O tamanho da ROM deste sistema era 48K e isso incluía um intérprete BASIC. Também não havia um sistema de arquivos padrão na época.

Desde que o DOS cresceu e se tornou o sistema operacional mais popular para esta plataforma, e o Windows posteriormente, que funcionava com essa configuração, ninguém pensou em estender o BIOS dessa maneira para incluir a capacidade real de carregamento de inicialização.

Não tenho certeza dos recursos do UEFI - ele pode ter um recurso real de carregamento de inicialização que não é usado pelo Windows por um motivo ou outro (o Windows insiste em usar seu próprio gerenciador de inicialização quando você o instala). Outros firmwares que não são do BIOS, como o U-Boot e os de muitos telefones e roteadores, carregam e executam kernels diretamente. Não existe uma razão técnica para isso desde quando os BIOSs começaram a ter espaço na ROM para fazer mais coisas.