* [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction @ 2020-09-24 8:28 Lee, Chun-Yi 2020-09-24 9:51 ` Greg Kroah-Hartman 2020-09-24 10:47 ` Ard Biesheuvel 0 siblings, 2 replies; 6+ messages in thread From: Lee, Chun-Yi @ 2020-09-24 8:28 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi, linux-kernel, Lee, Chun-Yi, Ard Biesheuvel, Matthias Brugger, Fabian Vogt, Ilias Apalodimas, Greg Kroah-Hartman, Arthur Heymans, Patrick Rudolph 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@kernel.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Fabian Vogt <fvogt@suse.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Arthur Heymans <arthur@aheymans.xyz> Cc: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> --- drivers/firmware/efi/efi.c | 7 ------- drivers/firmware/efi/vars.c | 17 +++++++++++++++++ 2 files changed, 17 insertions(+), 7 deletions(-) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 3aa07c3b5136..23c11a2a3f4d 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -405,13 +405,6 @@ static int __init efisubsys_init(void) if (error) goto err_remove_group; - /* and the standard mountpoint for efivarfs */ - error = sysfs_create_mount_point(efi_kobj, "efivars"); - if (error) { - pr_err("efivars: Subsystem registration failed.\n"); - goto err_remove_group; - } - if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS)) efi_debugfs_init(); diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c index 973eef234b36..6fa7f288d635 100644 --- a/drivers/firmware/efi/vars.c +++ b/drivers/firmware/efi/vars.c @@ -1179,6 +1179,8 @@ int efivars_register(struct efivars *efivars, const struct efivar_operations *ops, struct kobject *kobject) { + int error; + if (down_interruptible(&efivars_lock)) return -EINTR; @@ -1191,6 +1193,19 @@ int efivars_register(struct efivars *efivars, up(&efivars_lock); + /* and the standard mountpoint for efivarfs */ + if (efi_kobj) { + error = sysfs_create_mount_point(efi_kobj, "efivars"); + if (error) { + if (down_interruptible(&efivars_lock)) + return -EINTR; + __efivars = NULL; + up(&efivars_lock); + pr_err("efivars: Subsystem registration failed.\n"); + return error; + } + } + return 0; } EXPORT_SYMBOL_GPL(efivars_register); @@ -1222,6 +1237,8 @@ int efivars_unregister(struct efivars *efivars) pr_info("Unregistered efivars operations\n"); __efivars = NULL; + if (efi_kobj) + sysfs_remove_mount_point(efi_kobj, "efivars"); rv = 0; out: -- 2.16.4 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction 2020-09-24 8:28 [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction Lee, Chun-Yi @ 2020-09-24 9:51 ` Greg Kroah-Hartman 2020-09-25 0:43 ` joeyli 2020-09-24 10:47 ` Ard Biesheuvel 1 sibling, 1 reply; 6+ messages in thread From: Greg Kroah-Hartman @ 2020-09-24 9:51 UTC (permalink / raw) To: Lee, Chun-Yi Cc: Ard Biesheuvel, linux-efi, linux-kernel, Lee, Chun-Yi, Ard Biesheuvel, Matthias Brugger, Fabian Vogt, Ilias Apalodimas, Arthur Heymans, Patrick Rudolph On Thu, Sep 24, 2020 at 04:28:33PM +0800, Lee, Chun-Yi 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. Why not do what all other tools do, and look in /proc/filesystems? Why is efivars "special" in this way? What tool isn't properly looking for the filesystem in that way today? > 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. I do not understand this last sentence, can you try to explain it better? > This patch be tested on Here on qemu-OVMF and qemu-uboot. How about real hardware? :) > > Cc: Ard Biesheuvel <ardb@kernel.org> > Cc: Matthias Brugger <mbrugger@suse.com> > Cc: Fabian Vogt <fvogt@suse.com> > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Arthur Heymans <arthur@aheymans.xyz> > Cc: Patrick Rudolph <patrick.rudolph@9elements.com> > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> > --- > drivers/firmware/efi/efi.c | 7 ------- > drivers/firmware/efi/vars.c | 17 +++++++++++++++++ > 2 files changed, 17 insertions(+), 7 deletions(-) > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index 3aa07c3b5136..23c11a2a3f4d 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -405,13 +405,6 @@ static int __init efisubsys_init(void) > if (error) > goto err_remove_group; > > - /* and the standard mountpoint for efivarfs */ > - error = sysfs_create_mount_point(efi_kobj, "efivars"); > - if (error) { > - pr_err("efivars: Subsystem registration failed.\n"); > - goto err_remove_group; > - } > - > if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS)) > efi_debugfs_init(); > > diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c > index 973eef234b36..6fa7f288d635 100644 > --- a/drivers/firmware/efi/vars.c > +++ b/drivers/firmware/efi/vars.c > @@ -1179,6 +1179,8 @@ int efivars_register(struct efivars *efivars, > const struct efivar_operations *ops, > struct kobject *kobject) > { > + int error; > + > if (down_interruptible(&efivars_lock)) > return -EINTR; > > @@ -1191,6 +1193,19 @@ int efivars_register(struct efivars *efivars, > > up(&efivars_lock); > > + /* and the standard mountpoint for efivarfs */ > + if (efi_kobj) { Why test for this? Can it race? thanks, greg k-h ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction 2020-09-24 9:51 ` Greg Kroah-Hartman @ 2020-09-25 0:43 ` joeyli 0 siblings, 0 replies; 6+ messages in thread From: joeyli @ 2020-09-25 0:43 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Lee, Chun-Yi, Ard Biesheuvel, linux-efi, linux-kernel, Ard Biesheuvel, Matthias Brugger, Fabian Vogt, Ilias Apalodimas, Arthur Heymans, Patrick Rudolph Hi Greg, On Thu, Sep 24, 2020 at 11:51:57AM +0200, Greg Kroah-Hartman wrote: > On Thu, Sep 24, 2020 at 04:28:33PM +0800, Lee, Chun-Yi 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. > > Why not do what all other tools do, and look in /proc/filesystems? > > Why is efivars "special" in this way? What tool isn't properly looking > for the filesystem in that way today? > Thanks for your idea. I think that this is good enough for userland tool to check the availability of efivarfs. Ignore my patch please. Regards Joey Lee > > 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. > > I do not understand this last sentence, can you try to explain it > better? > > > This patch be tested on Here on qemu-OVMF and qemu-uboot. > > How about real hardware? :) > > > > > Cc: Ard Biesheuvel <ardb@kernel.org> > > Cc: Matthias Brugger <mbrugger@suse.com> > > Cc: Fabian Vogt <fvogt@suse.com> > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: Arthur Heymans <arthur@aheymans.xyz> > > Cc: Patrick Rudolph <patrick.rudolph@9elements.com> > > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> > > --- > > drivers/firmware/efi/efi.c | 7 ------- > > drivers/firmware/efi/vars.c | 17 +++++++++++++++++ > > 2 files changed, 17 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > > index 3aa07c3b5136..23c11a2a3f4d 100644 > > --- a/drivers/firmware/efi/efi.c > > +++ b/drivers/firmware/efi/efi.c > > @@ -405,13 +405,6 @@ static int __init efisubsys_init(void) > > if (error) > > goto err_remove_group; > > > > - /* and the standard mountpoint for efivarfs */ > > - error = sysfs_create_mount_point(efi_kobj, "efivars"); > > - if (error) { > > - pr_err("efivars: Subsystem registration failed.\n"); > > - goto err_remove_group; > > - } > > - > > if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS)) > > efi_debugfs_init(); > > > > diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c > > index 973eef234b36..6fa7f288d635 100644 > > --- a/drivers/firmware/efi/vars.c > > +++ b/drivers/firmware/efi/vars.c > > @@ -1179,6 +1179,8 @@ int efivars_register(struct efivars *efivars, > > const struct efivar_operations *ops, > > struct kobject *kobject) > > { > > + int error; > > + > > if (down_interruptible(&efivars_lock)) > > return -EINTR; > > > > @@ -1191,6 +1193,19 @@ int efivars_register(struct efivars *efivars, > > > > up(&efivars_lock); > > > > + /* and the standard mountpoint for efivarfs */ > > + if (efi_kobj) { > > Why test for this? Can it race? > > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction 2020-09-24 8:28 [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction Lee, Chun-Yi 2020-09-24 9:51 ` Greg Kroah-Hartman @ 2020-09-24 10:47 ` Ard Biesheuvel 2020-09-25 0:50 ` joeyli 1 sibling, 1 reply; 6+ messages in thread From: Ard Biesheuvel @ 2020-09-24 10:47 UTC (permalink / raw) To: Lee, Chun-Yi Cc: Ard Biesheuvel, linux-efi, Linux Kernel Mailing List, Lee, Chun-Yi, Matthias Brugger, Fabian Vogt, Ilias Apalodimas, Greg Kroah-Hartman, Arthur Heymans, Patrick Rudolph On Thu, 24 Sep 2020 at 10:28, Lee, Chun-Yi <joeyli.kernel@gmail.com> 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@kernel.org> > Cc: Matthias Brugger <mbrugger@suse.com> > Cc: Fabian Vogt <fvogt@suse.com> > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Arthur Heymans <arthur@aheymans.xyz> > Cc: Patrick Rudolph <patrick.rudolph@9elements.com> > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> > --- 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. 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? It also helps if you could clarify what the actual use case is, rather than saying that it is generally useful. [0] https://lore.kernel.org/linux-efi/20200825160719.7188-1-jlee@suse.com/ > drivers/firmware/efi/efi.c | 7 ------- > drivers/firmware/efi/vars.c | 17 +++++++++++++++++ > 2 files changed, 17 insertions(+), 7 deletions(-) > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index 3aa07c3b5136..23c11a2a3f4d 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -405,13 +405,6 @@ static int __init efisubsys_init(void) > if (error) > goto err_remove_group; > > - /* and the standard mountpoint for efivarfs */ > - error = sysfs_create_mount_point(efi_kobj, "efivars"); > - if (error) { > - pr_err("efivars: Subsystem registration failed.\n"); > - goto err_remove_group; > - } > - > if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS)) > efi_debugfs_init(); > > diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c > index 973eef234b36..6fa7f288d635 100644 > --- a/drivers/firmware/efi/vars.c > +++ b/drivers/firmware/efi/vars.c > @@ -1179,6 +1179,8 @@ int efivars_register(struct efivars *efivars, > const struct efivar_operations *ops, > struct kobject *kobject) > { > + int error; > + > if (down_interruptible(&efivars_lock)) > return -EINTR; > > @@ -1191,6 +1193,19 @@ int efivars_register(struct efivars *efivars, > > up(&efivars_lock); > > + /* and the standard mountpoint for efivarfs */ > + if (efi_kobj) { > + error = sysfs_create_mount_point(efi_kobj, "efivars"); > + if (error) { > + if (down_interruptible(&efivars_lock)) > + return -EINTR; > + __efivars = NULL; > + up(&efivars_lock); > + pr_err("efivars: Subsystem registration failed.\n"); > + return error; > + } > + } > + > return 0; > } > EXPORT_SYMBOL_GPL(efivars_register); > @@ -1222,6 +1237,8 @@ int efivars_unregister(struct efivars *efivars) > > pr_info("Unregistered efivars operations\n"); > __efivars = NULL; > + if (efi_kobj) > + sysfs_remove_mount_point(efi_kobj, "efivars"); > > rv = 0; > out: > -- > 2.16.4 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction 2020-09-24 10:47 ` Ard Biesheuvel @ 2020-09-25 0:50 ` joeyli 2020-09-25 7:01 ` Ard Biesheuvel 0 siblings, 1 reply; 6+ messages in thread From: joeyli @ 2020-09-25 0:50 UTC (permalink / raw) To: Ard Biesheuvel Cc: Lee, Chun-Yi, Ard Biesheuvel, linux-efi, Linux Kernel Mailing List, Matthias Brugger, Fabian Vogt, Ilias Apalodimas, Greg Kroah-Hartman, Arthur Heymans, Patrick Rudolph 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@gmail.com> 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@kernel.org> > > Cc: Matthias Brugger <mbrugger@suse.com> > > Cc: Fabian Vogt <fvogt@suse.com> > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: Arthur Heymans <arthur@aheymans.xyz> > > Cc: Patrick Rudolph <patrick.rudolph@9elements.com> > > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> > > --- > > 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. Thanks for your help! Joey Lee > It also helps if you could clarify what the actual use case is, rather > than saying that it is generally useful. > > > > > > [0] https://lore.kernel.org/linux-efi/20200825160719.7188-1-jlee@suse.com/ > > > drivers/firmware/efi/efi.c | 7 ------- > > drivers/firmware/efi/vars.c | 17 +++++++++++++++++ > > 2 files changed, 17 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > > index 3aa07c3b5136..23c11a2a3f4d 100644 > > --- a/drivers/firmware/efi/efi.c > > +++ b/drivers/firmware/efi/efi.c > > @@ -405,13 +405,6 @@ static int __init efisubsys_init(void) > > if (error) > > goto err_remove_group; > > > > - /* and the standard mountpoint for efivarfs */ > > - error = sysfs_create_mount_point(efi_kobj, "efivars"); > > - if (error) { > > - pr_err("efivars: Subsystem registration failed.\n"); > > - goto err_remove_group; > > - } > > - > > if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS)) > > efi_debugfs_init(); > > > > diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c > > index 973eef234b36..6fa7f288d635 100644 > > --- a/drivers/firmware/efi/vars.c > > +++ b/drivers/firmware/efi/vars.c > > @@ -1179,6 +1179,8 @@ int efivars_register(struct efivars *efivars, > > const struct efivar_operations *ops, > > struct kobject *kobject) > > { > > + int error; > > + > > if (down_interruptible(&efivars_lock)) > > return -EINTR; > > > > @@ -1191,6 +1193,19 @@ int efivars_register(struct efivars *efivars, > > > > up(&efivars_lock); > > > > + /* and the standard mountpoint for efivarfs */ > > + if (efi_kobj) { > > + error = sysfs_create_mount_point(efi_kobj, "efivars"); > > + if (error) { > > + if (down_interruptible(&efivars_lock)) > > + return -EINTR; > > + __efivars = NULL; > > + up(&efivars_lock); > > + pr_err("efivars: Subsystem registration failed.\n"); > > + return error; > > + } > > + } > > + > > return 0; > > } > > EXPORT_SYMBOL_GPL(efivars_register); > > @@ -1222,6 +1237,8 @@ int efivars_unregister(struct efivars *efivars) > > > > pr_info("Unregistered efivars operations\n"); > > __efivars = NULL; > > + if (efi_kobj) > > + sysfs_remove_mount_point(efi_kobj, "efivars"); > > > > rv = 0; > > out: > > -- > > 2.16.4 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction 2020-09-25 0:50 ` joeyli @ 2020-09-25 7:01 ` Ard Biesheuvel 0 siblings, 0 replies; 6+ messages in thread From: Ard Biesheuvel @ 2020-09-25 7:01 UTC (permalink / raw) To: joeyli Cc: Lee, Chun-Yi, Ard Biesheuvel, linux-efi, Linux Kernel Mailing List, Matthias Brugger, Fabian Vogt, Ilias Apalodimas, Greg Kroah-Hartman, Arthur Heymans, Patrick Rudolph On Fri, 25 Sep 2020 at 02:51, joeyli <jlee@suse.com> 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@gmail.com> 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@kernel.org> > > > Cc: Matthias Brugger <mbrugger@suse.com> > > > Cc: Fabian Vogt <fvogt@suse.com> > > > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > Cc: Arthur Heymans <arthur@aheymans.xyz> > > > Cc: Patrick Rudolph <patrick.rudolph@9elements.com> > > > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> > > > --- > > > > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-09-25 7:01 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-24 8:28 [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction Lee, Chun-Yi 2020-09-24 9:51 ` Greg Kroah-Hartman 2020-09-25 0:43 ` joeyli 2020-09-24 10:47 ` Ard Biesheuvel 2020-09-25 0:50 ` joeyli 2020-09-25 7:01 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).