I have a pile of potential janitorial work for interested parties

I have a pile of potential janitorial work for interested parties

[Robert P. J. Day]

  Quite some time ago, I was immersed in a bunch of Linux kernel
janitorial work, and I wrote a bunch of scripts that scanned the
kernel source tree and identified obvious candidates for
simplification and cleanup. I'm going to publish all of that to my
website in the very near future, but just to clarify what I mean, let
me provide a single example to see if this is still relevant, or
whether I'm off-base.

  One of the scripts I wrote scanned the kernel tree for what I call
"badref selects", those being entries in Kconfig files that "select"ed
config entries that did not exist (probably the result of someone
deleting config entries, but not checking to see if anything selected
that entry). Such occurrences are not fatal, but they are obvious
candidates for cleanup.

  I just ran that script on the current source tree just for the
drivers/ directory, and here's the output I got:


$ find_badref_selects.sh drivers
===== DRM_DEBUG_SELFTEST
drivers/gpu/drm/i915/Kconfig.debug:53:	select DRM_DEBUG_SELFTEST
===== DRM_KMS_DMA_HELPER
drivers/gpu/drm/adp/Kconfig:9:	select DRM_KMS_DMA_HELPER
drivers/gpu/drm/logicvc/Kconfig:7:	select DRM_KMS_DMA_HELPER
===== TEST_KUNIT_DEVICE_HELPERS
drivers/iio/test/Kconfig:11:	select TEST_KUNIT_DEVICE_HELPERS


This output suggests that those "selects" refer to config entries that
do not exist, and so could likely be removed as janitorial work.

  Does the above make sense? If I recursively grep for the strings,
say, "TEST_KUNIT_DEVICE_HELPERS", I see only that select statement,
and nothing else. I'm assuming that means it's superfluous. If this
makes sense, I can publish my scanning scripts and others are welcome
to use them to find stuff that can be cleaned up.

  Thoughts?

rday

Re: I have a pile of potential janitorial work for interested parties

[Ruben Wauters]

On Sat, 2025-06-28 at 17:08 -0400, Robert P. J. Day wrote:
> 
>   Quite some time ago, I was immersed in a bunch of Linux kernel
> janitorial work, and I wrote a bunch of scripts that scanned the
> kernel source tree and identified obvious candidates for
> simplification and cleanup. I'm going to publish all of that to my
> website in the very near future, but just to clarify what I mean, let
> me provide a single example to see if this is still relevant, or
> whether I'm off-base.
> 
>   One of the scripts I wrote scanned the kernel tree for what I call
> "badref selects", those being entries in Kconfig files that
> "select"ed
> config entries that did not exist (probably the result of someone
> deleting config entries, but not checking to see if anything selected
> that entry). Such occurrences are not fatal, but they are obvious
> candidates for cleanup.
> 
>   I just ran that script on the current source tree just for the
> drivers/ directory, and here's the output I got:
> 
> 
> $ find_badref_selects.sh drivers
> ===== DRM_DEBUG_SELFTEST
> drivers/gpu/drm/i915/Kconfig.debug:53:	select DRM_DEBUG_SELFTEST
> ===== DRM_KMS_DMA_HELPER
> drivers/gpu/drm/adp/Kconfig:9:	select DRM_KMS_DMA_HELPER
> drivers/gpu/drm/logicvc/Kconfig:7:	select DRM_KMS_DMA_HELPER
> ===== TEST_KUNIT_DEVICE_HELPERS
> drivers/iio/test/Kconfig:11:	select TEST_KUNIT_DEVICE_HELPERS
> 
> 
> This output suggests that those "selects" refer to config entries
> that
> do not exist, and so could likely be removed as janitorial work.
> 
>   Does the above make sense? If I recursively grep for the strings,
> say, "TEST_KUNIT_DEVICE_HELPERS", I see only that select statement,
> and nothing else. I'm assuming that means it's superfluous. If this
> makes sense, I can publish my scanning scripts and others are welcome
> to use them to find stuff that can be cleaned up.
> 
>   Thoughts?

Hello,

Thank you for highlighting this, I believe this is a good target for
cleanup, and I would be interested in any other scripts you have that
provide similar information.

I am fairly new to linux kernel development in general, not having a
large amount of patches to my name, however, opportunities for cleanup
and janitorial work, while often neglected by other programmers for
larger features, still are important in my opinion, as it creates a
more maintainable and cleaner codebase, as such I would be very much
interested in any cleanup opportunities.

