On Mon, 30 Jun 2025, Dr. David Alan Gilbert wrote: > * 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. Ah, good point, I had not thought of that. I stand corrected. rday
