On Mon, 23 Feb 2026 16:37:54 -0500
Peter Foley
On Mon, Feb 23, 2026 at 3:47 PM Stefano Brivio
wrote: By the way, I won't have a chance to try this before a couple of days, if needed, but another thought: if we end up adding/changing hundreds of include lines as a result, maybe the cleanup David mentioned would actually be in scope at that point, even from a mere perspective of "noise" we would add, or effort you're spending anyway (let's make it fully worth it I'd say).
I tried running clang-include-cleaner and then massaging it to not include c++ only headers or stuff from bits/ That wound up with: 64 files changed, 349 insertions(+), 189 deletions(-)
Unfortunatly include-cleaner isn't smart enough to handle things like #include
instead of So absent adding pragma annotations to glibc headers, I'm not sure a clean clang-include-cleaner check is possible.
We could always add suppressions for clang-tidy checks, we already have a bunch, see NOLINTNEXTLINE directives in the code.
That diff is https://github.com/pefoley2/passt/commit/6ae0bcb2bbdc10384346dda547db60f80c8... . I can send it as a proper patch as well if you're interested, but it's a lot of churn and I'm not sure how to prevent back-sliding...
Ouch... yeah. Let me have another look tomorrow (Tuesday) but I think it only makes sense if we use that as a chance to entirely switch to approach #2 David was mentioning (minus perhaps some exceptions), including all the related clean-ups. I'm totally for it by the way, if you can take care of it. Otherwise I'd recommend sticking to a more conservative approach for the moment being. -- Stefano