profiles: decouple "board_name" and "profile" from "platform" variable by map-b · Pull Request #71 · efahl/owut

map-b · 2026-04-02T18:14:48Z

Just separate the, now a bit overloaded, variable "device.platform" which represents: the board_name(dts compatible) and profile into two explicit variables trying to make clearer the profile identification process during ASU sysupgrades.

The old "sanitized" device.platform now would be "device.profile" while the raw board_name is kept in "device.board_name".

In the mapping case code, rename "real_platform" to ~~"platform_profile"~~ "profile" and "alias" to "board_name" in order to make clearer the translation/mapping being done: board_name -> profile

~~Rename standalone "profile" to a more representative "platform_profile" since it represents a tuple from the platform dictionary (profiles.json).~~ Removed.

Adapted some log outputs and show the two variables when printing the previous single "device.platform".

No change in the logic, nothing should be different after this change.

EDIT V2: (compare button)

Better names for the mapping code,
Clean-up the another confusing naming in the function "complete_build_info" where the inner "board" argument was representing the full platform (profiles.json), remove the platform_profile which was redundant since we are passing the full platform anyway.

map-b · 2026-04-02T18:30:21Z

Hello Eric, I am really hope we can agree at least with these renames... I finally got time to look into owut code, and I can understand your concerns... it is a bit confusing, you mostly implemented this code about two years ago and I suppose your were mainly using the special x86 /"generic" case.

There should not be any logic change. In most cases board_name and profile would the same (replacing(',', '-')) but we know that it is important to know/show both. I was going to make some in-line comments in the PR to expand the reasoning but I do not know. I'll wait for your first comments.

map-b · 2026-04-04T21:55:02Z

+		arch:       null,              // "x86_64" or "mipsel_24kc"   or "aarch64_cortex-a53", contained in platform_json
+		target:     target,            // "x86/64" or "ath79/generic" or "mediatek/mt7622", from system board
+		board_name: board_name,        // "generic" (for x86) or "tplink,archer-c7-v4" or "linksys,e8450-ubi"
+		profile:    profile,           // "generic", "tplink_archer-c7-v4" or "linksys_e8450-ubi", used to match profiles in profiles.json
+		fstype:     sysb.rootfs_type,  // "ext4" or "squashfs", what is actually present now
+		sutype:     sutype,            // Sysupgrade type, combined, combined-efi or sysupgrade or sdcard


Just aligned with spaces

map-b · 2026-04-04T22:51:30Z

 	let target   = sysb.release.target;
-	let platform = replace(sysb.board_name, /,/, "_");
+	let board_name = sysb.board_name;
+	let profile = replace(board_name, /,/, "_");


Maybe now do you see a bit clear that this is a shortcut for the mapping/translation, it works in most cases and avoid the bit compute of the translation but the canonical/correctness is doing the translation/mapping. Is not this reasonable? Can not we even talk?

This was my whole point with those reverts in ASU side about the "sanitization" vs "translation".

map-b · 2026-04-04T23:00:41Z

Do you not believe yet that I followed this to the bottom? Even Paul got confused :P with the namings openwrt/openwrt@2a07270#commitcomment-171740773 I just found this looking for examples of cases where the mapping is required, for example those devices using the BOARD_NAME in their images recipes (like those octeon, "er").

root@OpenWrt:~# owut check
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         ramips/mt7621
Profile        xiaomi_mi-router-3g
Board          xiaomi,mi-router-3g
Package-arch   mipsel_24kc
Version-from   25.12.0-rc4 r32534-12374d88b9 (kernel 6.12.66)
Version-to     25.12.2 r32802-f505120278 (kernel 6.12.74)
92 packages are out-of-date

root@OpenWrt:~# owut check --device octeon/generic:er
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         octeon/generic
Profile        ubnt_edgerouter
Board          er
Package-arch   mips64_octeonplus
Version-from   25.12.0-rc4 r32534-12374d88b9 (kernel 6.12.66)
Version-to     25.12.2 r32802-f505120278 (kernel 6.12.74)
2 packages missing in target version, cannot upgrade
93 packages are out-of-date

map-b · 2026-04-09T22:58:31Z

 	// https://github.com/efahl/owut/issues/2#issuecomment-2165021615

 	url.platform = `${url.upstream}/${release.dir}/targets/${device.target}/profiles.json`;
 	let platform = dl_platform();


