Hi,

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?

    -- Garrett