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. > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
