seiji.aguchi@xxxxxxx writes: >> Then will lost the sequence of our log. We will get lots of entries like >> "dmesg-efi-`unique but meaningless number here`" in pstore fs. Who will >> know which file is the latest record? > > Ah, that's good point. > >> And another side, the combin of timestamp, count and part is unique. Why >> we generate a unique number from a unique number? >> if you think "making a string from three ints and then a parse it to a >> int again" is odd, i'd like to use ((timestamp * 100 + part) * 100 + >> count. > > How about calculating the number of digit of part /count, instead of using fixed "100"? > We can ensure the uniqueness of each id by doing it. > > digit_num = log2(part)/log2(10) + 1 > timestamp * 10^(digit_num + 1) > Then we must implement a log10 and a pow func... And reverting id to timestamp, part and count will hard if we using unfixed length of count and id. So i'd like to using fixed length. My dell xps has 128kb nvram space. and it at most store 126 pstore entries. So I think 1000 will be a safe value for count. For part, 100 should be okay. I don't think there will be a large kmsg and we must split it into more than 100 parts. > 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
