Status of kernel-janitors?

Status of kernel-janitors?

[Linus Probert]

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.

Br,
Linus Probert

Re: Status of kernel-janitors?

[Dan Carpenter]

On Mon, Mar 30, 2026 at 02:10:49PM +0200, 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?
> 

Starting in driver/staging is good advice.

> 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.

Yeah.  After a while, you're left with only false positives or
we introduced new rules and the old code is sort of grandfathered
and the maintainers wouldn't appreciate an update.

> 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 tried to introduce the concept of, if you have an idea but don't
have the time to implement it right away, then write KTODO in your
email so people can search for that and get a list of ideas but it
hasn't really caught on.

regards,
dan carpenter

Re: Status of kernel-janitors?

[Linus Probert]

On Mon, Mar 30, 2026 at 03:25:42PM +0300, Dan Carpenter wrote:
> On Mon, Mar 30, 2026 at 02:10:49PM +0200, 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?
> > 
> 
> Starting in driver/staging is good advice.

I'll start looking around there then. Seems to be a good amount of TODO
files in there. Close to 1-to-1.

> > 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.
> 
> Yeah.  After a while, you're left with only false positives or
> we introduced new rules and the old code is sort of grandfathered
> and the maintainers wouldn't appreciate an update.
> 
> > 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 tried to introduce the concept of, if you have an idea but don't
> have the time to implement it right away, then write KTODO in your
> email so people can search for that and get a list of ideas but it
> hasn't really caught on.

A pity that didn't catch on. Could have served as a good stepping stone
to get some young blood into the project.

> regards,
> dan carpenter
> 

Thank you for the quick reply.

Re: Status of kernel-janitors?

[Robert P. J. Day]

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}

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).

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

rday

Re: Status of kernel-janitors?

[Linus Probert]

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

Re: Status of kernel-janitors?

[Dan Carpenter]

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,

There is a coccinelle check for this already.  I don't know why it
hasn't been done to NUM_ELEMENTS().

scripts/coccinelle/misc/array_size.cocci

regards,
dan carpenter

Re: Status of kernel-janitors?

[Robert P. J. Day]

On Mon, 30 Mar 2026, Dan Carpenter wrote:

> 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,
>
> There is a coccinelle check for this already.  I don't know why it
> hasn't been done to NUM_ELEMENTS().

  ah, i should have assumed there was a coccinelle check for that. in
order to be truly comprehensive, maybe you really need to attack the
problem with an ugly regex when the pretty stuff fails.

rday

Re: Status of kernel-janitors?

[Linus Probert]

On Mon Mar 30, 2026 at 10:48 PM CEST, Dan Carpenter wrote:
> On Mon, Mar 30, 2026 at 09:27:25AM -0400, Robert P. J. Day wrote:
>> On Mon, 30 Mar 2026, Linus Probert wrote:

[...]

> There is a coccinelle check for this already.  I don't know why it
> hasn't been done to NUM_ELEMENTS().
>
> scripts/coccinelle/misc/array_size.cocci

So. I have patches for the amd gpu which I can submit. Just not sure if
these have been left out for a reason or if the coccinelle check just
missed these.

I'm also not 100% sure where I send them. I made the changes on my local
staging-testing clone/branch. But these drivers are not in staging. Do
they still go through the same channels?

This is the gist of it:

- drm/amd/display: Remove unused NUM_ELEMENTS macros
- drm/amd/display: Replace inline NUM_ELEMENTS macro with ARRAY_SIZE

Some guidance on this would be most welcome.

Br,
Linus

Re: Status of kernel-janitors?

[Julia Lawall]

On Thu, 2 Apr 2026, Linus Probert wrote:

> On Mon Mar 30, 2026 at 10:48 PM CEST, Dan Carpenter wrote:
> > On Mon, Mar 30, 2026 at 09:27:25AM -0400, Robert P. J. Day wrote:
> >> On Mon, 30 Mar 2026, Linus Probert wrote:
>
> [...]
>
> > There is a coccinelle check for this already.  I don't know why it
> > hasn't been done to NUM_ELEMENTS().
> >
> > scripts/coccinelle/misc/array_size.cocci
>
> So. I have patches for the amd gpu which I can submit. Just not sure if
> these have been left out for a reason or if the coccinelle check just
> missed these.
>
> I'm also not 100% sure where I send them. I made the changes on my local
> staging-testing clone/branch. But these drivers are not in staging. Do
> they still go through the same channels?
>
> This is the gist of it:
>
> - drm/amd/display: Remove unused NUM_ELEMENTS macros
> - drm/amd/display: Replace inline NUM_ELEMENTS macro with ARRAY_SIZE
>
> Some guidance on this would be most welcome.

You can use the get_maintainer.pl script to find out who could be
interested.  You could use the following options to avoid getting too many
people:

--nokeywords --nogit --nogit-fallback --norolestats

julia

Re: Status of kernel-janitors?

[Linus Probert]

On Fri Apr 3, 2026 at 2:01 AM CEST, Julia Lawall wrote:

[...]

> You can use the get_maintainer.pl script to find out who could be
> interested.  You could use the following options to avoid getting too many
> people:
>
> --nokeywords --nogit --nogit-fallback --norolestats

Thanks. That's the command I've been using.

I submitted it to the listed emails and it got merged. My concern was
that the patch being written on staging-testing might not merge with
whatever branch it now got applied to.

I guess it was fine.

Br,
Linus

Re: Status of kernel-janitors?

[Rolf Reintjes]

Am 03.04.2026 um 23:12 schrieb Linus Probert:
> On Fri Apr 3, 2026 at 2:01 AM CEST, Julia Lawall wrote:
> 
> [...]
> 
>> You can use the get_maintainer.pl script to find out who could be
>> interested.  You could use the following options to avoid getting too many
>> people:
>>
>> --nokeywords --nogit --nogit-fallback --norolestats
> 
> Thanks. That's the command I've been using.
> 
> I submitted it to the listed emails and it got merged.

Why did you not CC kernel-janitors-mailinglist?

Rolf

Re: Status of kernel-janitors?

[Linus Probert]

On Sat Apr 4, 2026 at 12:20 AM CEST, Rolf Reintjes wrote:
> Am 03.04.2026 um 23:12 schrieb Linus Probert:
>> On Fri Apr 3, 2026 at 2:01 AM CEST, Julia Lawall wrote:

[...]

> Why did you not CC kernel-janitors-mailinglist?

I wasn't aware that this was custom to be honest. Apologies.

Br,
Linus

Re: Status of kernel-janitors?

[Ethan Tidmore]

On Fri Apr 3, 2026 at 4:12 PM CDT, Linus Probert wrote:
> On Fri Apr 3, 2026 at 2:01 AM CEST, Julia Lawall wrote:
>
> [...]
>
>> You can use the get_maintainer.pl script to find out who could be
>> interested.  You could use the following options to avoid getting too many
>> people:
>>
>> --nokeywords --nogit --nogit-fallback --norolestats
>
> Thanks. That's the command I've been using.
>
> I submitted it to the listed emails and it got merged. My concern was
> that the patch being written on staging-testing might not merge with
> whatever branch it now got applied to.

Typically linux-next is want you'd want to use here.

Thanks,

ET

>
> I guess it was fine.
>
> Br,
> Linus