boards: rename native64 -> native#21100
Conversation
OlegHahm
requested review from
MichelRottleuthner,
MrKevinWeiss,
aabadie,
jia200x,
kaspar030,
leandrolanzieri and
miri64
as code owners
github-actions
bot
added
Platform: native
kaspar030
added
the
CI: ready for build
OlegHahm
force-pushed
the
pr/native64_as_default
branch
from
014321f to
e4a8748
Compare
|
Should we, while maybe more complicated, make the rename to |
|
(maybe we should even integrate |
OlegHahm
force-pushed
the
pr/native64_as_default
branch
3 times, most recently
from
cf1eead to
7634654
Compare
|
I think there is indeed no reason to rush it. Integrating it into the release tests, might be a good idea. But I don't get your proposal for the deprecation cycle. (Do we want to deprecated native 32 bit at all?) |
No, just the fact that |
|
Ah, understood. Not sure though whether this is necessary. After all native is most likely not used in production but rather for testing and debugging. It should work reliable, so extending the transition time is a good thing but we should make sure that more people are using the 64 bit variant during this transition time to check for its reliability. |
OlegHahm
force-pushed
the
pr/native64_as_default
branch
from
7634654 to
a37eeab
Compare
|
We should probably update the docs as well. (No need to tell the people to install a 32bit x86 toolchain anymore.) |
Alpine based CI containers! |
mguetschow
left a comment
mguetschow
left a comment
There was a problem hiding this comment.
Looks quite straightforward enough, I trust you doing the right tree-wide search-and-replace. Can go in as soon as we've adapted the documentation for native and native64.
Updating the RIOT build dependencies can happen in a separate PR, I'd say.
sys/fido2/ctap/ctap_mem.c
Outdated
| #include "debug.h" | ||
|
|
||
| #ifdef BOARD_NATIVE | ||
| #ifdef BOARD_NATIVE32 |
There was a problem hiding this comment.
| #ifdef BOARD_NATIVE32 | |
| #if defined BOARD_NATIVE || defined BOARD_NATIVE32 |
maybe? (same in other places)
There was a problem hiding this comment.
I guess that makes sense here. In the tests I'm not sure - but since they work without an explicit #ifdef BOARD_NATIVE64 (or BOARD_NATIVE after the switch), they seem to require special handling for native32 only (for whatever reason).
There was a problem hiding this comment.
We also have CPU_NATIVE for that, which is set no matter what native 'board' is used.
Reflect the fact that the 64 bit version of native is the new default now.
|
Tried to address @mguetschow's comments. Thanks for the review. |
mguetschow
left a comment
mguetschow
left a comment
There was a problem hiding this comment.
Thanks @OlegHahm! If no one objects, I'd say let's merge and fix things later if they come up.
boards/native32/doc.txt
Outdated
| - SPI: Runtime configurable - `/dev/spidev*` are supported (Linux host only) | ||
| - GPIO: Runtime configurable - `/dev/gpiochip*` are supported (Linux host only) | ||
| Same board as \ref boards_native "native", but compiled for 32-bit instead of 64-bit. | ||
| Currently only Linux x86-32 is supported. |
There was a problem hiding this comment.
| Currently only Linux x86-32 is supported. | |
| Currently only Linux x86 is supported. |
There was a problem hiding this comment.
heh, that's not true - we also support Arm32 (but not AArch64 #20739)
There was a problem hiding this comment.
True. Totally forgot that.
mguetschow
added
CI: full build
|
Instead of renaming ifeq (native, $(BOARD))
BOARD = native$(shell getconf LONG_BIT)
endif |
Not sure. Would that work on non-Linux platforms? (I know that the current (official) support is limited to Linux anyway but IIRC basic native stuff also works on OSX (except for networking).) How about opening a separate PR for that after this one has been merged? |
|
Addressed @benpicco's comments. Can I squash? |
|
|
|
Yes, but the Linux implementation may differ (according to the man page) and I wasn't sure if the variables are also part. But looking into the limits.h, it seems that the answer is yes. I still would like to merge this PR first and then add another PR with the proposed idea. (I guess we should go with native32 and native64 as board names then. |
Hum, so another treewide commit changing all |
mguetschow
dismissed
their stale review
I'd favor discussing @benpicco's proposal first.
|
I agree with Mikolai that going through an alias sounds preferable to multiple treewide changes. (They're even planned in RDM0003, sorry for lack of progress on general aliasing infrastructure). |
Do you think there would be much more to it than what @benpicco proposed? Basically having a |
On the long run, we'll want to rename boards with confusing names to their systematic names; if that infrastructure were in place, the native switch could go there. It is not, but if we follow his suggestion, that place can later grow to also cater for other aliases. The impact on this PR is mainly this: No, it's not weird to have a place in the Makefiles where this renaming happens, even if it's just handling a single special case now – this is the first of more that will happen there. |
|
Okay, if the consensus if that we want to have this I would go over this PR again and rename native to native64 and implement the corresponding "alias" via the Makefile. |
|
You'll now also need a rebase now that #21135 is in 🙈 Probably easier to start from scratch :P |
|
On Fri, Feb 14, 2025 at 01:13:02AM -0800, mguetschow wrote:
Probably easier to start from scratch :P
If we decide to go with native32 and native64 it might be easier to start
from scratch indeed.
|
|
Discontinued in favor of #21242 |
9 participants
Contribution description
This patch renames the current native board into native32 and replaces it with the current native64 board.
The changeset is mostly renaming directories and replacing native64 with native32 within application Makefiles (unless native64) was not supported.
It's only superficially tested so far. Let's see what the CI comes up with.
Testing procedure
Use your favorite RIOT application on native.