Hello Linus, I am sending this cycle's EFI changes as two separate pull requests: - the first one covers the normal updates accumulated this cycle, including some cleanup of the 'efivars' layer; - the second one removes the obsolete 'efivars' sysfs driver, and consolidates the remaining code related to manipulating arbitrary EFI variables from user space into the efivarfs pseudo-filesystem driver. The 'efivars' sysfs interface and the 'efivarfs' (note the 'f') pseudo-filesystem are both based on an abstraction which is also called 'efivars' that caches EFI variables, and permits the backend to be swapped out, for backing the EFI variable store by, e.g., SMI calls or other secure firmware calls. (only used by Google SMI at the moment, but new uses are being proposed). Using two cached views of the same variable store leads to the problems you might expect, and other users also exist that (ab)use the efivars layer for non-obvious reasons. Most of the quirks are being cleaned up in 1/2 of this PR series. However, to really address this thoroughly, we should get rid of the obsolete sysfs based EFI variable interface for user space, and only keep the efivarfs pseudo-filesystem. This is what is implemented by 2/2 of this PR series, which also moves the remaining efivars logic that efivarfs relies on into the efivarfs driver, and no longer exports it to other parts of the kernel. Obviously, removing the sysfs interface could potentially break someone's workflow somewhere, and so it is not without risk. However, as far as I can infer from things like Debian code search etc, all support libraries that are in use to access EFI variables will prefer the efivarfs pseudo-filesystem, and fall back to the sysfs interface otherwise. The efivarfs pseudo-FS is 'default m' when CONFIG_EFI=y, and all the distros have switched to it a very long time ago. But individual cases might exist where a script accesses /sys/firmware/efi/vars/... directly, and this will no longer work after merging PR 2/2 of this series. In summary, I am leaving it up to you to pull the trigger on PR 2/2 - if you prefer to deal with this in a different way, please feel free to disregard the second PR, and make a suggestion how to address this instead. Note that the 2/2 changes were put at the end so reverting this should be quite straight-forward, in case we do decide to merge them and they turn out to be causing problems. Thanks, Ard.
