bzt wrote:We have a saying "You don't see the forest 'cos you are standing to close to a tree". First of all, almost all of you mix up BASIC with FULL support. You also should think about what's the difference between "standard firmware interface" and "standard OS interface". First would be beneficial for all OSes (hobby and mainstream as well), while the latter only for one specific OS' drivers.
@zaval: UEFI is over-complicated for only booting an OS. The truth is, 90% of it's library and complexity is not needed for that. If they were planning only for booting an OS, they should have designed a much more simpler and more sophisticated interface. And it's a common criticism, not just my opinion (Linus would agree too). My argument here is that while you can use BIOS VESA and disk interrupt in runtime, you can't use GOP. (And for god's sake, let's forget about real-mode, that's not the point here! It's just an ABI detail in this case. There is a way to change resolution (regardless to video card) and read/write disk (regardless of it's controller) from your OS with BIOS, while under EFI there's no way at all, you MUST implement native drivers and have all of them loaded at boot time, no fallback possible).
No, not overcomplicated at all. Booting from everywhere one could imagine is not just quick and dirty MBR code jumping. Basically, the broader the range of boot possibilities an implementer wants, the more he needs to implement. The required bare minimum, is not that "complicated". But to see that, one needs to dig into it deeper than just referencing Linus, who dislikes everything outside linux, and thus - whose criticism only invokes a desire to say: What a big deal.
A modern OS could benefit a lot from BlockIO and GOP and the others. I agree with mallard. Also, using firmware's interface for the device under "boot" mount is not only reasonable but desirable as it removes a couple OS layers and driver code. Nobody cares if reading/writing the /boot partition is slow, reliability is more important. Also BlockIO would be great to save a freshly downloaded SCSI driver to a SCSI disk for example. The same applies for network cards and all other devices. In lack of native driver that FULLY supports the device it would be better to have a fallback option with BASIC features than having nothing!
I don't know what OS layers you are talking about here, and this is way too OS specific, for the FW to care about. remember, it's not some messy "uboot", which only cares about linux and nothing else, it's about a standard for booting any OS. And their intention was clear - it's FW
boot services, made for using at boot time. on the boot time, your efi application, OS loader, uses all these possibilities (on the other end, your OS loader is a builder of your OS image/infrastructure and, basically is a part of it ), if it needs to, and only when everything has been read and ready, this link is getting thorn by it, not by FW, now OS has its drivers to manage everything, doesn't it? The same way you may use efi apps for even updating and upgrading your OS, if you want to, downloading your SCSI (sexy) drivers. You may have a whole bunch of efi apps for every need your OS might have, you even have an ability to put it in your own freakin Vendor directory, in the ESP, isn't this cool?
you may use everything there, it's just your choice when to do ExitBootServices(). Requiring these services to be present all the way even at run time, sounds just as a caprice, just to find something to pick on. Practically, it will not be a good idea, because the owner of the system at any time should be just one (we already have such parasite "technology" literally, as HV). The same way, blaming the FW for "over-complicated" design and requiring from it some "librarian" kind of support for things like graphics is unfair. What support? For every imagined OS? Probably that support would suck (dead bunnies through bent straws), so maybe you are better off to provide your OS with what support you want.
All I wanted to say, they didn't include all those things intentionally, because genuinely believed it's not needed at OS run time. I see that logical and I am not inclined to jump in a bandagon of "criticism" just becuase Linus told. (I'd rather do opposite
)
Efi applications are the key for interfacing with variety of UEFI services. Those are the bridge between the FW and OS. Use this approach to take advantages UEFI represents. Make your OSLoader deeply integrated in both UEFI and the kernel to achieve what you said is desirable.
