Re: Status of kernel-janitors?

[Linus Probert <linus.probert@gmail.com>]

On Mon, Mar 30, 2026 at 09:27:25AM -0400, Robert P. J. Day wrote:
> On Mon, 30 Mar 2026, Linus Probert wrote:
> 
> > Hello,
> >
> > I've been a long time builder and fiddler of kernel source. Running
> > self-compiled kernels and pulling in patches before official release
> > etc. Bog standard for most of you I assume.
> >
> > I'd love to dedicate some spare to help the project. Like so many
> > others.
> >
> > The kernel-janoitors "project" does pop up in various resources such as
> > kernelnewbies and I think it might have been mentioned in one of the
> > Linux Foundations free courses. But links to potential homepages seem to
> > be dead and resources are sometimes dated.
> >
> > I read somewhere that this has mostly evolved into janitorial work in
> > drivers/staging. TODOs were mentioned.
> >
> > So the actual question. In my mind janitorial code work is a good place
> > to dip ones toes when starting out. Is this the right mailing list to
> > ask about such things? Any suggestions to find an area where ones
> > assistance would be welcome?
> >
> > I'm aware of checkpatch.pl but for many drivers diverging from these
> > rules seem intentional and just blindly fixing checkpatch warnings are
> > not helpful to the maintainer.
> > Open source is a lot of work so the goal would be to be helpful while
> > not stealing too much attention from concerned parties.
> 
>   I mention this once in a while ... *many* years ago, I wrote some
> admittedly hacky scripts that scanned the kernel source tree looking
> for what I considered "obvious" cleanups. One of those cleanups was to
> abbreviate the numerous calculations of the length of an array
> sprinkled throughout the source code, so I wrote a script that can be
> run from the top of the kernel source tree and can take an argument of
> which subdirectory to examine, looking for a particular regular
> expression that I can barely recognize anymore:
> 
>   #!/bin/sh
>   DIR=${1-.}
>   grep -Er "sizeof ?\(?([^\)]+)\)? ?/ ?sizeof ?\(?.*\1.*" ${DIR}

Is there ever a regex that you do understand after *many* years?

> For example, if I run:
> 
>   $ arraysize.sh drivers/gpu/drm
> 
> I get the output:
> 
> drivers/gpu/drm/xe/xe_guc_hxg_helpers.h:#define hxg_sizeof(T)	(sizeof(T) / sizeof(u32) + BUILD_BUG_ON_ZERO(sizeof(T) % sizeof(u32)))
> drivers/gpu/drm/nouveau/nvif/fifo.c:	a->m.count = sizeof(a->v) / sizeof(a->v.runlists);
> drivers/gpu/drm/amd/display/dc/mpc/dcn30/dcn30_mpc.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))
> drivers/gpu/drm/amd/display/dc/mpc/dcn20/dcn20_mpc.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))
> drivers/gpu/drm/amd/display/dc/dpp/dcn10/dcn10_dpp_cm.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))
> drivers/gpu/drm/amd/display/dc/dpp/dcn10/dcn10_dpp_cm.c:	int arr_size = sizeof(dpp_input_csc_matrix)/sizeof(struct dpp_input_csc_matrix);
> drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c:	int arr_size = sizeof(dpp_input_csc_matrix)/sizeof(struct dpp_input_csc_matrix);
> drivers/gpu/drm/amd/display/dc/dpp/dcn20/dcn20_dpp_cm.c:	int arr_size = sizeof(dpp_input_csc_matrix)/sizeof(struct dpp_input_csc_matrix);
> drivers/gpu/drm/amd/display/dc/dpp/dcn401/dcn401_dpp_cm.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))
> drivers/gpu/drm/amd/display/dc/dpp/dcn401/dcn401_dpp_cm.c:	int arr_size = sizeof(dpp_input_csc_matrix) / sizeof(struct dpp_input_csc_matrix);
> drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c:	int arr_size = sizeof(input_csc_matrix)/sizeof(struct input_csc_matrix);
> drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c:	table_size = sizeof(qp_table_##mode##_##bpc##bpc_##max)/sizeof(*qp_table_##mode##_##bpc##bpc_##max); \
> drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c:	for (k = 0; k < sizeof(wb_arb_params->cli_watermark)/sizeof(wb_arb_params->cli_watermark[0]); k++) {
> drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))
> drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c:#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))
> 
> Note the number of places in that subsystem which calculate the length
> of an array; much of that can be abbreviated by now taking advantage
> of the kernel header file include/linux/array_size.h (only relevant
> line shown here):
> 
> #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> __must_be_array(arr))
> 
> That would seem to be obvious janitor work -- simplifying code a
> subsystem at a time (do *not* try to submit a single patch that
> covers the entire source tree).

Noted.

>   I have other examples, I should clean them up and post them.

This sounds like a good idea. I assume there are many like me who don't
mind some scout work in the name of OSS.

> rday

Thanks for the reply. I'll make a note of this and make one or two
patches based on this info.

-- Linus