Je ne crois pas avoir dit le contraire... mais l'UEFI ne va pas gérer la mémoire virtuelle de l'OS, ses IT, sa configuration cache et les finasseries pour maintenir sa cohérence très dépendantes de l'architecture.
Je dirais même que l'UEFI est une saloperie codé cochon, qui crée des dépendances évitables entre le boot loader et l'OS... avec pour résultat un code de démarrage en 3 phases quasi étanches (SEC/PEI/DXE), faisant intervenir jusque 3 origines de sources (RC/MRC, les réference code Intel source clos fournis uniquement aux éditeurs de BIOS/UEFI ; EDK2, implémentation de référence tirée encore par Intel ; Code glue/menu/log/selection boot device... historique de l'éditeur de BIOS).
Cad que le code commun se retrouve souvent avec 3(SEC/PEI/DXE)x3(sources code RC/EDK2/Editeur intégrant le patchwork)=9 duplicats...
Tout ce qu'on essaie d'ordinaire d'éviter. Avec au final un tas de m.... de l'ordre de grandeur du kernel linux en nb de lignes de code juste pour booter la machine, fournir qq services à l'OS (car microsoft n'a jamais su s'en passer, cf les ancêtres "interruptions" BIOS des boot services UEFI actuels), après avoir fait l'énumération PCI.
Et un truc plus long en temps (chargé d'une flash SPI) d'execution que le démarrage de l'OS complet derrière.
Pour fournir quoi d'utile? Un menu de config assez basique et un shell pas sans rappeler la boite DOS (en particulier les scripts, on revient au temps du .BAT): Un u-boot qu'on a longtemps fait tenir sur un secteur de 512k de flash NOR sur du powerPC est de ce point de vue mieux foutu que ces BIOS qui réclament une flash de 16MB (avec les firmwares en pagaille, autre spécificité Intel).
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par lym . En réponse à la dépêche Redox OS, le prochain système d’exploitation à conquérir le monde ?. Évalué à 5.
Je ne crois pas avoir dit le contraire... mais l'UEFI ne va pas gérer la mémoire virtuelle de l'OS, ses IT, sa configuration cache et les finasseries pour maintenir sa cohérence très dépendantes de l'architecture.
Je dirais même que l'UEFI est une saloperie codé cochon, qui crée des dépendances évitables entre le boot loader et l'OS... avec pour résultat un code de démarrage en 3 phases quasi étanches (SEC/PEI/DXE), faisant intervenir jusque 3 origines de sources (RC/MRC, les réference code Intel source clos fournis uniquement aux éditeurs de BIOS/UEFI ; EDK2, implémentation de référence tirée encore par Intel ; Code glue/menu/log/selection boot device... historique de l'éditeur de BIOS).
Cad que le code commun se retrouve souvent avec 3(SEC/PEI/DXE)x3(sources code RC/EDK2/Editeur intégrant le patchwork)=9 duplicats...
Tout ce qu'on essaie d'ordinaire d'éviter. Avec au final un tas de m.... de l'ordre de grandeur du kernel linux en nb de lignes de code juste pour booter la machine, fournir qq services à l'OS (car microsoft n'a jamais su s'en passer, cf les ancêtres "interruptions" BIOS des boot services UEFI actuels), après avoir fait l'énumération PCI.
Et un truc plus long en temps (chargé d'une flash SPI) d'execution que le démarrage de l'OS complet derrière.
Pour fournir quoi d'utile? Un menu de config assez basique et un shell pas sans rappeler la boite DOS (en particulier les scripts, on revient au temps du .BAT): Un u-boot qu'on a longtemps fait tenir sur un secteur de 512k de flash NOR sur du powerPC est de ce point de vue mieux foutu que ces BIOS qui réclament une flash de 16MB (avec les firmwares en pagaille, autre spécificité Intel).
Stp, ne me parles plus d'UEFI...