>> 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
Yes. These are nice:
public kernel image ID (also found in System.map)
public boot ID
private boot ID
public system ID (stored where?)
private system ID (stored where?)
>> 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
...
> 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 NT boot loader can read the registry. It must do this for i18n
support at least. (it then loads a variety of files)
> 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.
This is quite a mess. It would be nice to have every boot loader
ship with a program to set parameters, wherever they may be stored.
-
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/