Re: Preparation for creating netbsd-7 branch

[Matt Thomas <matt%3am-software.com@localhost>]

On Jul 20, 2014, at 3:25 AM, Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> 
wrote:

> christos@ wrote:
> 
>> On Jul 20,  3:50am, tsutsui%ceres.dti.ne.jp@localhost (Izumi Tsutsui) wrote:
>> -- Subject: Re: Preparation for creating netbsd-7 branch
>> 
>> | christos@ wrote:
>> | 
>> | > In article <140719232527.M0121767%mirage.ceres.dti.ne.jp@localhost>,
>> | > Izumi Tsutsui  <tsutsui%ceres.dti.ne.jp@localhost> wrote:
>> | > >> On behalf of the release engineering team, I am happy to announce 
>> that 
>> | > >> the release process for NetBSD 7.0 is now underway.
>> | > >
>> | > >Does anyone (core? releng?) has a particular plan about
>> | > >the default MACHINE_ARCH for each arm ports?
>> | > 
>> | > Let's discuss it. What do you propose?
>> | 
>> | I asked matt@ on port-arm last year and got no answer.
>> | http://mail-index.netbsd.org/port-arm/2013/10/26/msg002073.html
>> | I think (other) Core members should handle it.
>> 
>> Yes, I've been trying to follow that thread. Can you please summarize
>> the problem and propose a solution? Is it a backwards compatibility issue?
>> Or do we need to worry about binaries produced with sf on hf able machines
>> in the future? Why would one do that? To be compatible with old machines?
> 
> The main problem is lack of design description with random changes.
> http://mail-index.netbsd.org/port-arm/2013/10/26/msg002069.html
> http://mail-index.netbsd.org/port-arm/2013/10/27/msg002075.html
> Without specification, no idea what is intentional and what is broken.
> 
> Anyway, most concerns are too late to discuss.
> - MACHINE_ARCH should be static or dynamic

If you include <sys/param.h>, you (almost) get the right MACHINE_ARCH 
definition.
The exception is that earmv5{,hf}{,eb} looks like earm{,hf}{,eb}.  

> - how sysctl hw.machine_arch should be handled

Right now it return the MACHINE_ARCH the executable was built for via an ELF 
note.

> - different MACHINE_ARCH for kernel and userland should be allowed or not

Of course it should.  If you have FPU_VFP enabled kernel, you can either 
softfloat or hardfloat userland or both (via chroot or MKCOMPAT (TBD)).  You 
don't have FPU_VFP in your kernel, you must run a softfloat kernel since there 
is no emulation of VFP instructions.

> - different MACHINE_ARCH should be used for armv4/v6/v7 or not

Absolutely.  You can't run an earmv7 on earmv6 or before.  You default to just 
earm but you lose efficiency and performance.  An earmv7hf userland is much 
faster on an armv7 cpu than a earm{,hf} userland.  

> - a single kernel should handle different MACHINE_ARCH userland or not

This more dependent on the CPU that the kernel.  A shark/cats must run a earmv4 
kernel and userland since it can't execute the instructions present in earmv5+ 
executables.  The same goes earmv5 and earmv[67] executables.  The point is to 
build the best performing userland for your CPU/SOC.  RPIs need all the help 
they can get. :)

> - should we use different MACHINE_ARCH for softfloat and hardfloat or not

Absolutely.  The ABIs are different.  You can't run a softfloat program with a 
hardfloat libc since libc is missing the softfloat calls.  If you use a 
hardfloat programs with softfloat libraries, floating point values won't be 
passed compatibly.  A different ABI means a MACHINE_ARCH.  It is a travesty 
that we never forced new MACHINE_ARCH for softfloat/hardfloat for other 
architectures (mips, m68K) to distinguish hardfloat/softfloat.  

Should I have not used a different MACHINE_ARCH for mips64 N32 which is a 
32-bit ABI (with some 64-bit ness) and completely incompatible with O32?

> All of these usages have been changed from other MACHINE_ARCH.

Because they were broken.  Just because we didn't do the right thing for them 
doesn't mean we should continue to do the wrong thing in the future.  With 
earm, I could fix that mistake and I did.

> For the next release, core/releng should decide per current implementation:
> - how the default userland MACHINE_ARCH should be deteremined

What do you mean by default?  For evbarm/cats/shark/etc. the MACHINE_ARCH is 
determined by what parameters you supply to build.sh (allowed -m shortcuts like 
ecats/eshark/evbearmv7hf-el, etc).

This is evbmips64-el .vs. evbmips-el.  

> - how to handle migration from old ABI to new one on sysinst

In essence, this is no different from upgrading an i386 userland to an amd64 
userland.

> - which MACHINE_ARCH binaries should be prepared for official packages
> etc. for the new MACHINE_ARCH strategies.

I have not seen an ARMv6 or ARMv7 machine without floating point yet.

A few things: As long as all your programs/libraries use the same float model 
and also use instructions that your CPU supports, mixing earmhf with earmv6hf 
and earmv7hf programs/libraries is completely fine.  But using the 
appropriately complied programs/libraries for your CPU will give the best 
performance.

If you want maximum compatibility with performance loss on armv6+ CPUs, use 
earm (which is the default).  (unless you are worried about shark/cats, then 
use earmv4).
If you want maximum performance, then use the appropriate MACHINE_ARCH for your 
platform.

You are making a mountain out of a molehill.  Providing a simple mechanism for 
an optimized userland for an embedded system (which most ARMs are) is a good 
thing.