Remix.run Logo
Y_Y 5 days ago

What about just committing the symbols that are actually referenced in the code? I be most almost all of those registers are never mentioned elsewhere and and could be culled with an appropriate dead-code elimination step (per release).

kimixa 5 days ago | parent | next [-]

I feel then people would then complain that they're shipping "incomplete" or "obfuscated" code.

These headers are likely generated from their internal RTL, and somewhat part of the documentation to allow other OSS users to understand the interface. Even if most aren't used by most client drivers, and "just" some internal detail of their firmware/GPU command processing, or even optional and completely unused in current drivers, they may be useful to the community if the host can see and modify them.

Sure, you could argue that should be "split out" from the headers and documented separately, but at this point I'm generally happy for the hardware companies to give the community as much as possible and let them decide what's relevant.

lunar-whitey 5 days ago | parent | prev [-]

I’m not aware of any widely available tools that can identify unreferenced C preprocessor macros and newer language constructs that are amenable to analysis are still fairly new.

Removing unreferenced definitions from open source patches would also underscore the fact that driver code is already largely inaccessible to contributors that don’t have access to hardware specifications. The few that persist without it probably appreciate that the full listings are still published somewhere.