Tony, I think all guys agree to hold multiple logs. On the other hand, we have different opinions on overwriting policy. So, I would like to find a way to fix this issue ,losing critical message, without overwriting policy at first. I talked with Matthew a bit privately and he suggested to use QueryVariableInfo service which is supported in EFI 2.0 or later. If we can use it, we know the remaining NVRAM space before calling SetVariable. This mean that we can avoid the situation which efi_pstore have to handle out of space conditions. Also, we don't need to introduce a new kernel parameter by just holding multiple logs. What do you think? Seiji > -----Original Message----- > From: Matthew Garrett [mailto:mjg@xxxxxxxxxx] > Sent: Monday, July 23, 2012 10:17 AM > To: Don Zickus > Cc: Seiji Aguchi; Luck, Tony; linux-doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; mikew@xxxxxxxxxx; dle- > develop@xxxxxxxxxxxxxxxxxxxxx; Satoru Moriya > Subject: Re: [RFC][PATCH v2 2/3] Hold multiple logs > > On Thu, Jul 19, 2012 at 11:03:28PM -0400, Don Zickus wrote: > > > What is the harm of not using this and just letting the number be > > infinite (or until EFI runs out of space)? Is it a big deal if extra > > failures are logged? > > Running out of space in EFI isn't a well-tested scenario, and I wouldn't expect all firmware to handle it gracefully. This is made worse by > EFI 1 not providing any information about available storage. I'd be fine with changing the default number of entries on systems where > we can obtain the appropriate information to make that decision, but otherwise I think it should be limited to 1. > > -- > Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