Please efahl, apologies for whatever reason you don't even talk, but this is for the project. You need to be open and keep neutral even if someone makes mistakes, you should encourage everyone to join and help. I really tried to not make too noise or communicate in excess, and only give my opinion in cases where I can be moderate confident that it's right.

Back on topic, this is the "platform" which I keep referring to, also called "target\subtarget" (profiles.json), but the other one, the "device.platform" referring to the board_name/profile... Isn't it confusing?

map-b · 2026-04-16T18:25:19Z

The (still) faulty traverse case looks like this:

root@OpenWrt:~# owut check --device layerscape/armv8_64b:traverse,ten64
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         layerscape/armv8_64b
Profile        ten64-mtd
Board          traverse,ten64
Package-arch   aarch64_generic
Version-from   25.12.0-rc4 r32534-12374d88b9 (kernel 6.12.66)
Version-to     25.12.2 r32802-f505120278 (kernel 6.12.74)

*With the x86 targets would be interesting to see the varity of "unused" board_names.

Fixed (snapshot only), traverse ten64-mtd:

root@OpenWrt:~# owut check --device layerscape/armv8_64b:traverse,ten64 --version-to snapshot
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         layerscape/armv8_64b
Profile        traverse_ten64-mtd
Board          traverse,ten64
Package-arch   aarch64_generic
Version-from   25.12.0-rc4 r32534-12374d88b9 (kernel 6.12.66)
Version-to     SNAPSHOT r34027-02e14b7278 (kernel 6.12.80)

Does it look good to you?

Just separate the, now a bit overloaded, variable "device.platform" which represents: the "board_name"(dts compatible) and the "profile" into two explicit variables trying to make clearer the profile identification process during ASU sysupgrades. The old "sanitized" "device.platform" now would be "device.profile" while the raw "board_name" is kept in "device.board_name". In the mapping case code, rename "real_platform" to "profile" and "alias" to "board_name" in order to make clearer the translation/mapping being done: board_name -> profile Simplify the "complete_build_info" function and call by passing only the full "platform" (profiles.json) as argument and, inside the function, rename the, now only one, argument to "profiles_json" instead of the previous two: "profile" and "board" where "board" was representing the full platform and "profile" was representing a specific profile in that platform. Adapted some log outputs and show the two variables when printing the previous single "device.platform". No change in the logic, nothing should be different after this change. Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com>

map-b force-pushed the profiles-decouple-device-platform branch from e3414da to 1e3fdfa Compare April 4, 2026 21:51

map-b commented Apr 4, 2026

View reviewed changes

map-b force-pushed the profiles-decouple-device-platform branch from 1e3fdfa to 1abc8ea Compare April 4, 2026 22:06

map-b commented Apr 4, 2026

View reviewed changes

map-b commented Apr 9, 2026

View reviewed changes

map-b mentioned this pull request Apr 13, 2026

asu: revert sanitize openwrt/asu#1554

Closed

map-b force-pushed the profiles-decouple-device-platform branch from 1abc8ea to b1c0226 Compare April 16, 2026 18:07

map-b force-pushed the profiles-decouple-device-platform branch from b1c0226 to 9441fcc Compare April 16, 2026 18:30

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

profiles: decouple "board_name" and "profile" from "platform" variable#71

profiles: decouple "board_name" and "profile" from "platform" variable#71
map-b wants to merge 1 commit intoefahl:mainfrom
map-b:profiles-decouple-device-platform

map-b commented Apr 2, 2026 •

edited

Loading

Uh oh!

map-b commented Apr 2, 2026

Uh oh!

map-b Apr 4, 2026

Uh oh!

map-b Apr 4, 2026

Uh oh!

map-b commented Apr 4, 2026

Uh oh!

map-b Apr 9, 2026

Uh oh!

map-b commented Apr 16, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

map-b commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

map-b commented Apr 2, 2026

Uh oh!

map-b Apr 4, 2026

Choose a reason for hiding this comment

Uh oh!

map-b Apr 4, 2026

Choose a reason for hiding this comment

Uh oh!

map-b commented Apr 4, 2026

Uh oh!

map-b Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

map-b commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

map-b commented Apr 2, 2026 •

edited

Loading

map-b commented Apr 16, 2026 •

edited

Loading