18 Jun
2018
18 Jun
'18
3:50 p.m.
On 18 June 2018 at 17:49, Arnd Bergmann arnd@arndb.de wrote:
On Mon, Jun 18, 2018 at 5:47 PM, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 18 June 2018 at 16:17, Arnd Bergmann arnd@arndb.de wrote:
atomic64_set(&seq, ((u64)get_seconds()) << 32);
if (!atomic64_read(&seq)) {time64_t time = ktime_get_real_seconds();/** This code is unlikely to still be needed in year 2106,* but just in case, let's use a few more bits for timestamps* after y2038 to be sure they keep increasing monotonically* for the next few hundred years...*/if (time < 0x80000000)atomic64_set(&seq, (ktime_get_real_seconds()) << 32);elseatomic64_set(&seq, 0x8000000000000000ull |ktime_get_real_seconds() << 24);}Given that these values are never decoded and interpreted as timestamps, can't we simply switch to the second flavour immediately?
I considered that, but the downside would be that all future filenames would come before all past file names.
Won't we have that same problem in 2038?
I don't know if the order is important at all, but the current implementation at least looks like it's intended to keep all file names strictly sorted across boots.
Arnd