linux-kernel - Re: [PATCH 54/56] x86: Remove void casts

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]

Message-ID: <20090408151644.GQ12931@elte.hu>
Date:	Wed, 8 Apr 2009 17:16:44 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jack Stone <jwjstone@...tmail.fm>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Bert Wesarg <bert.wesarg@...glemail.com>,
	linux-kernel@...r.kernel.org, jeff@...zik.org,
	kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 54/56] x86: Remove void casts

* Jack Stone <jwjstone@...tmail.fm> wrote:

> Ingo Molnar wrote:
>
> > Since you do many such patches it might make sense to script up 
> > a "who maintains what" kind of script - and share that script 
> > with lkml.
> >
> > I have this silly little script:
> >
> >   git log $@ | grep Signed-off-by: |
> >    cut -d: -f2 | cut -d\< -f1 |
> >     sort | uniq -c | sort -n
> >
> > To find out any recent parties that touches a particular file. 
> > But it would be nice to somehow automate the pickup of 
> > mailing-list addresses from MAINTAINERS for example. We've 
> > literally got hundreds of email lists there.
> >
> > It is not trivial to do though :-)
>
> It would be useful. The main problem is working out what files 
> belong to what MAINTAINERS entries.
> 
> I'll see what I can cook up.

In theory we could put regex patterns into MAINTAINERS. Something 
like this:

LOCKDEP AND LOCKSTAT
P:	Peter Zijlstra
M:	peterz@...radead.org
P:	Ingo Molnar
M:	mingo@...hat.com
L:	linux-kernel@...r.kernel.org
T:	git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-lockdep.git
F:	kernel/lock*
F:	include/linux/lockdep.h
S:	Maintained

Note: there are files that fall under multiple maintainers so this 
wouldnt be a 'precise' thing - but it would sure be useful.

( There's also other details like subdirectories within a larger 
  hiearchy and there being overlap between problems. Sometimes they 
  are sub-maintained, sometimes they are exclusive so pure glob
  patterns are probably not enough. )

If this concept looks good to you ... i'd suggest that before you do 
a large patch against MAINTAINERS mapping all the maintainer 
domains, could you just do it for a few cases and send an RFC patch 
to lkml?

If there's a general upstream buy-in and a there's a 
scripts/list-maintainers.sh script that takes advantage of it then 
all this would be rather useful. (and i've Cc:-ed Andrew and Linus - 
if this is to be shot down due to fundamental objections then better 
do it at the early stages ;-)

Plus checkpatch could be extended to check whether the Cc: list in a 
patch properly matches the patterns in MAINTAINERS.

If done propery this would save us from quite a few mechanic "hm, 
who maintains _that_ file??" searches and it would also save 
maintainers from quite a few "hm, who queued up _that_ crap without 
Cc:-ing me??" moments.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/