Yes, it's hardware registers. Could be a better idea to generate that from some more compact format, though.

But really, who needs THAT many hardware registers? I'm guessing that what's happening here is the internal "registers" are actually structs in memory, and someone wanted to address one memory location and thought, "I know, I'll auto-generate #defines for all of the words/longs/bytes!" And now, we're stuck with a billion "hardware registers" that are no such thing. Because somewhere in the code they might be used as such.

▲

lunar-whitey 5 days ago | parent [-]

The size of the MMIO addressable register space on many modern VLSI devices is shocking the first time you see it. However, OS device drivers often do not need to access more than a small subset of the registers. In addition, the register layout for functional units within a larger device is often identical after accounting for unremarkable changes to unit base addresses or iterative, generational addition of new registers.

The problem is the language and toolchain for OS device drivers cannot consume the manifests RTL designers use to enumerate registers, and and RTL designers rarely share the manifests and toolchains they use to generate source files for the OS developers. Instead, it is common to generate and share sources for the entire MMIO space of every supported chip revision.

To eliminate the source bloat this produces, OS driver developers would need to work with RTL design teams to release IP sanitized register manifests and tooling that can generate saner outputs for their own consumption. This is fairly specialized work and there is not a strong business incentive for most large firms to support it.

▲

Y_Y 5 days ago | parent [-]

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.