Subject: hw.machine in compat mode
To: None <>
From: Quentin Garnier <>
List: tech-kern
Date: 07/09/2004 22:18:59
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi folks,

This morning I asked around about how we should handle hw.machine and
hw.machine_arch for compat modules, most notably for netbsd32.

Currently we only override hw.machine_arch, but I think it is wrong.

For example, on an i386, both uname -m and -p return 'i386', while on
amd64/compat_netbsd32, uname -m still returns 'amd64' and uname -p returns

It confuses packages and lead some (well, at least Mozilla Firefox's, the
one I tried today) configure scripts to try and build amd64 code, which is
not possible in a compat_netbsd32 environment (the i386 gcc doesn't allow

First I thought that using 64 bits extensions in 32 bits mode was possible
on x86_64, so it would actually have made sense to have uname -a returning
'i386' and uname -p returning 'x86_64', so that application could even
know they can use 64 bits extensions (just like 16 bits applications can
use 32 bits registers and operands on ia32).

Unfortunately this is not possible so 'i386' for uname -p is ok.

I believe this is the same issue for sparc64, while sh5 is not really
affected since the emulated arch is still called sh5.

Adding an override for hw.machine is a piece of cake work, but are there
any objections about it?

[Just for the notice:  once hw.machine changed, firefox compiles but does
not install correctly because of missing POSIX timer support in

Quentin Garnier -
The NetBSD Project -

Content-Type: application/pgp-signature

Version: GnuPG v1.2.4 (NetBSD)