Skip to content

Ship synced custom SAI headers in libsaivs-dev #1984

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
brcarr-nv wants to merge 1 commit into
base: master
Choose a base branch
from
+10 −0
Open

Ship synced custom SAI headers in libsaivs-dev #1984

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions debian/rules
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,6 +72,16 @@ endif
ifneq ($(filter rpc,$(DEB_BUILD_PROFILES)),)
sed -i 's|ENABLE_SAITHRIFT=0|ENABLE_SAITHRIFT=1 # Add a comment to fix https://github.com/Azure/sonic-buildimage/issues/2694 |' debian/syncd-rpc/usr/bin/syncd_init_common.sh
endif
# SAI may be built with vendor custom headers in SAI/custom/ and the generated
# saimetadata.h emitted in that case includes "#include <saicustom.h>". Ship
# those custom headers in libsaivs-dev (the VS SAI dev package that is installed
# during downstream builds such as sonic-swss) so that include resolves.
# libsaivs-dev conflicts with vendor SAI dev packages, so the two never
# co-install and there is no file-overwrite clash. Guarded on existence so
# builds that don't include custom headers are unaffected.
if ls SAI/custom/*custom*.h >/dev/null 2>&1 && [ -d debian/libsaivs-dev/usr/include/sai ]; then \
install -m 644 SAI/custom/*custom*.h debian/libsaivs-dev/usr/include/sai/; \
fi

@lolyu lolyu Jul 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The *custom*.h glob is narrower than the include chain the generated metadata actually consumes, and the failure mode is silent + deferred to downstream build time.

parse.pl emits #include <saicustom.h> into the public saimetadata.h (guarded if scalar@ch), but that saicustom.h is an aggregator: parse.pl discovers custom content by scanning $CUSTOM_DIR = "../custom/" and emits per-API includes named saicustom$shortapi.h (parse.pl ~L4688) — saicustomacl.h, saicustomswitch.h, etc. So the real downstream include chain is:

saimetadata.h -> saicustom.h -> saicustomacl.h, saicustomswitch.h, ...

Every link in that chain has to be present in libsaivs-dev for the downstream saimetadata.h compile (e.g. sonic-swss) to resolve.

Two problems with *custom*.h:

  1. Coverage relies on the "custom" substring being in every filename. Mellanox's split happens to name everything saicustom*.h today, so the glob catches them — but nothing in the SAI meta build requires that. saicustom.h (or a per-API custom header) is free to #include a vendor header in SAI/custom/ whose name doesn't contain "custom" (a shared typedef/defs header, etc.). Any such header is silently dropped and the chain breaks at swss build time with a confusing "no such file" far from here.

  2. The guard doesn't verify coverage. ls SAI/custom/*custom*.h >/dev/null 2>&1 only checks that at least one matching file exists, not that the installed set matches what the aggregator includes. Install a partial set and the guard still passes.

Since libsaivs-dev conflicts with vendor dev packages (as the PR description establishes), there's no file-overwrite risk — which removes the only reason to be conservative about what's installed. Suggest just shipping the whole custom dir the metadata build consumes:

install -m 644 SAI/custom/*.h debian/libsaivs-dev/usr/include/sai/;

That mirrors parse.pl's $CUSTOM_DIR scan exactly and guarantees the full aggregated include chain resolves.

Question: does the vendor SAI/custom/ ever contain headers — directly, or transitively #included by saicustom*.h — that don't match *custom*? If so this glob drops them. Given there's no overwrite risk, is there any reason not to install SAI/custom/*.h?

override_dh_installinit:
dh_installinit --init-script=syncd
Expand Down
Loading