linux-kernel - Re: [PATCH 01/10] Fs: ext4: acl.c: fixed indent issue

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:	Sat, 25 Sep 2010 22:10:30 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Joe Perches <joe@...ches.com>
Cc:	Andy Whitcroft <apw@...onical.com>, Christoph Hellwig <hch@....de>,
	T Dent <tdent48227@...il.com>, adilger.kernel@...ger.ca,
	jack@...e.cz, dmonakhov@...nvz.org, sandeen@...hat.com,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/10] Fs: ext4: acl.c: fixed indent issue

On Sat, Sep 25, 2010 at 07:03:11PM -0700, Joe Perches wrote:
> 
> When you define "it" that way, not as any simple
> file pattern match, but as a control for what
> 	"git log -- path"
> to inspect,  it's quite feasible to use the pattern
> match rather than the file name.
> 
> So, thanks, that's a good suggestion.

Don't make it an option, though.  If you must use hueristics, then at
least *try* to make the hueristics smarter.  If the file name falls
into certain patterns, such as:

     fs/*/*.[ch]
     drivers/scsi/*/*.[ch]
     drivers/net/*/*.[ch]

etc., then you really should be doing the analysis by subdirectory,
and not by file.

> > I don't believe get_maintainers.pl does have legitmate use, since it's
> > really not that hard to look up something in MAINTAINERS, and if it's
> > not there, some real human judgement is needed, and not hueristic
> > guessing --- or at the very least, the script needs to warn that it's
> > guessing, and maybe explain to the user in detail why it's making the
> > guesses that it's making, so the user has a chance of understanding
> > why it might be completely wrong.
> 
> Multiple warning labels on tools tend to get ignored.
> People that use tools without training tend to get injured.

There's something very simple you can do that would help.  Don't make
it easy for people to do

   mail $(./get_maintainer.pl) < annoying-e-mail

Instead have get_maintainer.pl always be very verbose, and have it
*explain* what it is doing, so that in order for someone to use the
damn thing, they have to read the text while they are finding the
e-mail address to cut and paste out of its output.

I really dislike training people that using dumb scripts is a good
idea.  Tools like that just plain shouldn't exist, if they are that
subject to error.  If you can clean up the tool to the point where the
error rate is manageable, maybe, perhaps.

But what was shipped as part of 2.6.35 was really, really, *REALLY*
bad.  It makes me wonder how much testing someone did with the
hueristics before turning it loose for the newbies to use.

	   	  	     	       	   - Ted
--
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/