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

[Bruce Ashfield]

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.

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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"