boards: rename native64 -> native #21100

OlegHahm · 2024-12-21T00:23:36Z

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.

riot-ci · 2024-12-21T00:41:52Z

Murdock results

✔️ PASSED

5e08104 fixup! native: document new native default

Success	Failures	Total	Runtime
148021	0	148021	01h:38m:28s

Artifacts

Documentation preview

miri64 · 2024-12-21T09:26:06Z

Should we, while maybe more complicated, make the rename to native32 first, make a link to it as native (see e.g. feather-m0-lora for how to link a board variant) and then walk through our normal deprecation cycle for the relinking to native64? Or can we just assume that people want native64 ASAP and that native64 is stable enough by now to not cause any regressions?

miri64 · 2024-12-21T09:33:12Z

(maybe we should even integrate native64 into the release tests first)

OlegHahm · 2024-12-21T09:52:27Z

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?)

miri64 · 2024-12-21T09:57:21Z

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 native is native32, i.e., have native point to native32 and make a deprecation note, that it will point to native64 2 release cycles later.

OlegHahm · 2024-12-21T10:12:07Z

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 · 2025-02-07T10:06:45Z

We should probably update the docs as well. (No need to tell the people to install a 32bit x86 toolchain anymore.)

kaspar030 · 2025-02-07T10:23:15Z

No need to tell the people to install a 32bit x86 toolchain anymore.

Alpine based CI containers!

mguetschow

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.

boards/native/doc.txt

mguetschow · 2025-02-11T08:20:28Z

sys/fido2/ctap/ctap_mem.c

@@ -28,7 +28,7 @@
 #define ENABLE_DEBUG    (0)
 #include "debug.h"

-#ifdef BOARD_NATIVE
+#ifdef BOARD_NATIVE32


Suggested change

#ifdef BOARD_NATIVE32

#if defined BOARD_NATIVE || defined BOARD_NATIVE32

maybe? (same in other places)

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).

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.

OlegHahm · 2025-02-11T20:44:24Z

Tried to address @mguetschow's comments. Thanks for the review.

mguetschow

Thanks @OlegHahm! If no one objects, I'd say let's merge and fix things later if they come up.

mguetschow · 2025-02-12T12:32:36Z

boards/native32/doc.txt

- 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.


Suggested change

Currently only Linux x86-32 is supported.

Currently only Linux x86 is supported.

heh, that's not true - we also support Arm32 (but not AArch64 #20739)

True. Totally forgot that.

benpicco · 2025-02-12T15:05:43Z

Instead of renaming native64 -> native, how about keeping the name and instead doing

ifeq (native, $(BOARD))
  BOARD = native$(shell getconf LONG_BIT)
endif

OlegHahm · 2025-02-12T18:10:50Z

Instead of renaming native64 -> native, how about keeping the name and instead doing
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?

OlegHahm · 2025-02-12T18:14:42Z

Addressed @benpicco's comments. Can I squash?

benpicco · 2025-02-12T18:39:53Z

getconf is POSIX

OlegHahm · 2025-02-12T18:45:12Z

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.

mguetschow · 2025-02-13T08:56:56Z

I guess we should go with native32 and native64 as board names then.

Hum, so another treewide commit changing all native back to native64? I'd rather opt for sorting this out before merging.

@benpicco

I'd favor discussing @benpicco's proposal first.

chrysn · 2025-02-13T15:13:42Z

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).

mguetschow · 2025-02-13T15:16:34Z

general aliasing infrastructure

Do you think there would be much more to it than what @benpicco proposed? Basically having a BOARD redefinition for any of the aliases at a central point called from Makefile.include?

chrysn · 2025-02-13T15:21:57Z

Do you think there would be much more to it than what @benpicco proposed?

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.

OlegHahm · 2025-02-13T21:45:31Z

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.

mguetschow · 2025-02-14T09:12:39Z

You'll now also need a rebase now that #21135 is in 🙈

Probably easier to start from scratch :P

OlegHahm · 2025-02-14T13:41:07Z

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.

