Re: Preparation for creating netbsd-7 branch

[christos%astron.com@localhost (Christos Zoulas)]

In article <140720192553.M0104576%mirage.ceres.dti.ne.jp@localhost>,
Izumi Tsutsui  <tsutsui%ceres.dti.ne.jp@localhost> wrote:
>
>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.

Please correct me if I am wrong:
- The default userland is selected by installing the toolchain that
  produces that kind of userland. The binaries are "branded" via an
  Elf note that are of this kind of machine arch.
- I am not sure if migration works, but presumably a hardfloat kernel
  should be able to handle softfloat binaries. I.e. recompilation is
  advised, but nothing more.
- Each "MACHINE" should have its default MACHINE_ARCH. This could change
  over time. There are multiple evbarm flavors built for different hardware
  with different capabilities.

christos