Subject: Re: netbsd DHCP vendor class identifier (VCI)
To: None <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 11/11/2005 17:06:44
In article <4373EB41.email@example.com>,
Garrett D'Amore <firstname.lastname@example.org> 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,
>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
>Or for a big-endian machine
>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?