this latest project of cramming the full definition of each kernel
subsystem into the MAINTAINERS file has been bothering me, and i've
finally figured out why. it's because the MAINTAINERS file is being
asked to now be the source of reference information that just doesn't
match its name. it's the "MAINTAINERS" file so it seems that all it
should be keeping track of is the maintainer of each subsystem, and
that's all.
what people are clearly after is a way to match any part of the
kernel source to a subsystem and, henceforth, to a maintainer, but
there's nothing that says all of that has to be crammed into *that*
file.
why not add a new script to the kernel source tree that, given a
file or directory name as an argument, returns its corresponding
"subsystem" that can be cross-referenced against the MAINTAINERS file?
something like:
$ show_subsystem drivers/bluetooth/bpa10x.c
BLUETOOTH
there would seem to be a number of advantages to this approach:
1) it reduces the MAINTAINERS file back to what it should be in the
first place -- a simple reference list of each kernel subsystem, and
who's responsible for it, so that constant reshuffling of files or
directories in a particular subsystem doesn't require constant
updating of the MAINTAINERS file.
2) you could extend the show_subsystem() routine to, once it found the
subsystem, quickly cross-reference the MAINTAINERS file and print out
the corresponding maintainer. i believe the word "trivial" applies
here.
3) by making this a feature separate from the MAINTAINERS file, it can
be mocked up and hacked separately and finally patched in when it's
ready to go, rather than applying 5 bazillion patches to the poor
MAINTAINERS file.
4) finally, a feature like this could be used as a sanity check on the
kernel subsystem structure. every once in a while, it could be
invoked for every single file and directory in the tree, just to see
if all of those appear to belong to at least one subsystem. if not,
print a warning: "Whoa, file /fubar/snafu doesn't belong to a
subsystem. Deal with it."
the actual implementation would seem to be easy -- perhaps a simple
text file that defines each subsystem and every file and directory
that's part of it:
FIREWIRE:drivers/firewire/,include/linux/firewire.h,... etc ...
i mean, it doesn't get a whole lot simpler than that, and it would
seem to be *way* easier to read.
thoughts?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
> $ show_subsystem drivers/bluetooth/bpa10x.c
> BLUETOOTH
"what's a subsystem"?
I'm not sure there is an appropriate definition.
If there is an appropriate definition, why
should anyone care what subsystem a particular
file is in?
> 1) it reduces the MAINTAINERS file back to what it should be in the
> first place -- a simple reference list of each kernel subsystem, and
> who's responsible for it, so that constant reshuffling of files or
> directories in a particular subsystem doesn't require constant
> updating of the MAINTAINERS file.
I'd still be happy if MAINTAINERS went away.
I'm not sure what good it does other than have
a link to mailing lists that otherwise might not
be CC'd on patches.
> thoughts?
For user submission of bug reports, perhaps it'd be
more useful to have a submitkernelbugreport script
and a network enabled "dispatch bug report" to
appropriate maintainers service.
Try something out and see what happens.
Good luck. Joe
On Sat, 18 Aug 2007, Joe Perches wrote:
> On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
> > $ show_subsystem drivers/bluetooth/bpa10x.c
> > BLUETOOTH
>
> "what's a subsystem"? I'm not sure there is an appropriate
> definition. If there is an appropriate definition, why should anyone
> care what subsystem a particular file is in?
i'm confused -- i thought that was sort of the whole purpose of this
exercise, to match parts of the kernel source tree against the
maintainer for those parts, and to do that via the defined
"subsystem" which is currently used in MAINTAINERS.
you can, of course, banish the concept of a subsystem entirely and
work purely from a file and directory perspective, but i think the
notion of the kernel tree being composed of subsystems is a useful
idea. that's just my opinion, though.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Sun, 2007-08-19 at 08:22 -0400, Robert P. J. Day wrote:
> On Sat, 18 Aug 2007, Joe Perches wrote:
> > On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
> > > $ show_subsystem drivers/bluetooth/bpa10x.c
> > > BLUETOOTH
> > "what's a subsystem"? I'm not sure there is an appropriate
> > definition. If there is an appropriate definition, why should anyone
> > care what subsystem a particular file is in?
> i'm confused -- i thought that was sort of the whole purpose of this
> exercise, to match parts of the kernel source tree against the
> maintainer for those parts, and to do that via the defined
> "subsystem" which is currently used in MAINTAINERS.
What I did was for patch submission.
That script should probably be named "get_patch_cc_list".
It does now by default use git to find and include the
most frequent signatories.
I think that descriptions of subsystems are not
particularly useful. The file hierarchy should
effectively do that. I think a tool to inform a
"list of interested parties" when a file is touched
is useful though.
If there is to be a subsystem definition, I think it
needs to be hierarchical with things like specific
net drivers not a subsystem, but an element of the
subsystem net:drivers (or drivers:net or both).
If these elements are bundled together into a single
"subsystem" descriptor file you will run into the "hot"
file problem that Linus described.
cheers, Joe
"Robert P. J. Day" <[email protected]> writes:
> i'm confused -- i thought that was sort of the whole purpose of this
> exercise, to match parts of the kernel source tree against the
> maintainer for those parts, and to do that via the defined
> "subsystem" which is currently used in MAINTAINERS.
>
> you can, of course, banish the concept of a subsystem entirely and
> work purely from a file and directory perspective, but i think the
> notion of the kernel tree being composed of subsystems is a useful
> idea. that's just my opinion, though.
Obviously the concept of subsystems is the right one, except that
the subsystems aren't that well defined (or they are but not
for average kernel user) - thus "file masks".
--
Krzysztof Halasa
Joe Perches wrote:
> On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
>> $ show_subsystem drivers/bluetooth/bpa10x.c
>> BLUETOOTH
>
> "what's a subsystem"?
> I'm not sure there is an appropriate definition.
> If there is an appropriate definition, why
> should anyone care what subsystem a particular
> file is in?
Until I can pass a patch or source file as an argument to a script and get out
the URL of the git tree it needs to go into on the path to Linus's tree,
MAINTAINERS is inadequate. If I ask for the MAINTAINER info of
drivers/net/atl1/atl1_main.c, I should get back myself, my co-maintainer, our
sourceforge URL, our mailing list address, etc. There should also be a
mechanism, either as part of MAINTAINERS or something else, that will tell me
that atl1 is part of the netdev subsystem, which is discussed on
[email protected], maintained by Jeff Garzik, and has the appropriate URI
for the netdev GIT tree.
-- Chris
On Mon, 2007-08-20 at 15:31 -0400, Chris Snook wrote:
> Until I can pass a patch or source file as an argument to a script and get out
> the URL of the git tree it needs to go into on the path to Linus's tree,
> MAINTAINERS is inadequate. If I ask for the MAINTAINER info of
> drivers/net/atl1/atl1_main.c, I should get back myself, my co-maintainer, our
> sourceforge URL, our mailing list address, etc. There should also be a
> mechanism, either as part of MAINTAINERS or something else, that will tell me
> that atl1 is part of the netdev subsystem, which is discussed on
> [email protected], maintained by Jeff Garzik, and has the appropriate URI
> for the netdev GIT tree.
Finding a specific "List" or "Web" or "Tree" from a file is
a pretty easy extension to the current get_maintainer script.
The git_maintainer script could easily be modified to take
a filename rather than a patch file as input too.
There is no specific "parent" information in MAINTAINERS.
Are you suggesting there should be?
Still, it's easy to use directory parentage.
Is that good enough?
For instance:
ATL1 has this maintainer block:
ATL1 ETHERNET DRIVER
P: Jay Cliburn
M: [email protected]
P: Chris Snook
M: [email protected]
L: [email protected]
W: http://sourceforge.net/projects/atl1
W: http://atl1.sourceforge.net
S: Maintained
F: drivers/net/atl1/
and NETWORK DEVICE DRIVERS has:
NETWORK DEVICE DRIVERS
P: Andrew Morton
M: [email protected]
P: Jeff Garzik
M: [email protected]
L: [email protected]
T: git kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
S: Maintained
F: drivers/net/
So, NETWORK DEVICE DRIVERS would be CC'd on any change
to ATL1 (or any other driver in drivers/net/...)
Of course the same lookup could apply to L: or T:
cheers, Joe
Joe Perches wrote:
> On Mon, 2007-08-20 at 15:31 -0400, Chris Snook wrote:
>> Until I can pass a patch or source file as an argument to a script and get out
>> the URL of the git tree it needs to go into on the path to Linus's tree,
>> MAINTAINERS is inadequate. If I ask for the MAINTAINER info of
>> drivers/net/atl1/atl1_main.c, I should get back myself, my co-maintainer, our
>> sourceforge URL, our mailing list address, etc. There should also be a
>> mechanism, either as part of MAINTAINERS or something else, that will tell me
>> that atl1 is part of the netdev subsystem, which is discussed on
>> [email protected], maintained by Jeff Garzik, and has the appropriate URI
>> for the netdev GIT tree.
>
> Finding a specific "List" or "Web" or "Tree" from a file is
> a pretty easy extension to the current get_maintainer script.
>
> The git_maintainer script could easily be modified to take
> a filename rather than a patch file as input too.
>
> There is no specific "parent" information in MAINTAINERS.
> Are you suggesting there should be?
>
> Still, it's easy to use directory parentage.
> Is that good enough?
I suppose. I was thinking initially that directory parentage alone
wouldn't suffice, because you could be traversing upwards from a variety
of places with a complex patch. But now that I think about it, a patch
should really only be going in through one git tree, no matter how many
subsystems it might peripherally touch. Deciding which tree really
requires human intelligence, so there's no point trying to automate
that. Multiple inheritance would be... bad...
-- Chris