> 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 show up with different names on each boot.
>
> Right now I have a simple script to save & clear ... not much more
> complex than:
>
> cd /sys/fs/pstore
> cp * /var/log/save-pstore
> rm *
>
> This depends on not re-using filenames (otherwise new files in pstore
> might overwrite older saved files in my /var/log/save-pstore area).
I see.. It is a persuasive use case.
(1) I agree that some func(timestamp, part, count) would be good idea.
This might work, although an overflow will happen some time...
sprintf(id_str, "%lld%d%d", timestamp, part, count)
simple_str_to_ull(id_str, &id, base)
(2) There is a GetNextHighMonotonicCount() runtime service in EFI specification
to get a persistent number across the reboot, but I'm not sure if it is safe to use it..
Also, it would be good if we can create the id by ourselves, rather than using firmware.
(3) Also, (it might not be good idea), if a pstore filesystem expects all backend drivers
to use the persistent id, the pstore should provide it by itself.
(by using time stamp counter or something like that.)
As I looked into the ramoops's code. It seems to use a non-persistent sequential counter,by initializing
read_cnt to "0" in ramoops_pstore_open(), and incrementing it in ramoops_pstore_read().
It doesn't seem to be the pstore's expectation.
And when someone introduces a new driver, they may misunderstand how to create the id as well..
As above, there are mutiple ideas, but (1) is reasonable to me.
Seiji
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
