--driver flag

[user7z]

look at this :
[root@lp ~]# efibootmgr --driver
No DriverOrder is set

[root@lp ~]# efibootmgr -c -d /dev/nvme0n1 -p 1 --driver /efi/EFI/systemd/drivers/ext2_x64.efi --verbose
DriverOrder: 0000
Driver0000* Linux HD(1,GPT,772cc26e-56d0-4a31-b44d-3885b5eb7dab,0x800,0x81800)/\EFI\arch\grub.efi/efi/EFI/systemd/drivers/ext2_x64.efi
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 18 08 00 00 00 00 00 6e c2 2c 77 d0 56 31 4a b4 4d 38 85 b5 eb 7d ab 02 02 / 04 04 2a 00 5c 00 45 00 46 00 49 00 5c 00 61 00 72 00 63 00 68 00 5c 00 67 00 72 00 75 00 62 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
data: 2f 65 66 69 2f 45 46 49 2f 73 79 73 74 65 6d 64 2f 64 72 69 76 65 72 73 2f 65 78 74 32 5f 78 36 34 2e 65 66 69

what iam tinkering with is that , iam thinking if there is a possibility to use efivariables , and store some stuff , e.g drivers , some efi executables , etc ... , but no sufficient documentation is provided , specifically for this two :

-r | --driver Operate on Driver variables, not Boot Variables.
-y | --sysprep Operate on SysPrep variables, not Boot Variables.

[user7z]

the --driver option is actually an option that if used like this : efiboormgr --driver , it tels efibootmgr to apply the options named boot options , to the driver variables , the help message should declare that there are three types of variables to affect :
#bootvariables
#drivervariables
#sysprep
the options other than (variable specifires) are applicable to the variable type you like , by default its the bootvariable ,the other types needs to be explecetlly specified.
plz dont play with this two variables , because what this doing is editing the nvram , if one plays with it might affect the firmware in a bad way , wich could BREAK YOU DAMN UEFI !!!
whats the application of this ? the idea is if there is a way to make those useless firmware boot a nonFAT32 filesystems , zfs guys , RAID0 specifically , .... , it could also be a way to add efiexecutables to the firmware , like memtest86+ .

[user7z]

see this pdf , it points some technical cons/pros , those additional two variable types , can be used to unlock a fully luks encrypted device without needing external ESP !!! , no need for external usb to boot fully encrypted disk , this would need devs to release drivers for that , but the curent system boot procees would not allow that , but advanced user could work arround it if the have the devs support , efifs repo has filesystems drivers , this could be applied to a zfs encryption use case for know !!!