Re: System unique identifier.....

Matthew Jacob (mjacob@feral.com)
Wed, 23 Jun 1999 22:47:32 -0700 (PDT)

> Date: Tue, 22 Jun 1999 11:52:18 -0700 (PWT)
> From: Matthew Jacob <mjacob@feral.com>
>
> My original posting said why I was doing this- I've a need to generate at
> least a 64 bit unique WWN for a NODE id for fibre channel. This is for
> fibre channel ports that don't have assigned (in NVRAM) WWNs. Like I said,
> Solaris has a hack that takes the first ethernet mac addr and or's in 1 <<
> 60 (and controller instance number if you're making a port vs. a node WWN)
> for this purpose. I could do this also for Linux, but it raised the
> metaquestion of "I need a system unique identifier". Yes, it's a
> heavyweight object, but that's no reason to not make it available to
> kernel (at boot time too) subsystems that need it.
>
> Does this system unique identifier need to be the same across reboots?
> If so, an in-kernel UUID generator which generates a new UUID at each
> boot is obviously the wrong thing. Instead, the system unique
> identifier would have to be stored on disk, and set using a system call,
> much like the system's hostname is set via a system call....
>
> If you just need a 128 or 64 bit unique id which is generated on the
> spot and doesn't need to be saved across reboots, this could trivially
> be done using a call to /dev/random routines.

Yes. That'd be trivial.

The system unique identifier needs to persistent across reboots, but
could also need to be changed without a reboot- kernel modules come and
go, and there might be an administrative reason to change the node WWN.
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...

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...).

Thanks- you helped me sort my muzzy thinking.

-matt

-
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/