From owner-freebsd-hackers Thu Jun 24 16: 0: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5799814CA6 for ; Thu, 24 Jun 1999 16:00:05 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id QAA24563; Thu, 24 Jun 1999 16:00:11 -0700 Date: Thu, 24 Jun 1999 15:58:46 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Justin C. Walker" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: System unique identifier..... In-Reply-To: <199906242246.PAA00847@rhapture.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Some systems just take the IEEE MAC address from the motherboard, or > that of the first interface it finds. Others use some algorithmic > variation on that value, but it generally boils down to the same > thing. For newer Intel boxes, you could just use the CPU chip... > well, never mind. Yes. The Solaris drivers use the 'localetheraddr' function, or's in 1<<60 and then HBA instance # << 48 to make a NAA_IEEE port identifier. > > The main issue, I think, is that of persistence. How persistent do > you want it? I'd bet that no matter what source you use, there's > always the problem of "it broke; I had to replace it; now what?". > Kind of like your grandfather's axe, which has had six handles and > two blades over its lifetime, but it's still your grandfather's axe. > I want it to persist until it's changed. Change doesn't mean a reboot. The practical side of this problem, which is a relatively trivial problem, is to supply a consistent node WWN for fibre channel adapters that don't have an assigned WWN in NVRAM. This only needs to be persistent across reboots when I finish implementing the target mode code- a WWN identifying a system as a 'device' needs to persist until told to change. There's all sorts of good stuff for generating 128 UUIDs. That has multiple uses. I want it to be availble to the kernel, and that prior to reboot. It strikes me that some userland generation of UUID could be used to seed a particular kernel- which could be changed via sysctl as needed (w/o rebooting). I'm trying to think of the practical and least objectionable semantics of how to support that sooner rather than later. The Linux folks (mostly Ted) helped me clarify some thinking about this so that the basic original source of the seeded WWN doesn't have to come from first principles in hardware that can be read prior to mounting root. But where the linux folks aren't really hipped on is a good architecturally clean place to store the seed. It'd be nice if we thought of this for FreeBSD. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message