linux-kernel - Storing Maintainers info around the kernel tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Aug 2007 09:04:50 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Rene Herman <rene.herman@...il.com>
Cc:	Dave Jones <davej@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>, Pavel Machek <pavel@....cz>,
	linux-pm@...ts.linux-foundation.org,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	Salikh Zakirov <salikh@...il.com>, git@...r.kernel.org
Subject: Storing Maintainers info around the kernel tree

Merging a couple related threads here:

On Aug 16, 2007, at 07:57:23, Rene Herman wrote:
> On 08/16/2007 01:26 PM, Salikh Zakirov wrote:
>> Rene Herman wrote:
>>> Perhaps that immediately suggests an implementation to someone  
>>> already familiar with git internals?
>> perhaps http://www.kernel.org/pub/software/scm/git/docs/ 
>> gitattributes.html and http://www.kernel.org/pub/software/scm/git/ 
>> docs/git-check-attr.html can help you?
>
> No, thanks, saw them, but .gitattributes is in fact in the same  
> category as .gitignore, which would _be_ a property.
>
> If you do this stuff in files scattered around the tree, updating  
> and moving stuff becomes a pain -- the tool would need to go edit  
> files.

 From a practical standpoint we don't want to duplicate someone's  
maintainer information in the attributes of every file they  
maintain.  It would be much easier to put in the "kernel/somesubsys"  
directory a Maintainers file which has:

[SOME RANDOM SUBSYSTEM]
P: J. Random Hacker
M: j.random.hacker@...alhost
L: random-subsys-devel@...r.kernel.org
F: *

Anywhere else you had files that you wanted to associate with J.  
Random Hacker's maintainership, you would just use:

[SOME RANDOM SUBSYSTEM]
F: somesubsys.h

I posted a comment describing a mechanism like this a couple days ago:
   http://lkml.org/lkml/2007/8/14/488

Executive overview:
On Aug 15, 2007, at 07:21:04, Rafael J. Wysocki wrote:
> On Wednesday, 15 August 2007 04:51, Kyle Moffett wrote:
>> (a) "Maintainers" files sprinkled around the source tree with  
>> relative pathnames and other data
>>
>> (b) Tool to generate a combined "MAINTAINERS" file from the ones  
>> sprinkled around the source tree
>>
>> (c) Tool to search through the generated "MAINTAINERS" file with  
>> all sorts of useful command-line options
>>
>> (d) Tool to check the generated "MAINTAINERS" file against recent  
>> git history and make suggestions
>
> I like this idea. :-)

Well, to back up this idea with some code, I'm attaching a little  
perl script which does part (b).  Basically you call it as:
   ./maint-combine $(find . -name Maintainers)

It will print any syntax errors on stderr during parsing.  Once it's  
done it will dump to stdout its combined "MAINTAINERS" text.  A  
couple notes:

*  It uses a little "priority" system to figure out what order to  
print the data from each origin in.  For example, the "F:" tag is  
given a score of 0, to force data consisting of just files towards  
the end.  The "P:", "M:", and "L:" tags are given scores of 5, since  
people are generally interesting to know about.  Everything else is  
given a score of "1".  The scores are added up per ($file,  
$subsystem) pair and then during printing each subsystem's data is  
ordered by score (highest comes first).

*  It generally allows any field at all; eventually we might want to  
limit it to a fixed list to help avoid typos.

*  It has a little bit of magic logic for the "F:" field so that it  
figures out the relative directory for each field when generating the  
output.  For example, an entry of "asm-*/suspend.h" in a file  
"include/Maintainers" will produce the output file entry: "F: include/ 
asm-*/suspend.h"

*  The format isn't quite the same as the current MAINTAINERS file,  
to make parsing easier and more dummy-proof I changed the syntax for  
a subsystem-name to use square brackets (IE: "[SUSPEND TO RAM]").   
The samples I gave in my previous email are what I used to test it  
with, plus a little dummy file with some syntax errors to check out  
the error messages:

Maintainers:
> [EVERYTHING ELSE]
> P: Various Linux Kernel Developers
> L: linux-kernel@...r.kernel.org
> F: *

kernel/power/Maintainers:
> [SUSPEND TO RAM]
> P: Pavel Machek
> M: pavel@...e.cz
> P: Rafael J. Wysocki
> M: rjw@...k.pl
> L: linux-pm@...ts.linux-foundation.org
> S: Maintained
> F: *

include/Maintainers:
> [SUSPEND TO RAM]
> F: linux/suspend.h
> F: linux/freezer.h
> F: linux/pm.h
> F: asm-*/suspend.h

If you have any other questions, the perl script is pretty self- 
explanatory and I'll be completely back online this weekend.  With  
any luck I'll have some time in a hotel tomorrow (mmm, slow-as-dirt  
hotel wireless, what fun) to work on parts (c) and (d).

Cheers,
Kyle Moffett

View attachment "maint-combine.txt" of type "text/plain" (2041 bytes)