Subject: Re: netbsd DHCP vendor class identifier (VCI)
To: None <tech-kern@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: tech-kern
Date: 11/11/2005 17:06:44
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