Subject: netbsd DHCP vendor class identifier (VCI)
To: None <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 11/10/2005 16:52:17
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,
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?