From owner-freebsd-arch@FreeBSD.ORG Tue Apr 10 21:55:16 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BABF16A401; Tue, 10 Apr 2007 21:55:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9002A13C4B9; Tue, 10 Apr 2007 21:55:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3ALtDxI067651; Tue, 10 Apr 2007 17:55:13 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 10 Apr 2007 17:46:02 -0400 User-Agent: KMail/1.9.4 References: <20070407120656.GD63916@garage.freebsd.pl> <200704091335.42092.jkim@FreeBSD.org> <20070409190743.GL76673@garage.freebsd.pl> In-Reply-To: <20070409190743.GL76673@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704101746.02890.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Tue, 10 Apr 2007 17:55:13 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3064/Tue Apr 10 12:25:23 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: gnn@freebsd.org, Pawel Jakub Dawidek , Jung-uk Kim Subject: Re: Host ID. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 21:55:16 -0000 On Monday 09 April 2007 15:07, Pawel Jakub Dawidek wrote: > On Mon, Apr 09, 2007 at 01:35:39PM -0400, Jung-uk Kim wrote: > > On Sunday 08 April 2007 11:13 am, Pawel Jakub Dawidek wrote: > > > On Sun, Apr 08, 2007 at 10:04:16PM +0900, gnn@freebsd.org wrote: > > > > I noted that someone mentioned using a network based ID. Since > > > > EUI-64 are unique I would suspect they would be the best source > > > > for this on systems that don't naturally have a hostid concept. > > > > See Appendix A of RFC 2373 for how to create an EUI-64 Interface > > > > Identifier. > > > > > > > > The only problem with this approach that I see is that if you > > > > remove that interface (that is it was on a card not on your > > > > motherboard) then it goes away. Perhaps generating this and > > > > storing it, no matter what the future network configuration of > > > > the system is, is the right way to go. > > > > > > So why not generate it and be done with it? And what if you move > > > your card to another box were you're planning to install new > > > system? > > > > Actually uuidgen(2) uses uuid(3) and uuid(3) generates UUID version 1 > > string, i.e., it is based on timestamp and MAC address already. :-) > > But in my proposal we generate UUID only once and store it as it is, > which means are keep the same UUID even if network card has changed. > > > > I'd really like to make it simple and consistent on all archs, so > > > one knows exactly what to expect. > > > > Agreed. But I also agree with imp, i.e., we have to utilize hardware > > UUID if it is available and valid for the platform. > > I don't agree. As Robert pointed out there are situation you would like > to share the same UUID between many hosts. > > I'm committing as it is, we may change it in the future. Actually, I think it would be quite useful to use a hardware-defined ID if it exists. I think DES's suggestion of only using it when generating /etc/hostid strikes the right balance. -- John Baldwin