[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210518052117.14819-1-lukas.bulwahn@gmail.com>
Date: Tue, 18 May 2021 07:21:16 +0200
From: Lukas Bulwahn <lukas.bulwahn@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>
Cc: Ralf Ramsauer <ralf.ramsauer@...-regensburg.de>,
kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org,
Lukas Bulwahn <lukas.bulwahn@...il.com>
Subject: [RFC PATCH 0/1] Mining maintainers for kernel headers
Greg, Jiri,
Some basic data mining on the kernel development process [1, 2, 3] showed that
various files in ./include currently do not have a maintainer formally assigned
with a section in the MAINTAINERS file.
This is a first semi-automatic attempt of mining a mapping of header files to
MAINTAINERS section.
Currently, the automated code analysis basically does the following steps:
1. Heuristically map header files to the related source files.
The heuristics basically uses ctags to obtain the prototypes within a
header file and then elixir to identify in which these prototypes are
defined. The header file is then mapped to the source file with the highest
number of definitions for prototypes referred to. More fine-tuning may
still be required here.
2. Deterministically map these source files to its MAINTAINERS section.
Simply, using get_maintainer.pl, we obtain all relevant MAINTAINERS sections
for each source file linked to a header file above.
3. Combine those two mappings to identify which header files should be best
added to which section in the existing MAINTAINERS file.
As of now, we simply take the one most relevant source file identified and
map it to a maintainer section. However, as the mapping from step 1 does not
map every header file to a source file, the overall suggestions for
additions is still pretty incomplete.
4. Manually review the suggestions and manually create the patch for some
example sections.
At this early stage, we look at some selective sections, review the
suggestions made by this tool for a section, filter out suggestions that
seem rather wrong and then manually create the patch to add files and
patterns from ./include/linux to the appropriate section.
Hence, the provided additions in this patch should be correct, but are not
necessarily complete wrt. all header files in ./include/linux/ that actually
belong to the TTY LAYER.
As all of this work is still pretty early and experimental, please provide
feedback on its correctness or simply pick such change for your tree if it is
all okay to take for now (although not yet complete).
Also, criticism on the approach and the way providing such patches for
MAINTAINERS is welcome, e.g.:
Your suggestions need to have this specific quality before reaching out to me
or other kernel maintainers with patches of such kind.
Or: Please do not take up the maintainers' review time for such clean-up and
just keep MAINTAINERS in the state as it is. (I would hope that this MAINTAINERS
clean-up is worth my time to attempt it, and given some good heuristics and own
manual review, worth the time to pick up by the individual maintainers.)
Or: Please first work on this other clean-up topic in MAINTAINERS and then
afterwards clean up this aspect here.
[1] https://lore.kernel.org/lkml/alpine.DEB.2.21.2003090702440.3325@felia/#r
[2] https://lwn.net/Articles/842415/
[3] https://lists.elisa.tech/g/devel/message/1269
Thanks and best regards,
Lukas
Lukas Bulwahn (1):
MAINTAINERS: TTY LAYER: add some ./include/linux/ header files
MAINTAINERS | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--
2.17.1
Powered by blists - more mailing lists