mguetschow · 2025-04-03T10:59:02Z

Discontinued in favor of #21242

OlegHahm requested review from leandrolanzieri, jia200x, MrKevinWeiss, miri64, aabadie, MichelRottleuthner and kaspar030 as code owners December 21, 2024 00:23

kaspar030 added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Dec 21, 2024

OlegHahm force-pushed the pr/native64_as_default branch from 014321f to e4a8748 Compare December 21, 2024 00:50

github-actions bot added the Area: sys Area: System label Dec 21, 2024

OlegHahm force-pushed the pr/native64_as_default branch 3 times, most recently from cf1eead to 7634654 Compare December 21, 2024 09:49

OlegHahm force-pushed the pr/native64_as_default branch from 7634654 to a37eeab Compare December 21, 2024 10:51

mguetschow reviewed Feb 11, 2025

View reviewed changes

OlegHahm added 3 commits February 11, 2025 21:40

native: document new native default

c01a593

Reflect the fact that the 64 bit version of native is the new default now.

fixup! boards: rename native64 -> native

cb75569

tests: sys/ztimer: relaxed timings for native64

66ff333

mguetschow previously approved these changes Feb 12, 2025

View reviewed changes

fixup! fixup! boards: rename native64 -> native

334b900

fixup! native: document new native default

5e08104

mguetschow mentioned this pull request Feb 24, 2025

boards: introduce board alias and make native default to host target #21242

Merged

4 tasks

OlegHahm mentioned this pull request Mar 12, 2025

boards: set native variant depending on the host's CPU architecture #21291

Closed

mguetschow closed this Apr 3, 2025

	#ifdef BOARD_NATIVE32
	#if defined BOARD_NATIVE \|\| defined BOARD_NATIVE32

	Currently only Linux x86-32 is supported.
	Currently only Linux x86 is supported.

boards: rename native64 -> native #21100

boards: rename native64 -> native #21100

Uh oh!

Conversation

OlegHahm commented Dec 21, 2024

Contribution description

Testing procedure

Uh oh!

riot-ci commented Dec 21, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Murdock results

Artifacts

Uh oh!

miri64 commented Dec 21, 2024

Uh oh!

miri64 commented Dec 21, 2024

Uh oh!

OlegHahm commented Dec 21, 2024

Uh oh!

miri64 commented Dec 21, 2024

Uh oh!

OlegHahm commented Dec 21, 2024

Uh oh!

OlegHahm commented Feb 7, 2025

Uh oh!

kaspar030 commented Feb 7, 2025

Uh oh!

mguetschow left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mguetschow Feb 11, 2025

Choose a reason for hiding this comment

Uh oh!

OlegHahm Feb 11, 2025

Choose a reason for hiding this comment

Uh oh!

benpicco Feb 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OlegHahm commented Feb 11, 2025

Uh oh!

mguetschow left a comment

Choose a reason for hiding this comment

Uh oh!

mguetschow Feb 12, 2025

Choose a reason for hiding this comment

Uh oh!

benpicco Feb 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OlegHahm Feb 12, 2025

Choose a reason for hiding this comment

Uh oh!

benpicco commented Feb 12, 2025

Uh oh!

OlegHahm commented Feb 12, 2025

Uh oh!

OlegHahm commented Feb 12, 2025

Uh oh!

benpicco commented Feb 12, 2025

Uh oh!

OlegHahm commented Feb 12, 2025

Uh oh!

mguetschow commented Feb 13, 2025

Uh oh!

chrysn commented Feb 13, 2025

Uh oh!

mguetschow commented Feb 13, 2025

Uh oh!

chrysn commented Feb 13, 2025

Uh oh!

OlegHahm commented Feb 13, 2025

Uh oh!

mguetschow commented Feb 14, 2025

Uh oh!

OlegHahm commented Feb 14, 2025 via email

Uh oh!

riot-ci commented Dec 21, 2024 •

edited

Loading

benpicco Feb 12, 2025 •

edited

Loading

benpicco Feb 12, 2025 •

edited

Loading