* Robert P. J. Day (rpjday@xxxxxxxxxxxxxx) wrote: > 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. It's quite common; a set of #defines for every register/function/etc in their chip, maybe also for every firmware call with a struct for the interface layout. Sometimes these are spat our semi automatically from their hardware group who designed them. On the plus side, they don't take up any space in the resulting binary, unlike the zillions of unused wrapper functions some drivers have for every firmware call/register, many of which aren't used. > > > - 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: I've got a bunch of very hacky scripts that: a) Try and find symbols that are unused - generally functions that re defined but never called; it's very hacky, but so far I've removed hundreds of them (and am currently at the end of 'w's after about 9 months!). b) I was also hunting struct's defined in C files and not used, and also things like linked lists that are declared/defined but never used. Generally the patches to remove stuff have been well received, most devs want dead code removed; there are some who rather like their API the way it is, even if some of it's not used. I also try and do things like avoid hardware definitions (see above) and don't remove one half of a pair (e.g. if there's an inc_foo and a dec_foo but the inc isn't used). Dave > ./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 > -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
