On Fri, 25 Sep 2020 at 02:51, joeyli <jlee@xxxxxxxx> wrote: > > Hi Ard, > > On Thu, Sep 24, 2020 at 12:47:46PM +0200, Ard Biesheuvel wrote: > > On Thu, 24 Sep 2020 at 10:28, Lee, Chun-Yi <joeyli.kernel@xxxxxxxxx> wrote: > > > > > > This patch moved the logic of creating efivars mount point to the > > > registration of efivars abstraction. It's useful for userland to > > > determine the availability of efivars filesystem by checking the > > > existence of mount point. > > > > > > The 'efivars' platform device be created on generic EFI runtime services > > > platform, so it can be used to determine the availability of efivarfs. > > > But this approach is not available for google gsmi efivars abstraction. > > > > > > This patch be tested on Here on qemu-OVMF and qemu-uboot. > > > > > > Cc: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > Cc: Matthias Brugger <mbrugger@xxxxxxxx> > > > Cc: Fabian Vogt <fvogt@xxxxxxxx> > > > Cc: Ilias Apalodimas <ilias.apalodimas@xxxxxxxxxx> > > > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > Cc: Arthur Heymans <arthur@xxxxxxxxxxxx> > > > Cc: Patrick Rudolph <patrick.rudolph@xxxxxxxxxxxxx> > > > Signed-off-by: "Lee, Chun-Yi" <jlee@xxxxxxxx> > > > --- > > > > I take it this is v3 of [0]? If so, please explain how it deviates > > from v2. If it doesn't deviate from v2, it is better to continue the > > discussion in the other thread. > > > > For the sake of discussion, it helps to clarify the confusing nomenclature: > > > > a) 'efivars abstraction' - an internal kernel API that exposes EFI > > variables, and can potentially be backed by an implementation that is > > not EFI based (i.e., Google gsmi) > > > > b) efivars.ko module, built on top of the efivars abstraction, which > > exposes EFI variables (real ones or gsmi ones) via the deprecated > > sysfs interface > > > > c) efivarfs filesystem, also built on top of the efivars abstraction, > > which exposes EFI variables (real ones or gsmi ones) via a special > > filesystem independently of sysfs. > > > > Of course, the sysfs mount point we create for efivarfs is not called > > 'efivarfs' but 'efivars'. The sysfs subdirectory we create for > > efivars.ko is called 'vars'. Sigh. > > > > Thanks for your clarification. It's useful to me! > > > > > In this patch, you create the mount point for c) based on whether a) > > gets registered (which occurs on systems with EFI Get/SetVariable > > support or GSMI), right? So, to Greg's point, wouldn't it be easier to > > simply check whether efivarfs is listed in /proc/filesystems? > > > > Yes, I think that Greg's suggestion is good enough for a userland tool > to detect the availability of efivarfs. You can ignore my patch. > Excellent! Thanks for confirming.
