Dear @val, I don’t intend to offend you, and in no way I want to transform the technical discussion into emotionally charged polemic. I would stop here, but for those interested to boot an OS in UEFI mode rather than to show their superior knowledge of the specification, I will add some more details.
Linux image has ELF
(Executable and Linkable Format) as well as Haiku, *BSD (modern) and several other OSes. You can find it out by issuing a command from terminal:
file linux-XXXXX
and see the result, something like:
linux-XXXXX: ELF executable x86-64, for Linux
PE
executable format is used by Microsoft executables and by UEFI. Again, you can try:
file boot_linux.efi
(or whatever you have as part of GRUB installation) and see:
boot_linux.efi: PE32 executable x86, for UEFI
or something like this.
EDIT:
On my Linux installation:
file vmlinuz-4.9.0-8-amd64
vmlinuz-4.9.0-8-amd64: Linux kernel x86 boot executable bzImage, version 4.9.0-8-amd64 (debian-kernel@lists.debian.org) #1 SMP Debian 4.9.144-3.1 (2019-02-19), RO-rootFS, swap_dev 0x4, Normal VGA
ls -lh *-4.9.0.8-amd64
-rw-r--r-- 1 root root 183K Feb 19 11:05 config-4.9.0-8-amd64
-rw-r--r-- 1 root root 18M Mar 22 12:10 initrd.img-4.9.0-8-amd64
-rw-r--r-- 1 root root 3,1M Feb 19 11:05 System.map-4.9.0-8-amd64
-rw-r--r-- 1 root root 4,1M Feb 19 11:05 vmlinuz-4.9.0-8-amd64
file boot.efi
boot.efi: Universal EFI binary with 2 architectures, i386, x86_64
ls -lh boot.efi
-r--r--r-- 1 alex alex 224K May 6 2017 boot.efi
You can see the difference between file format of Linux kernel and GRUB EFI image, as well as between their sizes.
The UEFI system only knows how to load / execute PE
format, specially compiled for it, including GRUB EFI. GRUB executable knows how to load Linux kernel (among some others, *BSD, IlluminOS/Solaris, macOS) as a file image, or (in case some OS kernel is part of file system and is not a file, such as MS Windows, Haiku) to chain load that partition, which loads partition loader, or OSL in your terminology. In all cases, an OS cannot pass the control back to UEFI, for this you always need to restart the computer. On the contrary, until Linux is not yet got the control, GRUB EFI can call other EFI executables directly, without restarting the computer.
Think of some Linux distribution, which doesn’t know what system do you have: BIOS/MBR or UEFI/GPT (or any other combination thereof). The same Linux image is installed in all cases. There is no UEFI specific or BIOS specific Linux image. So, the UEFI stuff is not related to Linux per se, but to the bootloader. You can do the following experiment (I did it): copy all the content of Linux partition with installed there Linux from a BIOS PC to UEFI PC, and then reinstall the GRUB. Linux will boot the same Linux image without any problem.
Now, where to keep the Linux image? You choose. Again, you are free to keep it in ESP partition, but this is not its intention (and FAT32 file system doesn’t keep important for Linux meta-information, like the access permissions and creation/modification timestamps). But usually ESP partition is not mounted in Linux. Now, consider you get an update, which also includes the Linux image. Where will it be written to? To Linux partition, or to ESP partition? Again, you can manually configure whatever to work, and update program cannot know your plans. But it will most probably install new kernel image into Linux partition, and you will be forced to repeat your setup to be able to boot Linux again. Where to keep all supporting files (fonts, splashes, animations, etc)? You decide. But just as well GRUB EFI image can access Linux partition to read Linux kernel image file, it also can read all the other files, including all the supporting stuff.
Backup files are usually kept outside of ESP partition. MS Windows UEFI installation creates separate partitions for booting and for backup, of different sizes.
I also played with other architectures than x86/x86-64. They all have their specific partition scheme, have specific bootloaders, which act differently and sometimes are implemented as image to be flashed (unlike file in file system). You probably will not want to have several OSes on ARM based computer, but it is also possible.
Regarding MBR vs GPT partition scheme. MBR takes 512 bytes at the very beginning of the disk and allows up to 4 primary partitions (logical partitions are implemented by repeting the MBR scheme in the beginning of so called extended partition). GPT keeps the partition layout in table of variable length at the beginning of the disk, and its copy at the end of the disk. Because GPT partitioning doesn’t limit the number of partitions on disk, this partition table may grow or shrink. By default, whatever tool you use to create GPT partition scheme (gdisk, gparted, etc), the partition table will be enough to hold 128 partitions. After that, if you create necessary partitions (not more than 128), and then want to create more than 128 partitions, you will need to re-create or adjust the partition table. In the former approach you will lost all your partitions, in the later approach the partition table will take physically more space out of the very first and very last partition, so their size will need to be adjusted.