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:	Mon, 18 Jan 2010 11:58:58 +0100
From:	Michal Marek <mmarek@...e.cz>
To:	Németh Márton <nm127@...email.hu>
Cc:	linux-kbuild@...r.kernel.org,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Julia Lawall <julia@...u.dk>,
	Pekka Enberg <penberg@...helsinki.fi>,
	David Miller <davem@...emloft.net>, stefanr@...6.in-berlin.de,
	adi@...apodia.org, david.vrabel@....com, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, cocci@...u.dk,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nicolas Palix <npalix@...u.dk>
Subject: Re: SmPL scripts into build environment?

On 15.1.2010 17:49, Németh Márton wrote:
> Hi Marek,

s/Marek/Michal/ :)


> there was a discussion about patches which are generated using the
> tool called spatch. In the changelog the SmPL script was usually
> included, see http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=commit&s=%3Csmpl%3E .
> It is useful to store the SmPL scripts because they may find
> problems in the newcoming code also.
> 
> In order to run a "check" the spatch tool and the SmPL is also necessary.
> There was an idea to place the used SmPL scripts under the Linux
> kernel source tree so it can move from the changelog but still remain
> for later use. The "check" could be run similar to the tools checkpatch,
> sparse or lockdep.
> 
> What do you think where the SmPL scripts can be placed?

Documentation/smpl/$name_of_problem_fixed.cocci? Or maybe better
scripts/smlp/..., if you are going to add some wrapper that runs the
semantic patches on the source tree. Or something like that, a dedicated
subdirectory to store the semantic patches in individual files.


> What do you think the best way would be to introduce some check like this
> in the build environment?

I've only heard about the tool, I haven't used it yet. Does it need to
preprocess and parse source files like sparse does, or can it check C
files without expanding macros and includes? If the former, then let's
extend make C=... to also support spatch. If the latter, then a script
that runs spatch on all *.c files found the tree should be enough. But
as I said, I haven't used the tool, so I don't know what it needs and
what it can offer.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