Re: MACHINE_ARCH on NetBSD/evbearmv6hf-el current

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> As described in
> http://gnats.netbsd.org/48193
> and
> http://gnats.netbsd.org/48215 .
> 
> 
> pkg_add on NetBSD/evbearm*hf fails with, for example,
> 
> pkg_add: NetBSD/earmv6hf 6.99.23 (pkg) vs. NetBSD/earm 6.99.23 (this host)
> 
> error.
> 
> What is solution?
> This problem discourages my pkgsrc development on Raspberry Pi.

It was broken by matt@ and no response for a month in recent discussion:
 http://mail-index.netbsd.org/tech-userlevel/2013/09/18/msg007954.html

The essencial problem is:

"How to determine whether current environment is hardfloat or softfloat?"

By static MACHINE_ARCH, or dynamic sysctl(3)?
If dynamic sysctl(3) is prefered, which node?


MACHINE_ARCH=earmhf was initially introduced into build.sh and bsd.*.mk:
 http://mail-index.netbsd.org/source-changes/2013/02/03/msg041159.html
 http://mail-index.netbsd.org/source-changes/2013/02/03/msg041160.html
but there was no changes against MACHINE_ARCH values in <machine/param.h>.

This initially caused the problem mentioned in PR/48193
(i.e. inconsistent MACHINE_ARCH between uname(1) and bsd.own.mk):
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/08/msg034148.html

PR/48193 pointed out no hf definitions in MACHINE_ARCH in param.h:
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/10/msg034174.html
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/14/msg034184.html

After that, exec_elf.h was changed to have machine_arch info in the
ELF note:
 http://mail-index.netbsd.org/source-changes/2013/09/10/msg047399.html
 http://mail-index.netbsd.org/source-changes/2013/09/10/msg047400.html
 http://mail-index.netbsd.org/source-changes/2013/09/10/msg047401.html

And sysctl(9) for machine_arch was introduced to return the value
dynamically instead of static MACHINE_ARCH in <machine/param.h>:
 http://mail-index.netbsd.org/source-changes/2013/09/10/msg047416.html
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/14/msg034185.html

But there was a report the above sysctl change didn't help the problem:
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/14/msg034194.html  
 
Then make(1) was changed to use the sysctl machine_arch instead of
MACHINE_ARCH from <machine/param.h>:
 http://mail-index.netbsd.org/source-changes/2013/09/14/msg047577.html

But pkg_add(1) has the same problem as make(1) (i.e. it uses
MACHINE_ARCH from <machine/param.h>):
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034225.html

matt claimed it was a separate issue and PR/48215 was filed:
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034226.html
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034229.html

Then matt also claimed pkg_add(1) problem was a tools issue:
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034230.html

I asked about the strategy how to determine sf or hf:
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034234.html

Then matt claimed his changes solved the PR/48193 and further discussion
should go in tech-* lists instead of gnats:
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034240.html
 http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034244.html 
 
After that removal of MACHINE_ARCH was proposed in tech-userlevel:
 http://mail-index.netbsd.org/tech-userlevel/2013/09/16/msg007949.html 

I replied that it could cause inconsistency (emips is MACHINE_ARCH=mipseb
but softfloat) and it might also require many changes to third party
applications like pkg_add(1):
  http://mail-index.netbsd.org/tech-userlevel/2013/09/18/msg007954.html

Then everything stalls.


All these MACHINE_ARCH=earmhf* changes were committed without discussion,
and it looks all changes were introduced without proper considerations.
(though I don't know if changes by core members need prior approvals or not)

---
Izumi Tsutsui