NetBSD Problem Report #32136
From www@netbsd.org Mon Nov 21 17:34:42 2005
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
id 8C9AF63BA19; Mon, 21 Nov 2005 17:34:42 +0000 (UTC)
Message-Id: <20051121173442.8C9AF63BA19@narn.netbsd.org>
Date: Mon, 21 Nov 2005 17:34:42 +0000 (UTC)
From: garrett_damore@tadpole.com
Reply-To: garrett_damore@tadpole.com
To: gnats-bugs@netbsd.org
Subject: DHCP VCI not unique for some platforms
X-Send-Pr-Version: www-1.0
>Number: 32136
>Category: kern
>Synopsis: DHCP VCI not unique for some platforms
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Mon Nov 21 17:35:00 +0000 2005
>Originator: Garrett D'Amore
>Release: 3.99.11
>Organization:
Tadpole Computer, Inc.
>Environment:
evbmips (Au1500 board)
>Description:
This is more fully discussed in http://mail-index.netbsd.org/tech-kern/2005/11/10/0005.html
For reference, here is the original problem description:
I've noticed that the NetBSD in-kernel DHCP client sends a vendor class
identifier which is made up as follows:
snprintf(vci, sizeof(vci), "%s:%s:kernel:%s", ostype, MACHINE,
osrelease);
On my Alchemy based system, this gives "NetBSD:evbmips:kernel:3.99.11"
The problem is that on some systems, this isn't enough information. For
example, on the Alchemy platform, the result given by uname -m is
"evbmips", but the result given by uname -p is either "mipsel" or
"mipseb", depending on whether the kernel is built for big or little endian.
This leads to the problem: I am often switching back and forth on CPU
endianness (to verify changes, for example) on a single unit. This is
set by nothing more than a jumper. However, I need different root
filesystems (the unit is diskless) via NFS, and right now the DHCP
server can't tell the whether I want a big or a little endian userland.
My proposal, therefore, is to add a field, like this:
snprintf(vci, sizeof(vci), "%s:%s:%s:kernel:%s", ostype, machine,
machine_arch, osrelease);
Which would give me a VCI of
NetBSD:evbmips:mipsel:kernel:3.99.11
Or for a big-endian machine
NetBSD:evbmips:mipseb:kernel:3.99.11
I realize this represents change, and there is likely to be some reason
not to change this, but it seems to me the current situation is not
quite adequate and needs fixing. Thoughts?
>How-To-Repeat:
>Fix:
A couple of suggestions were made in the thread:
a) don't change the VCI on platforms where the uname -p and uname -m match.
b) (refinement, if possible) - don't change the VCI on platforms where the uname -m is adequately descriptive (not sure if there is an easy way to tell this, perhaps just a list of platforms where it differs)?
c) change VCI to:
snprintf(vci, sizeof(vci), "%s:%s-%s:kernel:%s", ostype, machine,
machine_arch, osrelease);
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.