Hello, On Sun, 20 Jul 2014 19:25:53 +0900 Izumi Tsutsui <tsut...@ceres.dti.ne.jp> wrote:
> christos@ wrote: > > > On Jul 20, 3:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: > > -- Subject: Re: Preparation for creating netbsd-7 branch > > > > | christos@ wrote: > > | > > | > In article <140719232527.m0121...@mirage.ceres.dti.ne.jp>, > > | > Izumi Tsutsui <tsut...@ceres.dti.ne.jp> 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
