Re: Branching delayed (was Re: Preparation for creating netbsd-7 branch)
On 7/25/14 11:07 PM, Jeff Rizzo wrote: On 7/13/14, 12:11 PM, Jeff Rizzo wrote: On behalf of the release engineering team, I am happy to announce that the release process for NetBSD 7.0 is now underway. We will be creating the netbsd-7 CVS branch on or about July 26th, just under two weeks from today. The creation of this branch will mark the start of the Beta period, which is expected to last into September. Between now and branch time, our focus is on fixing bugs, updating documentation, and ensuring that the basics (build, installation, boot) work on as many platforms as possible. The branch creation will be pushed back by a week, or possibly two - there's some good work happening that we're trying to get finished before we're at a good place to branch. Lots of good progress has been made - expect the branch to be created within the next 2 or 3 days. +j
Re: Branching delayed (was Re: Preparation for creating netbsd-7 branch)
On Fri, Aug 08, 2014 at 07:49:56AM -0700, Jeff Rizzo wrote: [...] Lots of good progress has been made - expect the branch to be created within the next 2 or 3 days. Is there chance for dealing with latest Ivy Bridge KMS regressions before branching? Also, if I have understood correctly, Riastradh's mails on tech-kern@ suggests that whole KMS (related to Ivy or not) stuff needs some extra additions to kernel, for example: http://mail-index.netbsd.org/tech-kern/2014/07/23/msg017392.html Regards, -- Piotr 'aniou' Meyer
Re: Branching delayed (was Re: Preparation for creating netbsd-7 branch)
On 8/8/14 10:29 AM, Piotr Meyer wrote: On Fri, Aug 08, 2014 at 07:49:56AM -0700, Jeff Rizzo wrote: [...] Lots of good progress has been made - expect the branch to be created within the next 2 or 3 days. Is there chance for dealing with latest Ivy Bridge KMS regressions before branching? Also, if I have understood correctly, Riastradh's mails on tech-kern@ suggests that whole KMS (related to Ivy or not) stuff needs some extra additions to kernel, for example: http://mail-index.netbsd.org/tech-kern/2014/07/23/msg017392.html Regards, The KMS stuff will be in NetBSD-7; our primary goal prior to branch is to have all the infrastructure in-place, not necessarily to have all the bugs fixed. That's what the beta is for! :) All the code and build mechanisms for the KMS drivers are imported and in-place; hopefully during the beta period existing bugs will get fixed.
Branching delayed (was Re: Preparation for creating netbsd-7 branch)
On 7/13/14, 12:11 PM, Jeff Rizzo wrote: On behalf of the release engineering team, I am happy to announce that the release process for NetBSD 7.0 is now underway. We will be creating the netbsd-7 CVS branch on or about July 26th, just under two weeks from today. The creation of this branch will mark the start of the Beta period, which is expected to last into September. Between now and branch time, our focus is on fixing bugs, updating documentation, and ensuring that the basics (build, installation, boot) work on as many platforms as possible. The branch creation will be pushed back by a week, or possibly two - there's some good work happening that we're trying to get finished before we're at a good place to branch.
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
On Thu, 24 Jul 2014, Jeff Rizzo wrote:
(Please keep me on the cc: when replying, otherwise we get 24-hour
lags such as this waiting for me to check list mail again)
OK.
... I'd keep the new ALIAS=evbearm* and remove the old ALIAS=evbarm*
lines, not provide both.
This ^^^ is actually why I have two aliase, because I personally
would keep the evbarm* style ones (since that's the port name) while
removing the evbearm* style ones, now that earm is the default.
I don't care which of the two you keep, but I think it's ugly to
have two aliases that mean the same thing.
If backward compatibility in alias names is important, then let's
at least invent a DEPRECATED keyword to mark the old aliases, or
use OALIAS= instead of ALIAS=. Adding a new keyword will not
require code changes, whereas adding OALIAS= will require a small
patch, such as the attached.
--apb (Alan Barrett)
Index: build.sh
===
--- build.sh6 Jul 2014 18:04:44 - 1.285
+++ build.sh25 Jul 2014 07:25:58 -
@@ -578,7 +578,8 @@ initdefaults()
#
# Each line contains a MACHINE and MACHINE_ARCH value, an optional ALIAS
# which may be used to refer to the MACHINE/MACHINE_ARCH pair, and an
-# optional DEFAULT or NO_DEFAULT keyword.
+# optional DEFAULT or NO_DEFAULT keyword. OALIAS works just like ALIAS,
+# but is for obsolete or deprecated aliases that may be removed in future.
#
# When a MACHINE corresponds to multiple possible values of
# MACHINE_ARCH, then this table should list all allowed combinations.
@@ -727,6 +728,12 @@ getarch()
found=$line
break
;;
+ * OALIAS=${MACHINE} *)
+ # Found a line with a matching OALIAS=alias.
+ warning Machine alias '${MACHINE}' is deprecated.
+ found=$line
+ break
+ ;;
MACHINE=${MACHINE} * NO_DEFAULT*)
# Found an explicit NO_DEFAULT for this MACHINE.
found=$line
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
Would it be a problem for you if the alias names were changed? --apb (Alan Barrett) Not at all- I'll just regenerate my scripts. I was concerned that the aliases would be removed period because technically they're redundant. The aliases however, make generating my scripts easier.
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
On 7/25/14, 12:28 AM, Alan Barrett wrote: I don't care which of the two you keep, but I think it's ugly to have two aliases that mean the same thing. After thinking about it some more, I've adopted your original suggestion. Here's what I want to commit, probably tomorrow. Index: build.sh === RCS file: /cvsroot/src/build.sh,v retrieving revision 1.285 diff -u -r1.285 build.sh --- build.sh6 Jul 2014 18:04:44 - 1.285 +++ build.sh26 Jul 2014 00:23:41 - @@ -602,17 +602,17 @@ MACHINE=arcMACHINE_ARCH=mipsel DEFAULT MACHINE=atari MACHINE_ARCH=m68k MACHINE=bebox MACHINE_ARCH=powerpc -MACHINE=cats MACHINE_ARCH=armDEFAULT -MACHINE=cats MACHINE_ARCH=earmv4 ALIAS=ecats +MACHINE=cats MACHINE_ARCH=armALIAS=ocats +MACHINE=cats MACHINE_ARCH=earmv4 ALIAS=ecats DEFAULT MACHINE=cesfic MACHINE_ARCH=m68k MACHINE=cobalt MACHINE_ARCH=mips64el ALIAS=cobalt64 MACHINE=cobalt MACHINE_ARCH=mipsel DEFAULT MACHINE=dreamcast MACHINE_ARCH=sh3el MACHINE=emips MACHINE_ARCH=mipseb MACHINE=epoc32 MACHINE_ARCH=arm -MACHINE=evbarm MACHINE_ARCH=armALIAS=evbarm-el DEFAULT -MACHINE=evbarm MACHINE_ARCH=armeb ALIAS=evbarm-eb -MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbearm-el +MACHINE=evbarm MACHINE_ARCH=armALIAS=evboarm-el +MACHINE=evbarm MACHINE_ARCH=armeb ALIAS=evboarm-eb +MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbearm-el DEFAULT MACHINE=evbarm MACHINE_ARCH=earmeb ALIAS=evbearm-eb MACHINE=evbarm MACHINE_ARCH=earmhf ALIAS=evbearmhf-el MACHINE=evbarm MACHINE_ARCH=earmhfeb ALIAS=evbearmhf-eb @@ -642,15 +642,16 @@ MACHINE=ews4800mipsMACHINE_ARCH=mipseb MACHINE=hp300 MACHINE_ARCH=m68k MACHINE=hppa MACHINE_ARCH=hppa -MACHINE=hpcarm MACHINE_ARCH=armDEFAULT +MACHINE=hpcarm MACHINE_ARCH=armALIAS=hpcoarm MACHINE=hpcarm MACHINE_ARCH=earm ALIAS=hpcearm +MACHINE=hpcarm MACHINE_ARCH=earmv4 ALIAS=hpcearmv4 DEFAULT MACHINE=hpcmipsMACHINE_ARCH=mipsel MACHINE=hpcsh MACHINE_ARCH=sh3el MACHINE=i386 MACHINE_ARCH=i386 MACHINE=ia64 MACHINE_ARCH=ia64 MACHINE=ibmnws MACHINE_ARCH=powerpc -MACHINE=iyonix MACHINE_ARCH=armDEFAULT -MACHINE=iyonix MACHINE_ARCH=earm ALIAS=eiyonix +MACHINE=iyonix MACHINE_ARCH=armALIAS=oiyonix +MACHINE=iyonix MACHINE_ARCH=earm ALIAS=eiyonix DEFAULT MACHINE=landiskMACHINE_ARCH=sh3el MACHINE=luna68kMACHINE_ARCH=m68k MACHINE=mac68k MACHINE_ARCH=m68k @@ -660,8 +661,8 @@ MACHINE=mmeye MACHINE_ARCH=sh3eb MACHINE=mvme68kMACHINE_ARCH=m68k MACHINE=mvmeppcMACHINE_ARCH=powerpc -MACHINE=netwinder MACHINE_ARCH=armDEFAULT -MACHINE=netwinder MACHINE_ARCH=earmv4 ALIAS=enetwinder +MACHINE=netwinder MACHINE_ARCH=armALIAS=onetwinder +MACHINE=netwinder MACHINE_ARCH=earmv4 ALIAS=enetwinder DEFAULT MACHINE=news68kMACHINE_ARCH=m68k MACHINE=newsmips MACHINE_ARCH=mipseb MACHINE=next68kMACHINE_ARCH=m68k @@ -680,16 +681,16 @@ MACHINE=sbmips MACHINE_ARCH=mipsel ALIAS=sbmips-el MACHINE=sgimipsMACHINE_ARCH=mips64eb ALIAS=sgimips64 MACHINE=sgimipsMACHINE_ARCH=mipseb DEFAULT -MACHINE=shark MACHINE_ARCH=armDEFAULT -MACHINE=shark MACHINE_ARCH=earmv4 ALIAS=eshark +MACHINE=shark MACHINE_ARCH=armALIAS=oshark +MACHINE=shark MACHINE_ARCH=earmv4 ALIAS=eshark DEFAULT MACHINE=sparc MACHINE_ARCH=sparc MACHINE=sparc64MACHINE_ARCH=sparc64 MACHINE=sun2 MACHINE_ARCH=m68000 MACHINE=sun3 MACHINE_ARCH=m68k MACHINE=vaxMACHINE_ARCH=vax MACHINE=x68k MACHINE_ARCH=m68k -MACHINE=zaurus MACHINE_ARCH=armDEFAULT -MACHINE=zaurus MACHINE_ARCH=earm ALIAS=ezaurus +MACHINE=zaurus MACHINE_ARCH=armALIAS=ozaurus +MACHINE=zaurus MACHINE_ARCH=earm ALIAS=ezaurus DEFAULT ' # getarch -- find the default MACHINE_ARCH for a MACHINE,
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
(Please keep me on the cc: when replying, otherwise we get 24-hour lags such as this waiting for me to check list mail again) On 7/23/14, 12:10 PM, Alan Barrett wrote: On Wed, 23 Jul 2014, Jeff Rizzo wrote: Attached is the proposed diff to build.sh with the changes, including hpcarm - MACHINE_ARCH=earmv4 . This patch introduces many cases in which the same MACHINE/MACHINE_ARCH pair is listed under more than one ALIAS. I don't see the point of that. To forestall complaints of the form, the name I used to use no longer works, and it's not clear what new one I should use. Aliases are primarily useful as a shorthand for people who run build.sh, and such people can be expected to adapt to changed alias names or changed defaults, without needing both old and new alias names to refer to identical MACHINE/MACHINE_ARCH pairs. OK, aliases are also usable with kver(8) from pkgsrc/devel/libkver, which contains a cut and pasted copy of the part of build.sh that deals with MACHINE/MACHINE_ARCH/ALIAS parsing, but kver uses are so specialised that I don't think we need backward compatible aliases there either. For example, in this list ... -MACHINE=evbarmMACHINE_ARCH=arm ALIAS=evbarm-elDEFAULT -MACHINE=evbarmMACHINE_ARCH=armebALIAS=evbarm-eb +MACHINE=evbarmMACHINE_ARCH=armALIAS=evboarm-el +MACHINE=evbarmMACHINE_ARCH=armebALIAS=evboarm-eb +MACHINE=evbarmMACHINE_ARCH=earmALIAS=evbarm-el DEFAULT MACHINE=evbarmMACHINE_ARCH=earmALIAS=evbearm-el +MACHINE=evbarmMACHINE_ARCH=earmebALIAS=evbarm-eb MACHINE=evbarmMACHINE_ARCH=earmebALIAS=evbearm-eb +MACHINE=evbarmMACHINE_ARCH=earmhfALIAS=evbarmhf-el MACHINE=evbarmMACHINE_ARCH=earmhfALIAS=evbearmhf-el +MACHINE=evbarmMACHINE_ARCH=earmhfeb ALIAS=evbarmhf-eb MACHINE=evbarmMACHINE_ARCH=earmhfeb ALIAS=evbearmhf-eb +MACHINE=evbarmMACHINE_ARCH=earmv4ALIAS=evbarmv4-el MACHINE=evbarmMACHINE_ARCH=earmv4ALIAS=evbearmv4-el +MACHINE=evbarmMACHINE_ARCH=earmv4eb ALIAS=evbarmv4-eb MACHINE=evbarmMACHINE_ARCH=earmv4eb ALIAS=evbearmv4-eb +MACHINE=evbarmMACHINE_ARCH=earmv5ALIAS=evbarmv5-el MACHINE=evbarmMACHINE_ARCH=earmv5ALIAS=evbearmv5-el +MACHINE=evbarmMACHINE_ARCH=earmv5eb ALIAS=evbarmv5-eb MACHINE=evbarmMACHINE_ARCH=earmv5eb ALIAS=evbearmv5-eb +MACHINE=evbarmMACHINE_ARCH=earmv6ALIAS=evbarmv6-el MACHINE=evbarmMACHINE_ARCH=earmv6ALIAS=evbearmv6-el +MACHINE=evbarmMACHINE_ARCH=earmv6hf ALIAS=evbarmv6hf-el MACHINE=evbarmMACHINE_ARCH=earmv6hf ALIAS=evbearmv6hf-el +MACHINE=evbarmMACHINE_ARCH=earmv6eb ALIAS=evbarmv6-eb MACHINE=evbarmMACHINE_ARCH=earmv6eb ALIAS=evbearmv6-eb +MACHINE=evbarmMACHINE_ARCH=earmv6hfeb ALIAS=evbarmv6hf-eb MACHINE=evbarmMACHINE_ARCH=earmv6hfeb ALIAS=evbearmv6hf-eb +MACHINE=evbarmMACHINE_ARCH=earmv7ALIAS=evbarmv7-el MACHINE=evbarmMACHINE_ARCH=earmv7ALIAS=evbearmv7-el +MACHINE=evbarmMACHINE_ARCH=earmv7eb ALIAS=evbarmv7-eb MACHINE=evbarmMACHINE_ARCH=earmv7eb ALIAS=evbearmv7-eb +MACHINE=evbarmMACHINE_ARCH=earmv7hf ALIAS=evbarmv7hf-el MACHINE=evbarmMACHINE_ARCH=earmv7hf ALIAS=evbearmv7hf-el +MACHINE=evbarmMACHINE_ARCH=earmv7hfeb ALIAS=evbarmv7hf-eb MACHINE=evbarmMACHINE_ARCH=earmv7hfeb ALIAS=evbearmv7hf-eb ... I'd keep the new ALIAS=evbearm* and remove the old ALIAS=evbarm* lines, not provide both. This ^^^ is actually why I have two aliase, because I personally would keep the evbarm* style ones (since that's the port name) while removing the evbearm* style ones, now that earm is the default. That said, if people don't care about aliases, I can remove them. --apb (Alan Barrett) +j
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
Accidentally forgot to Cc: the mailing list... whoops! -Original Message- From: William D. Jones Sent: Thursday, July 24, 2014 10:55 PM To: Jeff Rizzo Subject: Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch) That said, if people don't care about aliases, I can remove them. +j I happen to use the aliases to simplify generation of a build.sh wrapper using m4 (although if necessary I could run etcmanage on my cross compiling machine). See: https://gist.github.com/cr1901/07b8e6810caedc31fe7c -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client. -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
On Tue, 22 Jul 2014, Robert Swindells wrote: I would prefer hpcarm to switch to MACHINE_ARCH=earmv4 Currently, build.sh would reject that as invalid. It knows the following MACHINE/MACHINE_ARCH settings for hpcarm: MACHINE=hpcarm MACHINE_ARCH=armDEFAULT MACHINE=hpcarm MACHINE_ARCH=earm ALIAS=hpcearm If you want earmv4 to be the default, you could change those lines, perhaps to something like: MACHINE=hpcarm MACHINE_ARCH=armALIAS=hpcarm-old MACHINE=hpcarm MACHINE_ARCH=earm ALIAS=hpcearm MACHINE=hpcarm MACHINE_ARCH=earmv4 ALIAS=hpcearmv4 DEFAULT The MACHINE_ARCH tagged DEFAULT is used if you run build.sh with -m MACHINE and without -a MACHINE_ARCH. The ALIAS is usable as a shorthand, where running build.sh with -m ALIAS implies -m MACHINE -a MACHINE_ARCH. --apb (Alan Barrett)
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
On 7/22/14, 2:28 PM, Jeff Rizzo wrote: So, what I am proposing: - acorn26, acorn32, epoc32 remain MACHINE_ARCH=arm - cats, netwinder, shark switch to MACHINE_ARCH=earmv4 (rename oabi equiv to ocats, onetwinder, oshark) - hpcarm, iyonix, zaurus switch to MACHINE_ARCH=earm(which is equivalent to earmv5, correct?) - evbarm switch default MACHINE_ARCH=earm, and also build the following MACHINE_ARCHes: * earm, earmeb * earmhf, earmhfeb * earmv6hf * earmv7hf Does this make sense? If so, i'll post a diff with the proposed change to src, and once that's committed, I'll fix up the autobuild. Does anyone have a start at documenting this on the wiki for someone who might actually want to use one of our arm ports? :) +j Attached is the proposed diff to build.sh with the changes, including hpcarm - MACHINE_ARCH=earmv4 . I would like to commit this in the next 48h unless there are objections. Index: build.sh === RCS file: /cvsroot/src/build.sh,v retrieving revision 1.285 diff -u -r1.285 build.sh --- build.sh6 Jul 2014 18:04:44 - 1.285 +++ build.sh23 Jul 2014 18:43:32 - @@ -602,31 +602,47 @@ MACHINE=arcMACHINE_ARCH=mipsel DEFAULT MACHINE=atari MACHINE_ARCH=m68k MACHINE=bebox MACHINE_ARCH=powerpc -MACHINE=cats MACHINE_ARCH=armDEFAULT -MACHINE=cats MACHINE_ARCH=earmv4 ALIAS=ecats +MACHINE=cats MACHINE_ARCH=armALIAS=ocats +MACHINE=cats MACHINE_ARCH=earmv4 ALIAS=ecats DEFAULT MACHINE=cesfic MACHINE_ARCH=m68k MACHINE=cobalt MACHINE_ARCH=mips64el ALIAS=cobalt64 MACHINE=cobalt MACHINE_ARCH=mipsel DEFAULT MACHINE=dreamcast MACHINE_ARCH=sh3el MACHINE=emips MACHINE_ARCH=mipseb MACHINE=epoc32 MACHINE_ARCH=arm -MACHINE=evbarm MACHINE_ARCH=armALIAS=evbarm-el DEFAULT -MACHINE=evbarm MACHINE_ARCH=armeb ALIAS=evbarm-eb +MACHINE=evbarm MACHINE_ARCH=armALIAS=evboarm-el +MACHINE=evbarm MACHINE_ARCH=armeb ALIAS=evboarm-eb +MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbarm-el DEFAULT MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbearm-el +MACHINE=evbarm MACHINE_ARCH=earmeb ALIAS=evbarm-eb MACHINE=evbarm MACHINE_ARCH=earmeb ALIAS=evbearm-eb +MACHINE=evbarm MACHINE_ARCH=earmhf ALIAS=evbarmhf-el MACHINE=evbarm MACHINE_ARCH=earmhf ALIAS=evbearmhf-el +MACHINE=evbarm MACHINE_ARCH=earmhfeb ALIAS=evbarmhf-eb MACHINE=evbarm MACHINE_ARCH=earmhfeb ALIAS=evbearmhf-eb +MACHINE=evbarm MACHINE_ARCH=earmv4 ALIAS=evbarmv4-el MACHINE=evbarm MACHINE_ARCH=earmv4 ALIAS=evbearmv4-el +MACHINE=evbarm MACHINE_ARCH=earmv4eb ALIAS=evbarmv4-eb MACHINE=evbarm MACHINE_ARCH=earmv4eb ALIAS=evbearmv4-eb +MACHINE=evbarm MACHINE_ARCH=earmv5 ALIAS=evbarmv5-el MACHINE=evbarm MACHINE_ARCH=earmv5 ALIAS=evbearmv5-el +MACHINE=evbarm MACHINE_ARCH=earmv5eb ALIAS=evbarmv5-eb MACHINE=evbarm MACHINE_ARCH=earmv5eb ALIAS=evbearmv5-eb +MACHINE=evbarm MACHINE_ARCH=earmv6 ALIAS=evbarmv6-el MACHINE=evbarm MACHINE_ARCH=earmv6 ALIAS=evbearmv6-el +MACHINE=evbarm MACHINE_ARCH=earmv6hf ALIAS=evbarmv6hf-el MACHINE=evbarm MACHINE_ARCH=earmv6hf ALIAS=evbearmv6hf-el +MACHINE=evbarm MACHINE_ARCH=earmv6eb ALIAS=evbarmv6-eb MACHINE=evbarm MACHINE_ARCH=earmv6eb ALIAS=evbearmv6-eb +MACHINE=evbarm MACHINE_ARCH=earmv6hfeb ALIAS=evbarmv6hf-eb MACHINE=evbarm MACHINE_ARCH=earmv6hfeb ALIAS=evbearmv6hf-eb +MACHINE=evbarm MACHINE_ARCH=earmv7 ALIAS=evbarmv7-el MACHINE=evbarm MACHINE_ARCH=earmv7 ALIAS=evbearmv7-el +MACHINE=evbarm MACHINE_ARCH=earmv7eb ALIAS=evbarmv7-eb MACHINE=evbarm MACHINE_ARCH=earmv7eb ALIAS=evbearmv7-eb +MACHINE=evbarm MACHINE_ARCH=earmv7hf ALIAS=evbarmv7hf-el MACHINE=evbarm MACHINE_ARCH=earmv7hf ALIAS=evbearmv7hf-el +MACHINE=evbarm MACHINE_ARCH=earmv7hfeb ALIAS=evbarmv7hf-eb MACHINE=evbarm MACHINE_ARCH=earmv7hfeb ALIAS=evbearmv7hf-eb MACHINE=evbcf MACHINE_ARCH=coldfire MACHINE=evbmipsMACHINE_ARCH= NO_DEFAULT @@ -642,15 +658,16 @@ MACHINE=ews4800mipsMACHINE_ARCH=mipseb MACHINE=hp300 MACHINE_ARCH=m68k MACHINE=hppa MACHINE_ARCH=hppa -MACHINE=hpcarm MACHINE_ARCH=armDEFAULT +MACHINE=hpcarm MACHINE_ARCH=armALIAS=hpcoarm MACHINE=hpcarm MACHINE_ARCH=earm ALIAS=hpcearm +MACHINE=hpcarm MACHINE_ARCH=earmv4 ALIAS=hpcearmv4 DEFAULT MACHINE=hpcmipsMACHINE_ARCH=mipsel MACHINE=hpcsh MACHINE_ARCH=sh3el MACHINE=i386 MACHINE_ARCH=i386 MACHINE=ia64 MACHINE_ARCH=ia64
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
On Wed, 23 Jul 2014, Jeff Rizzo wrote: Attached is the proposed diff to build.sh with the changes, including hpcarm - MACHINE_ARCH=earmv4 . This patch introduces many cases in which the same MACHINE/MACHINE_ARCH pair is listed under more than one ALIAS. I don't see the point of that. Aliases are primarily useful as a shorthand for people who run build.sh, and such people can be expected to adapt to changed alias names or changed defaults, without needing both old and new alias names to refer to identical MACHINE/MACHINE_ARCH pairs. OK, aliases are also usable with kver(8) from pkgsrc/devel/libkver, which contains a cut and pasted copy of the part of build.sh that deals with MACHINE/MACHINE_ARCH/ALIAS parsing, but kver uses are so specialised that I don't think we need backward compatible aliases there either. For example, in this list ... -MACHINE=evbarm MACHINE_ARCH=armALIAS=evbarm-el DEFAULT -MACHINE=evbarm MACHINE_ARCH=armeb ALIAS=evbarm-eb +MACHINE=evbarm MACHINE_ARCH=armALIAS=evboarm-el +MACHINE=evbarm MACHINE_ARCH=armeb ALIAS=evboarm-eb +MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbarm-el DEFAULT MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbearm-el +MACHINE=evbarm MACHINE_ARCH=earmeb ALIAS=evbarm-eb MACHINE=evbarm MACHINE_ARCH=earmeb ALIAS=evbearm-eb +MACHINE=evbarm MACHINE_ARCH=earmhf ALIAS=evbarmhf-el MACHINE=evbarm MACHINE_ARCH=earmhf ALIAS=evbearmhf-el +MACHINE=evbarm MACHINE_ARCH=earmhfeb ALIAS=evbarmhf-eb MACHINE=evbarm MACHINE_ARCH=earmhfeb ALIAS=evbearmhf-eb +MACHINE=evbarm MACHINE_ARCH=earmv4 ALIAS=evbarmv4-el MACHINE=evbarm MACHINE_ARCH=earmv4 ALIAS=evbearmv4-el +MACHINE=evbarm MACHINE_ARCH=earmv4eb ALIAS=evbarmv4-eb MACHINE=evbarm MACHINE_ARCH=earmv4eb ALIAS=evbearmv4-eb +MACHINE=evbarm MACHINE_ARCH=earmv5 ALIAS=evbarmv5-el MACHINE=evbarm MACHINE_ARCH=earmv5 ALIAS=evbearmv5-el +MACHINE=evbarm MACHINE_ARCH=earmv5eb ALIAS=evbarmv5-eb MACHINE=evbarm MACHINE_ARCH=earmv5eb ALIAS=evbearmv5-eb +MACHINE=evbarm MACHINE_ARCH=earmv6 ALIAS=evbarmv6-el MACHINE=evbarm MACHINE_ARCH=earmv6 ALIAS=evbearmv6-el +MACHINE=evbarm MACHINE_ARCH=earmv6hf ALIAS=evbarmv6hf-el MACHINE=evbarm MACHINE_ARCH=earmv6hf ALIAS=evbearmv6hf-el +MACHINE=evbarm MACHINE_ARCH=earmv6eb ALIAS=evbarmv6-eb MACHINE=evbarm MACHINE_ARCH=earmv6eb ALIAS=evbearmv6-eb +MACHINE=evbarm MACHINE_ARCH=earmv6hfeb ALIAS=evbarmv6hf-eb MACHINE=evbarm MACHINE_ARCH=earmv6hfeb ALIAS=evbearmv6hf-eb +MACHINE=evbarm MACHINE_ARCH=earmv7 ALIAS=evbarmv7-el MACHINE=evbarm MACHINE_ARCH=earmv7 ALIAS=evbearmv7-el +MACHINE=evbarm MACHINE_ARCH=earmv7eb ALIAS=evbarmv7-eb MACHINE=evbarm MACHINE_ARCH=earmv7eb ALIAS=evbearmv7-eb +MACHINE=evbarm MACHINE_ARCH=earmv7hf ALIAS=evbarmv7hf-el MACHINE=evbarm MACHINE_ARCH=earmv7hf ALIAS=evbearmv7hf-el +MACHINE=evbarm MACHINE_ARCH=earmv7hfeb ALIAS=evbarmv7hf-eb MACHINE=evbarm MACHINE_ARCH=earmv7hfeb ALIAS=evbearmv7hf-eb ... I'd keep the new ALIAS=evbearm* and remove the old ALIAS=evbarm* lines, not provide both. --apb (Alan Barrett)
Re: Preparation for creating netbsd-7 branch - tmux
Any chance of importing the latest version of /usr/bin/tmux before the branch? We have 1.5, there is a 1.9a. It is available in pkgsrc, but they are not compatible with each other. That means that if you are running the base system version, there is no point in installing the pkgsrc version, because you can't use both at the same time. In other words, you'll have to terminate all your running sessions - a better moment for that is when you need to reboot for a system upgrade anyway. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgp0XKCuipj6m.pgp Description: PGP signature
Re: Preparation for creating netbsd-7 branch
Hi all, To give a user's perspective, I'd like to comment on a couple of items in the thread so far. Christos Zoulas wrote: 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? Someone like myself could need to move from the old evbarm to something else, e.g. on a Raspberry Pi, from evbarm to evbearmv6hf-el, which means they're going from soft float to hard float, and from OABI to EABI. The method to do so isn't documented anywhere (to my knowledge). There are also users trying to run current pkgsrc builds for evbarm on other variants.[1] (That could of course disappear if pkgsrc builds changed to match the new defaults.) I'd seen correspondence on port-arm about compatibility being offered via COMPAT_NETBSD32, though it was unclear what the extent of that is.[2] I think I'd misunderstood things, as I'd tried to help another user and it wasn't working as I'd thought. I'd opened a PR[3] seeking to improve the COMPAT_NETBSD32 man page, with the intent of documenting just what it does for ARM, but I hadn't yet approached any of the developers for help with the explanation. Nick Hudson wrote: Something (build.sh/wiki/both) can document each evbarm board to the correct MACHINE_ARCH variant based could then be provided. build.sh already contains useful information here From what I can see, traditionally the BUILDING document covers this information. (Well, not matching boards to aliases, but listing the various aliases.) However, it is rather out of date compared to build.sh, and not just for ARM ports. (As I think everyone here is already aware.) I'd submitted a PR[4] to try and bring the existing extent of the documentation up to date (as well as provide a few unrelated amendments). To avoid the overhead of maintaining documentation separately, the existing information in BUILDING could be removed and an option and function could be added to the build.sh script that would output the table, with users being directed there from BUILDING. (Or something else, but the existing documentation is inadequate for a number of ports.) I understand that writing documentation can often lag development efforts, but it would be unfortunate if users can't appreciate all the work developers have put in. (Well, I realize no one's doing this for fame, but...) References: 1. http://mail-index.netbsd.org/current-users/2014/07/17/msg025274.html 2. http://mail-index.netbsd.org/port-arm/2014/04/07/msg002350.html 3. http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48968 4. http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48741 Regards, Dave
Re: Preparation for creating netbsd-7 branch
matt@ wrote: What about acorn26 and acorn32? Are you willing to step up and fix any apcs32 bugs in gcc? I have no idea if acorn26 still runs (I've made a significant effort to ensure it does). It would greatly simplify the ARM world if it would just die. :) acorn32 uses an armv3 processor which I have no idea if EABI supports. earmv3 anyone? Anyone willing to give it a shot? How many machines running out there run NetBSD? If there are more acorn26 machines than I can count with my thumbs, I'd be surprised. acorn32? Single digits? Sometimes you just have to say goodbye (pc532) to a supported platform. Removal of ports should be handled by Core, and you are a member of Core group. Why didn't you propose the removal in the Core's meeting etc. when you dicided to purge old arm ABI? Anyway, lack of documentation is still the serious problem. I am exactly the wrong person to write it. I know the space intimately so I don't know what a new person needs to know because it would never occur to me. If you would not like to handle such non-technical matters (release binary builds, upgrade mechanism etc.) at all, you should always have got prior approvals from persons who will work on such dumb items you don't like. Otherwise release users will get useless binaries like mips ports in 6.0 release. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
On Mon, Jul 21, 2014 at 09:50:41PM +0200, Manuel Bouyer wrote: [...] I tested earmhf vs earmv7hf on the beaglebone black. with glxgears, the performance improvement is less than 1%. Do you have other tests that show a large gain with earmv7hf vs earmhf ? For 1% I don't think we should bother providing all of earmhf, earmv6hf and earmv7hf. I rebuilt a distribution; this time with build.sh -m evbarm -a earmv7hf -V CPUFLAGS=-mcpu=cortex-a8 -mtune=cortex-a8 -mfpu=neon -funsafe-math-optimizations Now glxgears shows a real improvement over earmhf; from about 24.8FPS to 25.8FPS (this would be about 4%). But we probably don't want to provide evbarm binaries with such CPU-specific compilation options (-funsafe-math-optimizations may also be a problem for some use case). -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: Preparation for creating netbsd-7 branch
On Mon, Jul 21, 2014 at 05:57:52PM +0200, Joerg Sonnenberger wrote: Preparing and testing such upgrade mechanism would be a bit boring work (there are few developers who care releases and sysinst itself) so I'm afraid no one will take it... For the ones in base, compat versions should exist in /usr/lib/XXX. Redirection magic exists. Not for old versions of libs. (Also, last I checked, sufficiently old i386 bins don't run on amd64 because COMPAT_xx for old xx isn't present.) -- David A. Holland dholl...@netbsd.org
Re: Preparation for creating netbsd-7 branch
On Tue, Jul 22, 2014 at 04:44:00PM +, David Holland wrote: On Mon, Jul 21, 2014 at 05:57:52PM +0200, Joerg Sonnenberger wrote: Preparing and testing such upgrade mechanism would be a bit boring work (there are few developers who care releases and sysinst itself) so I'm afraid no one will take it... For the ones in base, compat versions should exist in /usr/lib/XXX. Redirection magic exists. Not for old versions of libs. (Also, last I checked, sufficiently old i386 bins don't run on amd64 because COMPAT_xx for old xx isn't present.) Old versions are not touched by the upgrade process either, so they just remain. Joerg
ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
On 7/21/14, 4:28 AM, Nick Hudson wrote: IMO, non-earm ABI builds should be dropped in favour of earm and a subset of evbarm earm variants should be made available. This seems reasonable, and I am also going to suggest that the defaults change on those ports which are switching to EABI. ie, it seems to me like cats should build MACHINE=cats MACHINE_ARCH=earmv4 while (assuming we're not ripping OABI out) ocats can be an alias for MACHINE=cats MACHINE_ARCH=arm Likewise, evbarm* should change to EABI by default and evboarm* can build for the old ABI Something (build.sh/wiki/both) can document each evbarm board to the correct MACHINE_ARCH variant based could then be provided. build.sh already contains useful information here zoom$ grep earm /usr/src/build.sh MACHINE=catsMACHINE_ARCH=earmv4 ALIAS=ecats MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbearm-el MACHINE=evbarm MACHINE_ARCH=earmeb ALIAS=evbearm-eb MACHINE=evbarm MACHINE_ARCH=earmhf ALIAS=evbearmhf-el MACHINE=evbarm MACHINE_ARCH=earmhfeb ALIAS=evbearmhf-eb MACHINE=evbarm MACHINE_ARCH=earmv4 ALIAS=evbearmv4-el MACHINE=evbarm MACHINE_ARCH=earmv4eb ALIAS=evbearmv4-eb MACHINE=evbarm MACHINE_ARCH=earmv5 ALIAS=evbearmv5-el MACHINE=evbarm MACHINE_ARCH=earmv5eb ALIAS=evbearmv5-eb MACHINE=evbarm MACHINE_ARCH=earmv6 ALIAS=evbearmv6-el MACHINE=evbarm MACHINE_ARCH=earmv6hf ALIAS=evbearmv6hf-el MACHINE=evbarm MACHINE_ARCH=earmv6eb ALIAS=evbearmv6-eb MACHINE=evbarm MACHINE_ARCH=earmv6hfeb ALIAS=evbearmv6hf-eb MACHINE=evbarm MACHINE_ARCH=earmv7 ALIAS=evbearmv7-el MACHINE=evbarm MACHINE_ARCH=earmv7eb ALIAS=evbearmv7-eb MACHINE=evbarm MACHINE_ARCH=earmv7hf ALIAS=evbearmv7hf-el MACHINE=evbarm MACHINE_ARCH=earmv7hfeb ALIAS=evbearmv7hf-eb MACHINE=hpcarm MACHINE_ARCH=earm ALIAS=hpcearm MACHINE=iyonix MACHINE_ARCH=earm ALIAS=eiyonix MACHINE=netwinder MACHINE_ARCH=earmv4 ALIAS=enetwinder MACHINE=shark MACHINE_ARCH=earmv4 ALIAS=eshark MACHINE=zaurus MACHINE_ARCH=earm ALIAS=ezaurus zoom$ The evbarm board information can be derived from http://nxr.netbsd.org/xref/src/etc/etc.evbarm/Makefile.inc Building all arm ports for acorn32 compatibility is madness. So, what I am proposing: - acorn26, acorn32, epoc32 remain MACHINE_ARCH=arm - cats, netwinder, shark switch to MACHINE_ARCH=earmv4 (rename oabi equiv to ocats, onetwinder, oshark) - hpcarm, iyonix, zaurus switch to MACHINE_ARCH=earm(which is equivalent to earmv5, correct?) - evbarm switch default MACHINE_ARCH=earm, and also build the following MACHINE_ARCHes: * earm, earmeb * earmhf, earmhfeb * earmv6hf * earmv7hf Does this make sense? If so, i'll post a diff with the proposed change to src, and once that's committed, I'll fix up the autobuild. Does anyone have a start at documenting this on the wiki for someone who might actually want to use one of our arm ports? :) +j
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
Jeff Rizzo wrote: On 7/21/14, 4:28 AM, Nick Hudson wrote: IMO, non-earm ABI builds should be dropped in favour of earm and a subset of evbarm earm variants should be made available. This seems reasonable, and I am also going to suggest that the defaults change on those ports which are switching to EABI. [snip] So, what I am proposing: - hpcarm, iyonix, zaurus switch to MACHINE_ARCH=earm(which is equivalent to earmv5, correct?) I would prefer hpcarm to switch to MACHINE_ARCH=earmv4 Robert Swindells
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
Jeff Rizzo wrote: On 7/22/14, 2:45 PM, Robert Swindells wrote: I would prefer hpcarm to switch to MACHINE_ARCH=earmv4 Robert Swindells noted. (may have been a transcription error on my part) No, you didn't make an error transcribing it. The current definitions in build.sh are: MACHINE=hpcarm MACHINE_ARCH=armDEFAULT MACHINE=hpcarm MACHINE_ARCH=earm ALIAS=hpcearm I would prefer the EABI definition used to be earmv4 as several of the supported devices are ARMv4 ones. Robert Swindells
Re: Preparation for creating netbsd-7 branch
On Sun, Jul 20, 2014 at 08:45:40PM -0700, Matt Thomas wrote:
[...]
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).
By default, we mean what should show up in
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/
and
ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/
We probably don't have the ressources for providing binaries
for each {,e}arm{,hf} variants.
- 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.
This is something we don't handle at all right now.
--
Manuel Bouyer bou...@antioche.eu.org
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: Preparation for creating netbsd-7 branch
skrll@ wrote: On 07/21/14 06:49, Izumi Tsutsui wrote: matt@ wrote: 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? What (and how) MACHINE_ARCH should releng (binary builders) specify for each arm port on NetBSD 7.0 release? Personally, I hope we'll see builds for most (probably no need for v[67] sf) MACHINE_ARCH values. As matt said the RPI needs all the help it can get :) releng already says we don't have enough resources. - 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. So, your answer is We will never prepare such upgrade path right? I don't know how you got from Matt's statement to your question. I think there are solutions here. Where? There is no upgrade path from i386 to amd64 in sysinst. (we only had a.out to ELF) - 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. It doesn't answer the question at all. The question is which MACHINE_ARCH. I think the answer is the best one for your hardware. I'm asking about for official packages, not mine. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
On Mon, Jul 21, 2014 at 06:25:07PM +0900, Izumi Tsutsui wrote: There is no upgrade path from i386 to amd64 in sysinst. (we only had a.out to ELF) How much of an upgrade path do you need? Remove /dev, install sets as usual, rerun MAKEDEV should be enough... Joerg
Re: Preparation for creating netbsd-7 branch
On Mon, Jul 21, 2014 at 09:44:35AM +0200, Manuel Bouyer wrote:
We probably don't have the ressources for providing binaries
for each {,e}arm{,hf} variants.
We should only provide earm variants, and then there are not many relevant
combinations.
However, the question of a decent upgrade path from oabi to eabi has
to be solved.
Martin
Re: Preparation for creating netbsd-7 branch
On 07/21/14 10:25, Izumi Tsutsui wrote: skrll@ wrote: On 07/21/14 06:49, Izumi Tsutsui wrote: matt@ wrote: 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? What (and how) MACHINE_ARCH should releng (binary builders) specify for each arm port on NetBSD 7.0 release? Personally, I hope we'll see builds for most (probably no need for v[67] sf) MACHINE_ARCH values. As matt said the RPI needs all the help it can get :) releng already says we don't have enough resources. Really? Where did releng say that? IMO, non-earm ABI builds should be dropped in favour of earm and a subset of evbarm earm variants should be made available. Something (build.sh/wiki/both) can document each evbarm board to the correct MACHINE_ARCH variant based could then be provided. build.sh already contains useful information here zoom$ grep earm /usr/src/build.sh MACHINE=catsMACHINE_ARCH=earmv4 ALIAS=ecats MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbearm-el MACHINE=evbarm MACHINE_ARCH=earmeb ALIAS=evbearm-eb MACHINE=evbarm MACHINE_ARCH=earmhf ALIAS=evbearmhf-el MACHINE=evbarm MACHINE_ARCH=earmhfeb ALIAS=evbearmhf-eb MACHINE=evbarm MACHINE_ARCH=earmv4 ALIAS=evbearmv4-el MACHINE=evbarm MACHINE_ARCH=earmv4eb ALIAS=evbearmv4-eb MACHINE=evbarm MACHINE_ARCH=earmv5 ALIAS=evbearmv5-el MACHINE=evbarm MACHINE_ARCH=earmv5eb ALIAS=evbearmv5-eb MACHINE=evbarm MACHINE_ARCH=earmv6 ALIAS=evbearmv6-el MACHINE=evbarm MACHINE_ARCH=earmv6hf ALIAS=evbearmv6hf-el MACHINE=evbarm MACHINE_ARCH=earmv6eb ALIAS=evbearmv6-eb MACHINE=evbarm MACHINE_ARCH=earmv6hfeb ALIAS=evbearmv6hf-eb MACHINE=evbarm MACHINE_ARCH=earmv7 ALIAS=evbearmv7-el MACHINE=evbarm MACHINE_ARCH=earmv7eb ALIAS=evbearmv7-eb MACHINE=evbarm MACHINE_ARCH=earmv7hf ALIAS=evbearmv7hf-el MACHINE=evbarm MACHINE_ARCH=earmv7hfeb ALIAS=evbearmv7hf-eb MACHINE=hpcarm MACHINE_ARCH=earm ALIAS=hpcearm MACHINE=iyonix MACHINE_ARCH=earm ALIAS=eiyonix MACHINE=netwinder MACHINE_ARCH=earmv4 ALIAS=enetwinder MACHINE=shark MACHINE_ARCH=earmv4 ALIAS=eshark MACHINE=zaurus MACHINE_ARCH=earm ALIAS=ezaurus zoom$ The evbarm board information can be derived from http://nxr.netbsd.org/xref/src/etc/etc.evbarm/Makefile.inc Building all arm ports for acorn32 compatibility is madness. - 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. So, your answer is We will never prepare such upgrade path right? I don't know how you got from Matt's statement to your question. I think there are solutions here. Where? There is no upgrade path from i386 to amd64 in sysinst. (we only had a.out to ELF) Someone(tm) needs to add it. SMOP, right? Nick
Re: Preparation for creating netbsd-7 branch
skrll@ wrote:
On 07/21/14 10:25, Izumi Tsutsui wrote:
skrll@ wrote:
On 07/21/14 06:49, Izumi Tsutsui wrote:
matt@ wrote:
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?
What (and how) MACHINE_ARCH should releng (binary builders) specify
for each arm port on NetBSD 7.0 release?
Personally, I hope we'll see builds for most (probably no need for v[67]
sf) MACHINE_ARCH values. As matt said the RPI needs all the help it can
get :)
releng already says we don't have enough resources.
Really? Where did releng say that?
http://mail-index.netbsd.org/current-users/2014/07/21/msg025327.html
We probably don't have the ressources for providing binaries
for each {,e}arm{,hf} variants.
IMO, non-earm ABI builds should be dropped in favour of earm and a
subset of evbarm earm variants should be made available.
Something (build.sh/wiki/both) can document each evbarm board to the
correct MACHINE_ARCH variant based could then be provided.
build.sh already contains useful information here
zoom$ grep earm /usr/src/build.sh
MACHINE=catsMACHINE_ARCH=earmv4 ALIAS=ecats
MACHINE=evbarm MACHINE_ARCH=earm ALIAS=evbearm-el
MACHINE=evbarm MACHINE_ARCH=earmeb ALIAS=evbearm-eb
MACHINE=evbarm MACHINE_ARCH=earmhf ALIAS=evbearmhf-el
MACHINE=evbarm MACHINE_ARCH=earmhfeb ALIAS=evbearmhf-eb
MACHINE=evbarm MACHINE_ARCH=earmv4 ALIAS=evbearmv4-el
MACHINE=evbarm MACHINE_ARCH=earmv4eb ALIAS=evbearmv4-eb
MACHINE=evbarm MACHINE_ARCH=earmv5 ALIAS=evbearmv5-el
MACHINE=evbarm MACHINE_ARCH=earmv5eb ALIAS=evbearmv5-eb
MACHINE=evbarm MACHINE_ARCH=earmv6 ALIAS=evbearmv6-el
MACHINE=evbarm MACHINE_ARCH=earmv6hf ALIAS=evbearmv6hf-el
MACHINE=evbarm MACHINE_ARCH=earmv6eb ALIAS=evbearmv6-eb
MACHINE=evbarm MACHINE_ARCH=earmv6hfeb ALIAS=evbearmv6hf-eb
MACHINE=evbarm MACHINE_ARCH=earmv7 ALIAS=evbearmv7-el
MACHINE=evbarm MACHINE_ARCH=earmv7eb ALIAS=evbearmv7-eb
MACHINE=evbarm MACHINE_ARCH=earmv7hf ALIAS=evbearmv7hf-el
MACHINE=evbarm MACHINE_ARCH=earmv7hfeb ALIAS=evbearmv7hf-eb
MACHINE=hpcarm MACHINE_ARCH=earm ALIAS=hpcearm
MACHINE=iyonix MACHINE_ARCH=earm ALIAS=eiyonix
MACHINE=netwinder MACHINE_ARCH=earmv4 ALIAS=enetwinder
MACHINE=shark MACHINE_ARCH=earmv4 ALIAS=eshark
MACHINE=zaurus MACHINE_ARCH=earm ALIAS=ezaurus
zoom$
The evbarm board information can be derived from
http://nxr.netbsd.org/xref/src/etc/etc.evbarm/Makefile.inc
Building all arm ports for acorn32 compatibility is madness.
I know it has possible combinations.
My first question is
Which MACHINE_ARCH should be used for each arm port on the next release
It's non-technical, but probably determined by marketing and resources.
Ramdom comments won't help to get a proper conclusion, I'm afraid.
- 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.
So, your answer is
We will never prepare such upgrade path
right?
I don't know how you got from Matt's statement to your question. I think
there are solutions here.
Where?
There is no upgrade path from i386 to amd64 in sysinst.
(we only had a.out to ELF)
Someone(tm) needs to add it. SMOP, right?
Yes. It isn't a technical issue either.
My question to releng/core is
What should be done for the NetBSD 7.0 release?
I'm afraid we can't solve the issue until
the target branch (or even release) date
without proper plan.
---
Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
joerg@ wrote: On Mon, Jul 21, 2014 at 06:25:07PM +0900, Izumi Tsutsui wrote: There is no upgrade path from i386 to amd64 in sysinst. (we only had a.out to ELF) How much of an upgrade path do you need? Remove /dev, install sets as usual, rerun MAKEDEV should be enough... For example, prepare/move old compat libs if users also want to use old binaries? http://nxr.netbsd.org/xref/src/distrib/utils/sysinst/aout2elf.c Preparing and testing such upgrade mechanism would be a bit boring work (there are few developers who care releases and sysinst itself) so I'm afraid no one will take it... --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
It looks most your messages are caught by filter on mail.NetBSD.org host.
Could you check you yahoo mailer settings?
skrll@ wrote:
On 07/21/14 17:25, Izumi Tsutsui wrote:
skrll@ wrote:
On 07/21/14 15:32, Izumi Tsutsui wrote:
skrll@ wrote:
http://mail-index.netbsd.org/current-users/2014/07/21/msg025327.html
We probably don't have the ressources for providing binaries
for each {,e}arm{,hf} variants.
Probably?
Anyway, I don't think anyone is asking for all variants.
Well, I asked to releng/core, and one of releng member answered it.
That's all.
My first question is
Which MACHINE_ARCH should be used for each arm port on the next
release
It's non-technical, but probably determined by marketing and resources.
What's wrong with my suggestion? Feel free to suggest improvements.
You just mentioned possible combinations.
No I didn't.
Let me be more explicit
MACHINE=acorn26MACHINE_ARCH=arm
MACHINE=acorn32MACHINE_ARCH=arm
MACHINE=catsMACHINE_ARCH=earmv4
MACHINE=evbarm MACHINE_ARCH=earmv[67]hf{,eb}
MACHINE=evbarm MACHINE_ARCH=earm{,eb}
MACHINE=netwinder MACHINE_ARCH=earmv4
MACHINE=shark MACHINE_ARCH=earmv4
MACHINE=zaurus MACHINE_ARCH=earm
That is, use earm where possible, no softfloat for v[67].
This is 8 ABI combinations.
- What about epoc32, hpcarm, and iyonix?
I'd guess
MACHINE=epoc32MACHINE_ARCH=arm
MACHINE=hpcarmMACHINE_ARCH=earmv4
MACHINE=iyonix MACHINE_ARCH=earm
Maybe the port-masters/users can test?
Unfortunately all these ports are orphaned.
If not, leave as MACHINE_ARCH=arm
I'd rather suggest to switch to earm only on confirmed ports.
- Have you confirmed cats with earmv4?
(especially ELF to a.out conversion for the Cyclone firmware)
I've been running earmv4 on my cats for a long time now.
Ok, it's fine.
- Does zaurus really work with earm?
In sys/arch/zaurus/stand it builds Linux binaries
and I don't know if we can build it with earm toolchain.
(I was asked it by joerg and answered it, but no further response)
Don't know - maybe the port-masters/users can test. If not, leave as
MACHINE_ARCH=arm
It's also orphaned.
I wonder if it's really worth to introduce new ABI
into ancient Tier-II machines.
---
Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
Izumi Tsutsui wrote: skrll@ wrote: I'd guess MACHINE=hpcarmMACHINE_ARCH=earmv4 Maybe the port-masters/users can test? I can test hpcarm on an iPAQ. Unfortunately all these ports are orphaned. There were updates to hpcarm recently to get it to work on WZERO3 hardware, what is needed for it not to be considered orphaned ? Robert Swindells
Re: Preparation for creating netbsd-7 branch
On Tue, Jul 22, 2014 at 01:15:29AM +0900, Izumi Tsutsui wrote: Well, if you only read the quoted sentence and you are claiming about i386 to amd64 migration, please implement it in sysinst as you like. The problem discussed here is arm to earm (or its variant). Yes, the problem is real and should be solved in release documents or in sysinst. There are basically two options, IMHO: - provide everything we did release in netbsd-6 as arm and earm variant, document how to manually upgrade from old to eabi (it is usually not very hard to do, and many people will prefer all pkgs new over move all old libs to /compat) - minimize the number of binary sets we create for -7 and add support to sysinst to do a proper upgrade (this is not rocket science, but not exactly trivial either) When going with the first option, we should (a) urge new users to use earm variants, and (b) declare deprecation of old abi in the next release. Martin
Re: Preparation for creating netbsd-7 branch
rjs@ wrote: Izumi Tsutsui wrote: skrll@ wrote: I'd guess MACHINE=hpcarmMACHINE_ARCH=earmv4 Maybe the port-masters/users can test? I can test hpcarm on an iPAQ. Ok, good to hear. Unfortunately all these ports are orphaned. There were updates to hpcarm recently to get it to work on WZERO3 hardware, what is needed for it not to be considered orphaned ? orphaned means there is no portmainter to make a decision. http://www.netbsd.org/people/port-maintainers.html I have W-ZERO3 and Zaurus machines, but I'm not so motivated because I'm not sure what's the actual benefits and risk/concerns on switching to earm on such XScale generation machines. (most important part is lack of migration method, of course) Is there any documents/articles that describe earm on NetBSD? If not, we won't have enough brave users. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
On Jul 21, 2014, at 10:56 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: rjs@ wrote: Izumi Tsutsui wrote: skrll@ wrote: I'd guess MACHINE=hpcarmMACHINE_ARCH=earmv4 Maybe the port-masters/users can test? I can test hpcarm on an iPAQ. Ok, good to hear. Unfortunately all these ports are orphaned. There were updates to hpcarm recently to get it to work on WZERO3 hardware, what is needed for it not to be considered orphaned ? orphaned means there is no portmainter to make a decision. http://www.netbsd.org/people/port-maintainers.html I have W-ZERO3 and Zaurus machines, but I'm not so motivated because I'm not sure what's the actual benefits and risk/concerns on switching to earm on such XScale generation machines. (most important part is lack of migration method, of course) the default processor for earm was chosen so that xscale and above would get smaller code and slightly higher performance. Is there any documents/articles that describe earm on NetBSD? If not, we won't have enough brave users. The fact that NetBSD is finally using the ABI that ARM recommends and linux has been using for years? The apcs (oabi) is not supported anymore.
Re: Preparation for creating netbsd-7 branch
On Jul 21, 2014, at 11:23 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: matt@ wrote: On Jul 21, 2014, at 10:56 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: rjs@ wrote: Izumi Tsutsui wrote: skrll@ wrote: I'd guess MACHINE=hpcarmMACHINE_ARCH=earmv4 Maybe the port-masters/users can test? I can test hpcarm on an iPAQ. Ok, good to hear. Unfortunately all these ports are orphaned. There were updates to hpcarm recently to get it to work on WZERO3 hardware, what is needed for it not to be considered orphaned ? orphaned means there is no portmainter to make a decision. http://www.netbsd.org/people/port-maintainers.html I have W-ZERO3 and Zaurus machines, but I'm not so motivated because I'm not sure what's the actual benefits and risk/concerns on switching to earm on such XScale generation machines. (most important part is lack of migration method, of course) the default processor for earm was chosen so that xscale and above would get smaller code and slightly higher performance. Is there any documents/articles that describe earm on NetBSD? If not, we won't have enough brave users. The fact that NetBSD is finally using the ABI that ARM recommends and linux has been using for years? The apcs (oabi) is not supported anymore. What about acorn26 and acorn32? Are you willing to step up and fix any apcs32 bugs in gcc? I have no idea if acorn26 still runs (I've made a significant effort to ensure it does). It would greatly simplify the ARM world if it would just die. :) acorn32 uses an armv3 processor which I have no idea if EABI supports. earmv3 anyone? Anyone willing to give it a shot? How many machines running out there run NetBSD? If there are more acorn26 machines than I can count with my thumbs, I'd be surprised. acorn32? Single digits? Sometimes you just have to say goodbye (pc532) to a supported platform. What about SA-1100 iPAQ and Jornada in hpcarm? earmv4 will support them. Let me be clear about something, for softfloat, the sole difference between APCS-32 and AAPCS is that the alignment for doubles and long longs changed from 4 to 8 bytes and consequently the stack must be kept 8 byte aligned. Excluding hardfloat support, that it the only ABI difference between the two. Thus compiling for any earm variant is, for the most part, a simple recompile for the new ABI. Linux no longer supports these ancient machines, I guess. Anyway, lack of documentation is still the serious problem. I am exactly the wrong person to write it. I know the space intimately so I don't know what a new person needs to know because it would never occur to me.
Re: Preparation for creating netbsd-7 branch
On Jul 21, 2014, at 12:50 PM, Manuel Bouyer bou...@antioche.eu.org wrote:
On Sun, Jul 20, 2014 at 08:45:40PM -0700, Matt Thomas wrote:
[...]
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.
I tested earmhf vs earmv7hf on the beaglebone black. with glxgears,
the performance improvement is less than 1%.
Do you have other tests that show a large gain with earmv7hf vs earmhf ?
For 1% I don't think we should bother providing all of
earmhf, earmv6hf and earmv7hf.
Try string processing, armv6+ have much faster support for the str* routines.
Also, I've been working on faster memcpy taking advantage of the hardware
fixed of unaligned accesses.
Re: Preparation for creating netbsd-7 branch
On Mon, Jul 21, 2014 at 01:22:07PM -0700, Matt Thomas wrote: Try string processing, armv6+ have much faster support for the str* routines. Also, I've been working on faster memcpy taking advantage of the hardware fixed of unaligned accesses. OK, so a pkgsrc build could show some improvement. Unfortunably, right now a pkgsrc build ends quickly with a segfault :( -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: Preparation for creating netbsd-7 branch
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? christos
Re: Preparation for creating netbsd-7 branch
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. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
matt@ wrote: 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? What (and how) MACHINE_ARCH should releng (binary builders) specify for each arm port on NetBSD 7.0 release? - 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. So, your answer is We will never prepare such upgrade path right? - 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. It doesn't answer the question at all. The question is which MACHINE_ARCH. 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. You never mentioned such simple mechanism goal in public, did you? The probelm is all your changes have been committed without public discussion and proper article. That's all. You never answered any questions either, and you never wrote proper commit logs. (PR numbers, reports on public mailing lists etc.) You have never answered other core member's question about mips64 breakage either, put no comments to recent fixes. It looks far from proper behavior as a core member.. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
christos@ wrote: 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. No idea about correctness, but for NetBSD 7.0 we needs some choice. --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
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? --- Izumi Tsutsui
Re: Preparation for creating netbsd-7 branch
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? christos
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. --- Izumi Tsutsui
Preparation for creating netbsd-7 branch
On behalf of the release engineering team, I am happy to announce that the release process for NetBSD 7.0 is now underway. We will be creating the netbsd-7 CVS branch on or about July 26th, just under two weeks from today. The creation of this branch will mark the start of the Beta period, which is expected to last into September. Between now and branch time, our focus is on fixing bugs, updating documentation, and ensuring that the basics (build, installation, boot) work on as many platforms as possible. How can you help? Glad you asked! 1. Please make sure NetBSD-current can be installed and boots on hardware (or software emulators) you care about, it in your preferred configuration. *This is especially important for users of unusual or embedded hardware*. The latest builds, as always, can be downloaded from http://releng.netbsd.org/cgi-bin/builds.cgi - it's the HEAD builds we care about until branch time. If you encounter problems, please report them via send-pr (see http://www.netbsd.org/support/send-pr.html ), or at least a quick note to current-users. 2. Help to update documentation and release notes! The release notes for NetBSD are in the src tree, in src/distrib/notes [1]. As of this writing, many of those notes have not changed since the NetBSD 6.0 release - any patches against these release notes would be gratefully accepted. 3. Fix bugs that you find! Send-pr with minor fixes, whatever you've got. A more formal announcement will be made when the first beta binaries are available - in approximately two weeks. [1] These notes are written in *roff mdoc. The *most* helpful thing is to provide patches against this code, but if you just want to provide updated text against, say, http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201407131140Z/amd64/INSTALL.html (this link will disappear in the next few days, but the latest snapshot always has the latest notes) - that would be helpful, too.