Thank you very much

Ruben Wauters

> rday

Re: I have a pile of potential janitorial work for interested parties

[Robert P. J. Day]

On Mon, 30 Jun 2025, Ruben Wauters wrote:

... snip ...

> Hello,
>
> Thank you for highlighting this, I believe this is a good target for
> cleanup, and I would be interested in any other scripts you have
> that provide similar information.
>
> I am fairly new to linux kernel development in general, not having a
> large amount of patches to my name, however, opportunities for
> cleanup and janitorial work, while often neglected by other
> programmers for larger features, still are important in my opinion,
> as it creates a more maintainable and cleaner codebase, as such I
> would be very much interested in any cleanup opportunities.

I started documenting these potential cleanups here:

https://crashcourse.ca/doku/doku.php?id=linux_kernel_cleanup

so anyone who's interested can start processing whatever parts of the
kernel source tree that interests them.

There will be more cleanup scripts coming over the next few days.

rday

Re: I have a pile of potential janitorial work for interested parties

[Charalampos Mitrodimas]

"Robert P. J. Day" <rpjday@crashcourse.ca> writes:

> On Mon, 30 Jun 2025, Ruben Wauters wrote:
>
> ... snip ...
>
>> Hello,
>>
>> Thank you for highlighting this, I believe this is a good target for
>> cleanup, and I would be interested in any other scripts you have
>> that provide similar information.
>>
>> I am fairly new to linux kernel development in general, not having a
>> large amount of patches to my name, however, opportunities for
>> cleanup and janitorial work, while often neglected by other
>> programmers for larger features, still are important in my opinion,
>> as it creates a more maintainable and cleaner codebase, as such I
>> would be very much interested in any cleanup opportunities.
>
> I started documenting these potential cleanups here:
>
> https://crashcourse.ca/doku/doku.php?id=linux_kernel_cleanup
>
> so anyone who's interested can start processing whatever parts of the
> kernel source tree that interests them.

Hi Robert,

This is going to be very helpful to newcomers that are looking forward
to contributing to the Linux kernel.

Looking at your list, the tools are awesome and well-thought. But I
believe some guidelines can be put in-place for some, so folks can get
their patches upstream easily, and of course, have some confidence in
it.

One guideline that came to mind almost immediately is regarding the
tools "Calculating the length of an array" is that people should pick a
subsystem and send a patchset, i.e. do not send a massive change that
changes code under more than one Kernel subsystem.

This approach respects maintainer, and simplifies the review process.

--
C. Mitrodimas

>
> There will be more cleanup scripts coming over the next few days.
>
> rday

Re: I have a pile of potential janitorial work for interested parties

[Robert P. J. Day]

On Mon, 30 Jun 2025, Charalampos Mitrodimas wrote:

> "Robert P. J. Day" <rpjday@crashcourse.ca> writes:
>
> > On Mon, 30 Jun 2025, Ruben Wauters wrote:
> >
> > ... snip ...
> >
> >> Hello,
> >>
> >> Thank you for highlighting this, I believe this is a good target for
> >> cleanup, and I would be interested in any other scripts you have
> >> that provide similar information.
> >>
> >> I am fairly new to linux kernel development in general, not having a
> >> large amount of patches to my name, however, opportunities for
> >> cleanup and janitorial work, while often neglected by other
> >> programmers for larger features, still are important in my opinion,
> >> as it creates a more maintainable and cleaner codebase, as such I
> >> would be very much interested in any cleanup opportunities.
> >
> > I started documenting these potential cleanups here:
> >
> > https://crashcourse.ca/doku/doku.php?id=linux_kernel_cleanup
> >
> > so anyone who's interested can start processing whatever parts of the
> > kernel source tree that interests them.
>
> Hi Robert,
>
> This is going to be very helpful to newcomers that are looking forward
> to contributing to the Linux kernel.
>
> Looking at your list, the tools are awesome and well-thought. But I
> believe some guidelines can be put in-place for some, so folks can get
> their patches upstream easily, and of course, have some confidence in
> it.
>
> One guideline that came to mind almost immediately is regarding the
> tools "Calculating the length of an array" is that people should pick a
> subsystem and send a patchset, i.e. do not send a massive change that
> changes code under more than one Kernel subsystem.
>
> This approach respects maintainer, and simplifies the review process.

  I added a note to that effect early on that page.

rday