On Jul 20, 2014, at 3:25 AM, 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 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.
