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