The Extensible Firmware Interface - an introduction

Posted Aug 22, 2011 22:37 UTC (Mon) by marcH (subscriber, #57642)
In reply to: The Extensible Firmware Interface - an introduction by mjg59
Parent article: The Extensible Firmware Interface - an introduction

I think this is exactly the limitation that etienne is trying to demonstrate.

However I still do not really see how this is a limitation *in practice*.

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 9:56 UTC (Tue) by etienne (guest, #25256) [Link] (2 responses)

> However I still do not really see how this is a limitation *in practice*.

Lets take a real life example: the situation right now is that the first sector of the first disk is loaded, after that the ROM BIOS hopes for the best after jumping to the first instruction of the MBR.
The "first disk" is where the BIOS can be a bit configured, there is most of the time a boot menu where you can select what the "first disk" is, and if the first disk is not readable (disk broken or any other reason), then the next disk is tried.
Something nobody planned 30 years ago happens: disk sector sizes are going to increase from 512 to 4096 bytes per sector.
With current systems you hopefully will still have the first sector loaded (for any sector size one can imagine) and one can hope that at least the first 512 bytes are correctly loaded, and it should be sufficient for the bootloader to manage the situation (I tried to make that possible with Gujin, but cannot test because those disks are still under NDA).
Now, I believe EFI will handle 512 and 4096 bytes/sector at the SATA interface, but in few years there may be something else - and because EFI is IHMO too "intelligent", to boot you will not just need to upgrade a package in your distribution, but you will need to upgrade your BIOS.

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 10:50 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)

I miss how this is an answer to the previous question in the thread but anyway:

> ..., but you will need to upgrade your BIOS.

And? I have actually solved real boot problems (USB-ZIP/FDD/HDD, PXE,...) by upgrading BIOSes, this is not a pie in the sky. Note that, from the vendor's perspective it will be much cheaper to develop an upgrade in C (EFI) as opposed to assembly (BIOS).

If your PC is too old for maintenance then you will do what most people do in such cases: you will buy a new PC with an updated EFI/BIOS/whatever. Consider this very similar case: how many people actually try to shoehorn a brand new & big SATA drive into an old & slow pre-SATA PC? Practically none.

Working on a Windows 7 PC right now I often envy Apple, am tired of backward-compatibility and wish it were much more often thrown out of the window...

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 13:20 UTC (Tue) by etienne (guest, #25256) [Link]

I think we can agree to disagree on that one:
- for me, if it is possible to do in hardware, Linux should try to support it in software (because we do not know what will be the future).
- for you, if the number of people doing strange things is statistically insufficient, there is no point in trying to support it (because anyway we will have new PC including the evolution if it is good enough).

I would agree with you saying the world would be a simpler place if we did not have all those "strange" configurations to support, if the users would use their computer and OS for what it was designed for.