In article <4373EB41.2040905@tadpole.com>,
Garrett D'Amore <garrett_damore@tadpole.com> wrote:
>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?

I think that this is a reasonable request. Any more information that
we should put there to avoid further flag-days?

christos