RE: [PATCH 0/2] make all stored entries accessible.

2013-10-31 Thread Seiji Aguchi
I also like option 1 ... but I think the id should be a persistent value for a given saved record. So some func(timestamp, part, count) would be a good idea. If we try using sequential numbers - and don't manage to clear out /sys/fs/pstore each time - then we may have the same dmesg file

RE: [PATCH 0/2] make all stored entries accessible.

2013-10-30 Thread Luck, Tony
1. checking type, id, psi, count and timespec when finding duplicate entries. 2. adding count and timestamp for differentiating. Ah - I was expecting that the backend driver would have a unique id for each record stored ... but is seems that this isn't true for efivars. I just tried this

RE: [PATCH 0/2] make all stored entries accessible.

2013-10-30 Thread Seiji Aguchi
Ah - I was expecting that the backend driver would have a unique id for each record stored ... but is seems that this isn't true for efivars. So, do you mean efivars should fix to use the id in a proper way? I acked Madper's patch 2/2 earlier today, but when I look at your test result, I'm

RE: [PATCH 0/2] make all stored entries accessible.

2013-10-30 Thread Luck, Tony
So, do you mean efivars should fix to use the id in a proper way? It would avoid the need for all these tests, and additions to the filename to guarantee uniqueness. Not sure what options efivars has to create a unique, persistent id for each record. It's a fundamental part of how ERST works

Re: [PATCH 0/2] make all stored entries accessible.

2013-10-30 Thread Madper Xie
tony.l...@intel.com writes: So, do you mean efivars should fix to use the id in a proper way? It would avoid the need for all these tests, and additions to the filename to guarantee uniqueness. Not sure what options efivars has to create a unique, persistent id for each record. It's a