Re: kern.boottime drift after boot?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> On embedded systems without an RTC, you _could_ get the same UUID in
>> rare cases.  But I think this would be a bug, because on Linux, any
>> kind of jitter-source (interrupt timing, for instance) would perturb
>> the generated UUID.

> Hopefully!  Even though this jitter might not be high entropy, it
> should (in theory) be enough to give a differnet UUID each boot.

Probably.  Depending on how the entropy and RNG are handled, it is
likely to be different only with some (relatively high) probability.

What probability of collision (ie, of a boot giving the same value as
the previous boot) is acceptable here?  One in 256?  One in 64k?  One
in 4G?  If you're doing "random" generation, it's hard to avoid some
chance of collision.

If the system can tolerate repeated writes to a piece of its mass
storage (disk etc - "disk" for brevity), you could set up something
with (say) a 32-bit value saved in a fixed place.  Each boot, you read
it, save the value somewhere for this boot, and write it back to disk
incremented before doing anything else.  The value saved is your boot
ID.  But this depends on having a small piece of disk you can afford to
write to once per boot.

It also demands custom kernel code, unless NetBSD wants to adopt
something of the sort or it's acceptable to have duplicate boot IDs if
a boot attempt crashes "too early".  If the latter is acceptable
(which, based on the fragments of the original post I saw quoted,
sounds likely), you could even do it entirely in userland, immediately
upon having a writable persistent filesystem available.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B