uefi, le standard merdique concu par intel et ms, avec des noms imbitables (UUID pour choisir le périph de boot, \ à la place de / comme séparateur, ...)
Si les UUID n'étaient là que pour identifier les périphs de boot, tout ne serait pas aussi pourri. Un disque ou un filesystem se prête bien à l'identification par UUID. Et les distributions GNU/Linux repèrent leur filesystem ainsi depuis un bout de temps.
En fait les UUID dans UEFI sont partout. Y compris pour la liaison dynamique des API en lieu et place de symboles. Y compris pour pas mal d'API au coeur d'UEFI.
C'est principalement relou parce que ça complique le reverse engineering. (Quoiqu'avec quelques scripts IDA bien placés, on doit pouvoir limiter la gène.)
Quant à ACPI, pas autant d'UUID, mais des symboles de 4 caractères, une syntaxe de langage source idiote, une sémantique super complexe, une inspiration venant tout droit de l'architecture de l'IBM PC original dans beaucoup de domaines, une norme qui maintenant fait quasiment 1000 pages et fait référence à des dizaines d'autres, une rétrocompatibilité qui remonte jusqu'à la nuit des temps tout en n'étant probablement pas effective et donc qui serait très avantageuse remplacé par du phase-out. Bref pas plus bandant qu'UEFI.
La plateforme PC est historiquement une horreur et c'est de pire en pire. Certes, ça marchote, mais à quel prix ? Si on veut une plateforme plus cohérente que l'écosystème actuel pour arm sous Linux, autant jeter UEFI et ACPI à la poubelle et choisir des choses moins absurdes. Enfin bon vu que tout le monde verrouille son bootloader et développe sa plateforme ARM comme un driver d'imprimante windows (gruik, fire and forget), j'ai du mal à voir comment ça pourrait arriver. Il faudrait qu'un core kernel hackeur tape une crise et impose de la propreté. (Malheureusement vu que Linus surkif le fait que tous les constructeurs mettent des DRM partout sur leur matos, on risque d'être durablement dans la merde)
[^] # Re: Windows 8 sur ARM : pas étonnant
Posté par Guillaume Knispel . En réponse à la dépêche Vente liée: un pas en avant, un pas en arrière.... Évalué à 3. Dernière modification le 12 février 2012 à 16:24.
Si les UUID n'étaient là que pour identifier les périphs de boot, tout ne serait pas aussi pourri. Un disque ou un filesystem se prête bien à l'identification par UUID. Et les distributions GNU/Linux repèrent leur filesystem ainsi depuis un bout de temps.
En fait les UUID dans UEFI sont partout. Y compris pour la liaison dynamique des API en lieu et place de symboles. Y compris pour pas mal d'API au coeur d'UEFI.
C'est principalement relou parce que ça complique le reverse engineering. (Quoiqu'avec quelques scripts IDA bien placés, on doit pouvoir limiter la gène.)
Quant à ACPI, pas autant d'UUID, mais des symboles de 4 caractères, une syntaxe de langage source idiote, une sémantique super complexe, une inspiration venant tout droit de l'architecture de l'IBM PC original dans beaucoup de domaines, une norme qui maintenant fait quasiment 1000 pages et fait référence à des dizaines d'autres, une rétrocompatibilité qui remonte jusqu'à la nuit des temps tout en n'étant probablement pas effective et donc qui serait très avantageuse remplacé par du phase-out. Bref pas plus bandant qu'UEFI.
La plateforme PC est historiquement une horreur et c'est de pire en pire. Certes, ça marchote, mais à quel prix ? Si on veut une plateforme plus cohérente que l'écosystème actuel pour arm sous Linux, autant jeter UEFI et ACPI à la poubelle et choisir des choses moins absurdes. Enfin bon vu que tout le monde verrouille son bootloader et développe sa plateforme ARM comme un driver d'imprimante windows (gruik, fire and forget), j'ai du mal à voir comment ça pourrait arriver. Il faudrait qu'un core kernel hackeur tape une crise et impose de la propreté. (Malheureusement vu que Linus surkif le fait que tous les constructeurs mettent des DRM partout sur leur matos, on risque d'être durablement dans la merde)