[linux-yocto] [PATCH 2/3] meta: efi-ext.cfg: replace EFI_VARS with EFIVAR_FS

Stanacar, StefanX stefanx.stanacar at intel.com
Thu Mar 13 05:55:42 PDT 2014




On Thu, 2014-03-13 at 08:18 -0400, Bruce Ashfield wrote:
> On Thu, Mar 13, 2014 at 5:17 AM, Stanacar, StefanX
> <stefanx.stanacar at intel.com> wrote:
> >
> >
> >
> > On Wed, 2014-03-12 at 23:15 -0400, Bruce Ashfield wrote:
> >> On 2014-03-12, 10:15 AM, Stefan Stanacar wrote:
> >> > Linux kernel exposes EFI variables data to userspace via 2 interfaces:
> >> > - old sysfs-efivars interface (CONFIG_EFI_VARS), populated at /sys/firmware/efi/vars,
> >> > 1024 byte maximum per-variable data size limitation, no UEFI Secure Boot variables support
> >> > and not recommended anymore.
> >> > - new efivarfs interface (CONFIG_EFIVAR_FS), typically mounted like this:
> >> > mount -t efivarfs efivarfs /sys/firmware/efi/efivar
> >> > It was added in 3.8 intended as a replacement for the sysfs-efivars interface,
> >> > has no maximum per-variable size limitation and supports UEFI Secure Boot variables.
> >> > It also allows creating new vars easily, a very useful trick:
> >> > printf "\x07\x00\x00\x00\x00" > /sys/firmware/efi/efivar/myvar-12345678-1234-1234-1234-123456789abc
> >>
> >> I haven't looked into it yet, so I'll ask, can both co-exist ? Or
> >> is the most common mount point going to cause problems with a
> >> a conflicting path ?
> >>
> >
> > They both can co-exist - but from what I've read they shouldn't both be
> > active / mounted (the problem isn't the mount point but data
> > inconsistency). So I think we can safely enable both as modules.
> > Can the new one be in efi.cfg and the old one stays in efi-ext.cfg?
> 
> That works for me, have the new one as the default and keep the old one
> around for anyone that happens to depend on it.
> 

Cool, so I'll send a v2 doing exactly that and replacing patches 2 and
3.

Cheers,
Stefan

> Cheers,
> 
> Bruce
> 
> >
> > "Both the
> > sysfs and efivarfs code maintain their own lists which means the two
> > interfaces can be running simultaneously without interference, though
> > it should be noted that because no synchronisation is performed it is
> > very easy to create inconsistencies. efibootmgr doesn't currently use
> > efivarfs and users are likely to also require the old sysfs interface,
> > so it makes sense to allow both to be built."
> > from:
> > https://lkml.org/lkml/2013/4/16/473
> >
> >
> > Cheers,
> > Stefan
> >
> >> If so, I'd rather introduce the new one, and keep the old one
> >> around for this 1.6 release, that way I can warn and remove the
> >> existing one.
> >>
> >> Cheers,
> >>
> >> Bruce
> >>
> >> >
> >> > Signed-off-by: Stefan Stanacar <stefanx.stanacar at intel.com>
> >> > ---
> >> >   meta/cfg/kernel-cache/cfg/efi-ext.cfg | 2 +-
> >> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/meta/cfg/kernel-cache/cfg/efi-ext.cfg b/meta/cfg/kernel-cache/cfg/efi-ext.cfg
> >> > index 6371da2..edceb75 100644
> >> > --- a/meta/cfg/kernel-cache/cfg/efi-ext.cfg
> >> > +++ b/meta/cfg/kernel-cache/cfg/efi-ext.cfg
> >> > @@ -10,5 +10,5 @@ CONFIG_PARTITION_ADVANCED=y
> >> >   # Add support for optional EFI features
> >> >   CONFIG_FRAMEBUFFER_CONSOLE=y
> >> >   CONFIG_FB_EFI=y
> >> > -CONFIG_EFI_VARS=y
> >> > +CONFIG_EFIVAR_FS=y
> >> >   CONFIG_EFI_PARTITION=y
> >> >
> >>
> >
> > --
> > _______________________________________________
> > linux-yocto mailing list
> > linux-yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/linux-yocto
> 
> 
> 



More information about the linux-yocto mailing list