Bug#773309: CONFIG_PSTORE not enabled for arm64
On Thu, Dec 18, 2014 at 06:35:25PM +0000, Ian Campbell wrote:
> > > Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what
> > > pstore is, so sorry if this is a silly question).
> >
> > I am actually not concerned about pstore itself, but rather by the
> > lack of similarity between platforms.
>
> Consistency is a worthwhile goal, but not at the expense of enabling
> legacy x86 junk on new architectures where it can never have any
> relevance. I don't know if pstore fits that bill, which is why I was
> asking about it.
>
> If pstore is going to be a useful thing on arm64 then of course we
> should enable it. We should *not* enable it purely to gain the side
> effect of loading efivars (the more so since as discussed below it seems
> like efivars itself is a legacy interface).
pstore is not legacy nonsense (it's for storing system crash
information persistently). I don't actively care only since I've also
not heard anyone screaming for it.
> > > Is efivars needed only for efibootmgr or are there other reasons to want
> > > it?
> >
> > The /sys/firmware/efi/vars interface exported by efivars is actually a
> > legacy api (efivarfs is the preferred one), but since it is still
> > shipped, alignment across architectures would be desirable.
>
> Enabling legacy stuff on new architectures by default is not inherently
> desirable IMHO. It would be far better to use the new/proper stuff right
> out the gate, at least by default.
I agree, with the exception that where use of a legacy API has become
widespread enough, we may still need to keep it around until we've
killed off any important users.
> > There may or may not currently be other users than efibootmgr.
>
> I can see references in the efivars package (which provides libefivars,
> which efibootmgr uses) to efivarfs. Which suggests to me that loading
> efivars is not what is needed, but rather the automounting
> of /sys/firmware/efi/vars is. That would need to be a bug against some
> other package (the mountkernfs.sh providing one would be my best guess,
> which may well be systemd these days via some other means, #744301 seems
> related, although it goes further).
Absolutely - I intend to raise that bug on initscripts (but even
looking into that opened up a bit of a rabbit hole).
Ok, so I had a peek in codesearch.debian.net, to see what current
users we have. elilo can be ignored, dracut probably doesn't matter
(?), mdadm has it in platform-intel.c so still wouldn't matter, kernel
doesn't matter and grub2 will work anyway.
Which leaves us with the risk of out-of-tree software making use of it.
> > > (I don't have an x86 EFI system available to poke around and answer
> > > these for myself).
> > >
> > > I'm wondering if we ought to figure out how to load it automatically
> > > independent of the pstore stuff, for all arches.
> >
> > I'd be happy for it not to be autoloaded, as long as it was consistent
> > across architectures.
>
> I think (although I'm somewhat inferring some pieces) that the right
> answer here is to have something (mountkernfs.sh/systemd/pixies) mount
> efivarfs and to ignore the deprecated efivars thing on non-x86. The
> pstore stuff should be considered a separate feature request in its own
> right.
>
> I could clone this bug and retitle+reassign the other half into a bug to
> handle the efi half, but TBH I think conflating the EFI variable access
> from userspace requirement with enabling pstore in the kernel is just
> going to end up causing confusion, so a separate report to get efivarfs
> mounted would probably be best.
>
> Ian.
>
Reply to: