>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
