Re: Preparation for creating netbsd-7 branch

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Sun, 20 Jul 2014 19:25:53 +0900
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
> - how sysctl hw.machine_arch should be handled
> - different MACHINE_ARCH for kernel and userland should be allowed or not
> - different MACHINE_ARCH should be used for armv4/v6/v7 or not
> - a single kernel should handle different MACHINE_ARCH userland or not
> - should we use different MACHINE_ARCH for softfloat and hardfloat or not
> All of these usages have been changed from other MACHINE_ARCH.
> 
> For the next release, core/releng should decide per current implementation:
> - how the default userland MACHINE_ARCH should be deteremined
> - how to handle migration from old ABI to new one on sysinst
> - which MACHINE_ARCH binaries should be prepared for official packages
> etc. for the new MACHINE_ARCH strategies.

For the record, much of this applies on MIPS as well, especially since
mips64* is softfloat for now. I ran into trouble with mips64eb vs.
mipseb when playing with n32 userland & kernel on sgimips.

have fun
Michael