this post was submitted on 10 Aug 2025
345 points (98.9% liked)
Tech
1753 readers
26 users here now
A community for high quality news and discussion around technological advancements and changes
Things that fit:
- New tech releases
- Major tech changes
- Major milestones for tech
- Major tech news such as data breaches, discontinuation
Things that don't fit
- Minor app updates
- Government legislation
- Company news
- Opinion pieces
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So can anyone explain this? What are header files in this context and why are unnecessary functions especially problematic for them? Why would it not be up to Linus or not his concern what is included in the "RISC-V parts"? I guess this is all code for a Linux kernel that is built on top of RISC-V which I think is an assembly language, and not a modification to RISC-V itself?
I get the logic about make_u32_from_two_u16() being bad at least.
A header file in the C family of programming languages contains the declarations for each function that gets defined in the accompanying code file. Ideally, the header file should only contain import statements, some basic definitions, and function declarations. It should not contain any actual executable code.
A header file basically exists to tell the compiler "hey, these functions exist in this file, don't freak out if it gets called before you see its definition." Without the header file, you'd need to write the declarations at the beginning of the code file (in the header, hence the name).
So why is Linus especially upset about "pollution" of "generic headers" here, but considering it to be up to someone else what's in the "RISC-V parts"?
Because header files are common and used across multiple projects to create a common environment or API between those projects. The headers are a shared space, the code that calls the headers (e.g.: the platform-specific RISC V implementation) is a less shared space and may be outside of Linus' domain, so to speak. Basically, it's like if two cities shared a reservoir for drinking water. If one city decides to mix raw sewage in the water at their pump station, that's a bad idea, but it's a problem for that city to deal with. If, on the other hand, it dumps the raw sewage into the shared lake, it affects the other city as well
DISCLAIMER: I'm just speculating, I haven't touched c in decades and have no idea how Linux code works.
Generic headers here could refer to headers declaring common functions whose specific implementation might differ based on CPU architecture.
That is, the .h files would declare certain functions that other parts of the code can call to do CPU related stuff, and when compiling for a certain architecture you'd use different .c files implementing said functions for that specific architecture.
Obviously, since these headers will be common to multiple specific implementations, it'd be very important to have a standard or at least a consensus in regards to which functions they should declare, what they should return, and which parameters they should take.
From Linus' quote there, I assume the Google “devs” (probably Gemini) must have included RISC-V specific stuff in the headers, which would be an extremely big no-no as it could break other implementations or the code calling these functions.
Absolute code amateur here, but my guess is "generic headers" are just a copy/paste job from another program (or vibe code), and declare a bunch of really common functions that never actually get utilized in the code.
Sorta like copying the same import statements in Python, whether you're using numpy or not
I don't think that's quite right:
'generic' seems to be describing a category of header files that are especially important for some reason, and isn't being used as a pejorative to describe the rejected code.
The other way around. Headers are
exportcode, so messing it up could result in having one import fit two modules.