Alejandro Colomar <alx@xxxxxxxxxx> writes: > On 2023-08-29 16:17, Matthew Wilcox wrote: >> Ooh, story time! Long, long ago, we did not separate "Linux headers" >> from "libc headers". It used to be somebody's job to take the files >> in /usr/src/linux/include/linux and copy them to /usr/include/linux. >> Bold people used a symlink. People who cared about things like "Well, >> POSIX says that" would edit the files after copying them to remove things >> that POSIX said shouldn't be there or put _GNU_SOURCE markers around them. >> >> At some point, we decided to split the headers to create the uapi headers >> to make this job easier. Refinements are, of course, possible, and now >> easier than ever, but I think it's fair to say that anybody who included >> <linux/elf.h> at any time in history got given a struct dynamic. > > Thanks for the story! :-) > > >> Well, it's a compile-time failure either way. Code that depended on it >> is compiling happily today, and the code that would want to use it >> doesn't exist yet, so I'd rather err on the side of keeping code written >> in the last 30 years working. > > Fair enough. The kernel rules do allow removing the structure tag if we no one is using it. If someone is using it then the bug is a regression. If you have the energy you can do a good faith search to see if there is any likely hood that anyone is using it. At a quick look I don't see anything including linux/elf.h. Add in a debian code search (is there a github or gitlab code search?) and you can make a pretty firm dent how widespread that is. After a good faith search you can merge a patch to remove it, and then if anyone reports a problem because you somehow missed them you can revert the change. If anything like libc that wants to very carefully control it's exported symbols wants to use linux/elf.h it is probably worth it. Otherwise it is probably more work that it is worth. Eric
