It doesn't necessarily have to be 'stored on disk' or set via a system
call- it shouldn't be as this is information that is needed prior mounting
root (possibly).
There are a number of mechanisms to generate this. It seems to me that
this would be useful as a general kernel function, even prior to mounting
root. This actually takes this to a different level- a new UUID each boot
would indeed be not on point ridiculous, but arbitrary persistent
information available early at boot could be quite useful ("Gaak! A
Registry! aiee!"). There's a number of clever hacky ways to do this, not
least of which are more command line thingies- it's really more of a
question of where's the best natural place to store this system metadata
so that boot process code can get at it? Linux, so far, has punted this to
per-architecture space- sorry... I'm wandering and just musing
here...
Two quick comments here. First of all, even NT's registry is only
available after the root disk is mounted, since the registry is stored
on disk. The real problem with storing system metadata before the root
filesystem is mounted is that there really isn't any good place to store
the information. Right now, we use per-architecture hacks. About the
only thing architecture-independent which might work is a scheme which
modifies the actual kernel boot image and stores the information in the
kernel boot image. But where the actual kernel boot image is stored is
still architecture and/or boot manager independent. (For example if you
use LOADLIN.EXE the kernel image is stored on a dos partition somewhere
which might not even be accessible once Linux is booted.) So there
really aren't any good solutions here.
Secondly, note that /dev/random also isn't really useful that early in
the boot process, since it hasn't had a chance to capture much (if any)
entropy from the boot environment, and it wouldn't have had a chance to
reload entropy saved to disk from during the previous shutdown
procedure.
At any rate, this was all quite helpful. A user space UUID generator can
generate the seed WWN. I'll figure out some clever place to put it so
that a driver can get at it. It'd be nice if this was a generalizable
persistent system metadata solution that was not a per-platform different
mechanism (you know, OBP NVRAM for sparc, SRM NVRAM for Alpha, lilo
extensions for i386...).
Yes, this should work. I agree it would be nice to have a
architecture-indepedent persistent system metadata that was accessible
very early in the boot process. But that really isn't realistic.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/