On Mon, 30 Jun 2025, Dan Carpenter wrote: > On Mon, Jun 30, 2025 at 02:02:25PM -0400, Robert P. J. Day wrote: > > > > As promised, I have the first small number of kernel cleanup scripts > > that should inspire some obvious janitorial work: > > > > https://crashcourse.ca/doku/doku.php?id=linux_kernel_cleanup > > > > There will be more scripts coming, and a lot of them will address some > > rather obvious cleanup that relates to identifying leftover cruft that > > was overlooked when something was removed from the kernel -- things > > like: > > > > - are there things being #defined and never referenced? > > Quite often people publish these deliberately. They sort of function > as documentation. At one company every time they expose anything > about the hardware interface it has to be approved by the legal dept > so they publish every single define that they can possibly think of > as early as possible so they don't have to go back and forth with > legal later on. Ewwwwwwww ... I do not like that idea. I don't like stuff being "#define"d unless it's actually required by the proprocessor. Defining stuff as documentation is just ... ewwwwwwwwww. > > > - are there things defined in Kconfig files that are never used, > > or vice versa? > > Lukas Bulwahn does a lot of this work already. It will be interesting > to see if there is anything his scripts miss. Is that the same L. Bulwahn of RISC-V fame? I might need to touch base. > > > - are there header files that are never included anymore? > > That's a good idea. I have a script that tracks down exactly that sort of thing. I'm just cleaning that up now. There seems to still be a fair bit of that. As a representative example, there is a header file in the kernel source tree: ./sound/soc/amd/include/acp_2_2_enum.h Does anything include it? Nope: $ grep -r acp_2_2_enum.h * $ So my scripts still identify plenty of potential cleanup. More later. rday
