L'avvio è difficile
L'avvio ... beh ... è davvero la parte più difficile. Ogni volta che un computer si avvia sostanzialmente si incontra di nuovo. Si acquisisce con le sue varie parti, e per ognuna incontra si guadagna capacità. Ma deve tirarsi su dai propri bootstrap, per così dire, da quello quadrato ogni volta.
Quando si progetta un processo di avvio, il trucco è portare la macchina in più fasi. Il tuo avvio deve essere veloce e affidabile e ogni volta deve trovarsi in un ambiente completamente sconosciuto . Non mi avventurerò nemmeno in una conversazione in modalità reale / protetta (il che non vuol dire che potrei anche) , ma c'è molto da fare all'avvio. Mentre il computer assimila i suoi vari componenti ogni volta che lo fa in passaggi graduali. Probabilmente il più cruciale di questi è il passaggio dall'esecuzione del codice integrato all'esecuzione del codice su disco o, in altre parole, dall'esecutivo del kernel. Questo è quando il firmware (apparentemente) si arrende al sistema operativo.
Molti anni fa non era così. In passato il BIOS era davvero il Basic In / Out - i programmi regolari effettuavano chiamate al firmware per cose come disegnare lo schermo e accedere al disco. Questi erano chiamati interruzioni : i vecchi cappelli potevano ricordarli meglio per il brivido di gioia che spesso trovavano nell'assegnare IRQ per la loro nuova matrice di punti o USR.
INT13h
È la serie di funzioni 13H di interrupt ( o INTnel linguaggio in assembly ) che il BIOS offre come servizi per l'accesso al disco. Questi sono ancora utilizzati ancora oggi per i sistemi BIOS nel processo di avvio per passare dal firmware al disco.
Un sistema BIOS controlla i primi byte di ciascun disco che trova e cerca un modello che riconosce come Master Boot Record ( oMBR ) . Questo è uno standard de facto vecchio di decenni e include un po 'di binario eseguibile non elaborato che è scritto sulla testa del disco. L'MBR contrassegna un disco BIOS come avviabile. Smetterà di controllare quando ne trova uno, e così praticamente uno è tutto ciò che ottieni senza un inganno intelligente. Quando ne trova uno, lo mappa in memoria ed lo esegue (in modalità Reale, ma non ci vado ancora) .
L'MBR eseguito non è quasi sicuramente il kernel di sistema - 512 byte (dare o avere) sarebbero abbastanza inutili in quel reparto. Questo è probabilmente un bootloader - un programma progettato specificamente per superare una delle molte limitazioni di indirizzamento del BIOS - in particolare che non comprende affatto alcun tipo di file system.
Quando il bootloader legge nel kernel attuale e lo esegue è nella memoria (come tutti noi pregare lo farà ogni volta) , sarà probabilmente farlo chiedendo il BIOS tramite una INT13Hchiamata di interrupt. E se non lo fa - molti bootloader più elaborati monteranno i file system in senso convenzionale ed eseguiranno il codice in un altro modo - allora è molto poco probabile che il bootloader sia così sofisticato senza uno INT13Ho due. Spesso i bootloader devono caricare a catena se stessi - o varie fasi di se stessi - perché i 512 byte inizialmente allocati non soddisfano nemmeno le loro esigenze.
POLLO E UOVA
Tutto questo è un modo indiretto di discutere del disco, lo so, ma a questo punto dovrebbe essere abbondantemente chiaro che il problema principale - si potrebbe chiamarlo un tipo di gallina e uovo - sta accedendo al disco che contiene le istruzioni del programma su come accedere ai dischi . La chiave di questo problema è il firmware - e continua ad essere in modi molto diversi anche sui sistemi EFI - e, il più debole o no, il firmware è l'anello più importante nella catena di avvio.
Vedete, una volta eseguito il kernel, e tutte le sue miriadi di routine per l'accesso e il controllo dell'hardware avviato, tutti questi problemi scompaiono (o almeno cambiano in qualche modo) , perché i moderni sistemi operativi assumono il pieno controllo di un sistema, ma fino a quando non lo faranno i limiti del sistema si estenderanno solo nella misura consentita dal firmware. Questo dice molto: il BIOS non è cambiato molto INT13Hdall'8086. La chiamata è un originale 8086. Sì, ci sono state (una miriade) estensioni e hack ovviamente, ma innovazioni ...?
DI MEGLIO IN MEGLIO
La maggior parte delle modifiche al BIOS sono state semplicemente delle bende. In passato era un hard disk che doveva essere mappato fisicamente - vari aspetti specifici della sua geometria venivano indicati quando i dati venivano archiviati o recuperati da esso. Alla fine il disco rigido convenzionale è cresciuto fino a raggiungere una dimensione tale da proibirlo. Anche solo la mappa astratta era troppa informazione per un BIOS da gestire. Poiché può funzionare solo in modalità reale, il BIOS è limitato a 1 MB per registro di memoria. Gonfia la mappa del cilindro più grande di quella, o ingrandisci una delle sue proprietà di quante possano essere affrontate in così tanti bit, e il BIOS è letteralmente perso - fuori dai limiti.
Questa barriera è stata superata e superata molte volte. Ogni volta che la mappa viene astratta e codificata in un modo più nuovo, intelligente e meno preciso. E così in questi giorni è letteralmente impossibile per un BIOS mappare con precisione un'unità. Logical Block Addressing è di fatto lo standard di fatto, sebbene siano ancora necessarie alcune traduzioni di cilindri / testate / settori (o CHS) . Ciò che il firmware della scheda madre ha perso in termini di accuratezza / responsabilità, tali estensioni sono state astratte e aggiunte alle responsabilità del firmware del disco per colmare le lacune.
È questo gioco gatto e topo a cui fa riferimento la tua domanda. Quando il BIOS non riesce a capire un disco oltre un certo punto a causa delle sue dimensioni, allora tutti i dati che potresti voler recuperare all'avvio - come un bootloader o un kernel - probabilmente farebbero meglio a non trovarsi oltre quel punto. Questo è da dove /bootviene.
FORSE REALMENTE MEGLIO
In questi giorni, per fortuna, queste cose sono rese irrilevanti dalla fine del BIOS. Sono passati 30 anni, ma è stato ampiamente sostituito negli ultimi anni dallo standard UEFI (o EFI 2.0) . UEFI fornisce un mount dal primo minuto, si inizializza in modalità protetta, incorpora il proprio bootloader, fornisce archiviazione variabile con memoria flash persistente al riavvio, è specificato per gestire alcuni ennesimi zetabyte o qualunque cosa per disco ... e molto altro altro. È tutt'altro che perfetto, ma è un grande miglioramento rispetto al suo predecessore.
Anche gli argomenti per bootloader specializzati che coinvolgono la crittografia del disco o i file system a livelli falliscono se si considera che tutti questi devono essere comunque gestiti dal kernel del sistema operativo e se viene fornito un mount all'avvio, si ha sempre un chiaro- sparato per eseguirlo (soprattutto considerando che il kernel Linux, nella sua configurazione predefinita, è un eseguibile EFI tutto suo) .
Quindi una /bootpartizione separata probabilmente non dovrebbe preoccuparti eccessivamente e, se ti trovi in un sistema EFI, probabilmente avrai già un analogo nella partizione del sistema EFI, poiché questo è un requisito per l'avvio della modalità EFI.