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
So no. Things like this need to get bent. It does not go into generic header files
‘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.
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
The other way around. Headers are
exportcode, so messing it up could result in having one import fit two modules.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.