[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#773309: CONFIG_PSTORE not enabled for arm64



On Thu, 2014-12-18 at 20:08 +0000, Leif Lindholm wrote:
> 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.

Thanks, it does sound useful rather than legacy. Given what Ben said it
does seem like it would be worthwhile to enable.

> 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.

My inclination is towards suggesting that if people are running
out-of-tree software which needs the efivars interface then they should
arrange for it to be loaded themselves (e.g. by adding to /etc/modules).

Ian.


Reply to: