tony.luck@xxxxxxxxx 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 fundamental part of how ERST works (though the unique ID is just > based around a timestamp). > Okay, maybe there are three options here: 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. 2. change the id's type. let id become a string. so every backend could write anything to id. then it will become a part of filename in pstore filesystem. (but we need fix all backends since we modified api.) 3. apply the patches I have sent... even if the filename will be ugly and gory... Which one do you prefer? >> I acked Madper's patch 2/2 earlier today, but when I look at your test result, I'm not sure if >> it is reasonable for users to make multiple numbers visible to the file name. >> >>> -r--r--r-- 1 root root 17499 Oct 30 13:41 dmesg-erst-5940651313304961029--2129078373-1383165669 > > after I added the "count = 0" initialization the filename gets a tiny bit less > scary: > > -r--r--r-- 1 root root 17499 Oct 30 13:41 dmesg-erst-5940651313304961029-0-1383165669 > > -Tony -- Best, Madper Xie. -- 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
