linux-kernel - Re: [PATCH 4/5] checkpatch: fix __attribute_

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: <20091002074351.GK2957@shadowen.org>
Date:	Fri, 2 Oct 2009 08:43:51 +0100
From:	Andy Whitcroft <apw@...onical.com>
To:	Daniel Walker <dwalker@...o99.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] checkpatch: fix __attribute__ matching

On Thu, Oct 01, 2009 at 07:26:12AM -0700, Daniel Walker wrote:
> On Wed, 2009-09-30 at 18:46 +0100, Andy Whitcroft wrote:
> 
> > The problem with the __attribute__ match is that it is impossible to
> > sensibly write as a regular-expression as it has nested round brackets
> > within it.  I do wonder why we care what is before the equals.  I
> > suspect that any assignment ='s followed by a newline, followed by a {
> > is wrong.  There are few places that a { is right on the next line.
> 
> Yeah, I was thinking about that also .. I though there might be some
> "= {" situation I wasn't thinking of tho.
> 
> > I'll try that one out and see if it fires any false positives.  Its
> > passing my tests here.
> > 
> > Could you see if the version at the url below works better for you:
> > 
> >   http://www.kernel.org/pub/linux/kernel/people/apw/checkpatch/checkpatch.pl-testing
> 
> I'm wondering about your release cycle .. You seem to be selectively
> sending patches to Andrew ? Have you considered putting all your changes
> into Linux-Next for instance then just keep up with the merge-window
> cycle ? Either that or send everything to Andrew.. Either way, you would
> have all the changes getting tested, instead of something like above
> where is "testing" or a version number at an obscure url location..

Linux-next might also make sense, though generally I'd seen it as an
integration test bed to catch cross tree merge conflicts and I don't
generally have that issue.  There is a wrinkle that my checkpatch tree
is separate tree because it contains a large test suite and that really
isn't something we likely want in the kernel tree itself.  I will look
at generating some real linux based branches from my tree and pushing
those to g.k.o which would be suitable for pulling into -next.

I have been distracted lately getting up to speed in a new role and that
has impacted the regular flow of checkpatch stuff.  I am hoping to get
back to normal service there.

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