> 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
>> 1. combine timestamp, count and part into "id".
>>for now, in efi-pstore.c, *id = part. and we could simply change it
>>to unique one. F.E. *id = (timestamp * 100 + part) * 100 + count.
>
> My opinion close to 1.
> But, the "*id" should not be the complex one like (timestamp * 100 +
.kernel.org
> [mailto:linux-efi-ow...@vger.kernel.org] On Behalf Of Madper Xie
> Sent: Wednesday, October 30, 2013 11:01 PM
> To: Luck, Tony
> Cc: Seiji Aguchi; Madper Xie; keesc...@chromium.org; ccr...@android.com;
> an...@enomsg.org; linux-...@vger.kernel.org; linux-
> ker...@vg
: Wednesday, October 30, 2013 11:01 PM
To: Luck, Tony
Cc: Seiji Aguchi; Madper Xie; keesc...@chromium.org; ccr...@android.com;
an...@enomsg.org; linux-...@vger.kernel.org; linux-
ker...@vger.kernel.org; bbbo...@gmail.com
Subject: Re: [PATCH 0/2] make all stored entries accessible.
tony.l
1. combine timestamp, count and part into id.
for now, in efi-pstore.c, *id = part. and we could simply change it
to unique one. F.E. *id = (timestamp * 100 + part) * 100 + count.
My opinion close to 1.
But, the *id should not be the complex one like (timestamp * 100 + part) *
100 +
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
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
>
> 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
> 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
> 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
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
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
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
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
14 matches
Mail list logo
