Re: retiring arm oabi support for new things

["Kulesa, Craig A - (ckulesa)" <ckulesa%email.arizona.edu@localhost>]

On 2019-10-01 22:55, matthew green wrote:
> hi folks.
> 
> netbsd 9 will ship without any targets with oabi as the
> default, and most of the existing ports were already
> switched to eabi (epoc32 and acorn32 only.)
> 
> as part of this, i'm going to stop providing the ability
> to build any arm with oabi -- turn off the MKCOMPAT for
> all arm ports, so the oabi libraries are not provided
> anymore, turn off the oabi ld.elf.so, etc.
[...]

I've been generating earmv4 builds with MKCOMPAT=no for a while and all 
has been well.  It certainly improves the build times. Standardizing on 
EABI across the board is a coherent approach.

On a related note, however, the organization for 9.0 creates some 
inconsistency.  Inside the evbarm-earm builds, we are generating certain 
earmv4 kernels and install images for (formerly OABI) systems.  These 
systems can't use any of the generated sets, since earm builds use armv5 
instructions.

What's the right way to proceed?

- Amend the evbarm-earm installation documentation to indicate that the 
armv4 systems should install binary sets from one of the dedicated 
earmv4 ports like hpcarm or shark, and not evbarm-earm?

- Make earm compile to armv4(t) instructions so that everything with 
kernels in evbarm-earm can happily use the sets from the build?

- Remove earmv4 kernels from evbarm-earm; make earmv4 users do their own 
builds?

I would understand if folks want to push for the 3rd approach.  But I 
was excited to see EABI binaries for older hardware emerging in 9.0.

Craig