Skip to content

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

Open
map-b wants to merge 1 commit intoefahl:mainfrom
map-b:profiles-decouple-device-platform
Open

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

Conversation

@map-b
Copy link
Copy Markdown

@map-b map-b commented Apr 2, 2026

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

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.

@map-b
Copy link
Copy Markdown
Author

map-b commented Apr 2, 2026

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 map-b force-pushed the profiles-decouple-device-platform branch from e3414da to 1e3fdfa Compare April 4, 2026 21:51
Comment on lines +1301 to +1306
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
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just aligned with spaces

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

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.
@map-b map-b force-pushed the profiles-decouple-device-platform branch from 1e3fdfa to 1abc8ea Compare April 4, 2026 22:06
let target = sysb.release.target;
let platform = replace(sysb.board_name, /,/, "_");
let board_name = sysb.board_name;
let profile = replace(board_name, /,/, "_");
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Author

map-b commented Apr 4, 2026

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant