Skip to content

Let libipchw consumers drop vendor HALs they can never run on - #178

Merged
widgetii merged 1 commit into
masterfrom
vendor-filter
Jul 28, 2026
Merged

Let libipchw consumers drop vendor HALs they can never run on#178
widgetii merged 1 commit into
masterfrom
vendor-filter

Conversation

@widgetii

Copy link
Copy Markdown
Member

libipchw carries a HAL for every supported vendor. They are only reachable through the detection table in chipid.c, so a consumer that already knows its SoC family links a pile of code that can never execute.

--gc-sections does not help here — manufacturers[] is a static array of function pointers, so every entry stays referenced no matter what the linker does. The only way to drop them is to not compile them.

Change

New cache variable IPCHW_VENDORS selects which optional HALs go into the library:

  • all — default, behaviour and output unchanged
  • none — HiSilicon only
  • a ;-separated subset, e.g. -DIPCHW_VENDORS="sstar;xm"

The HiSilicon HAL is always built, because hw_detect_system() dispatches to it directly rather than through the table.

The ipctool executable is a diagnostic tool that has to run on anything, so it always compiles every vendor regardless of the setting.

Measurements

ARM Release build:

IPCHW_VENDORS ipcinfo libipchw.a ipctool
all (default) 96,208 150,060 263,456
sstar;xm 91,728 112,340 263,456
none 87,456 103,064 263,456

none takes 8,752 bytes (9.1%) off ipcinfo. ipctool is unchanged across all three, as intended.

Building with the default all produces a byte-identical result to before this change.

Notes on the implementation

  • chipid.c gets a sentinel entry plus a detect_fn check in the loop, so manufacturers[] stays a well-formed non-empty array when every optional vendor is compiled out.
  • ipcinfo's print_serial() guards its sstar_get_die_id() call. That is a direct dependency from a library consumer on a HAL that may no longer be present — worth knowing it exists.
  • Vendor HALs turned out to be referenced from exactly one place in the library (chipid.c) plus their own implementation file, which is why this stays small.

Testing

Cross-built for ARM in all three configurations above; ipcinfo and ipctool both link cleanly in each.

Verified on a Hi3516EV300 + IMX335 that detection is unaffected — ipcinfo -c/-f/-s/-t report identical values built with all and with none:

chip=hi3516ev300  family=hi3516ev200  sensor=imx335  temp=73.93

🤖 Generated with Claude Code

libipchw carries a HAL for every supported vendor. They are only reachable
through the detection table in chipid.c, so a consumer that already knows
its SoC family links a pile of code that can never execute. --gc-sections
does not help: the manufacturers[] table is a static array of function
pointers, so every entry stays referenced.

Add IPCHW_VENDORS, which selects the optional HALs compiled into the
library: "all" (default, unchanged), "none", or a ;-separated subset. The
HiSilicon HAL is always built because hw_detect_system() dispatches to it
directly rather than through the table.

On an ARM Release build this takes ipcinfo from 96208 to 87456 bytes
(-8752, -9.1%) and libipchw.a from 150060 to 103064. Building with the
default "all" is byte-identical to before.

The ipctool executable is a diagnostic tool that has to run on anything,
so it keeps every vendor regardless of the setting — it is 263456 bytes
with "all", "none" and a subset alike.

chipid.c gets a sentinel entry and a detect_fn check so manufacturers[]
stays well-formed when every optional vendor is compiled out. ipcinfo's
print_serial() guards its sstar_get_die_id() call, since that is a direct
dependency on a HAL that may no longer be present.

Verified on a Hi3516EV300 + IMX335: ipcinfo -c/-f/-s/-t report identical
values built with "all" and with "none".

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@widgetii
widgetii merged commit 9f57d6e into master Jul 28, 2026
4 checks passed
@widgetii
widgetii deleted the vendor-filter branch July 28, 2026 10:21
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