Messages in this thread | | | Date | Thu, 24 Jun 1999 17:24:58 -0400 | Subject | Re: System unique identifier..... | From | tytso@mit ... |
| |
Date: Wed, 23 Jun 1999 22:47:32 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com>
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/
| |