Subject: Re: netbsd DHCP vendor class identifier (VCI)
To: None <>
From: Christos Zoulas <>
List: tech-kern
Date: 11/11/2005 17:06:44
In article <>,
Garrett D'Amore <> wrote:
>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?