Messages in this thread | | | Date | Wed, 23 Jun 1999 22:47:32 -0700 (PDT) | From | Matthew Jacob <> | Subject | Re: System unique identifier..... |
| |
> 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/
| |