linux-kernel - Re: [PATCH] headerdep: a tool for detecting inclusion cycles in header file

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: <20080426182648.GA18578@uranus.ravnborg.org>
Date:	Sat, 26 Apr 2008 20:26:48 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Vegard Nossum <vegard.nossum@...il.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Adrian Bunk <bunk@...nel.org>, linux-kbuild@...r.kernel.org,
	kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] headerdep: a tool for detecting inclusion cycles in header file

On Sat, Apr 26, 2008 at 03:45:54PM +0200, Vegard Nossum wrote:
> Hi Sam,
> 
> Maybe something like this could be useful for cleaning up headers (and
> maintaining that cleanliness once it has been achieved). What do you think?
Hi Vegard.

I really like the idea to use some automated checks to increase the
quality of our headers.
And that raises the question about what is the most important
issue we have with our headers and how do we detect them in the
best possible way?

To detect inclusion cycles in a configured kernel I really think
sparse is the better place to detect it. We have sparse as an
advenced sanity check tool and adding the possibility to detect
inclusion cycles should be easier than it was to cook up this
perl script.

But we have much more important issues.
In general we have far to many dependencies in the current headers
and too much code rely on headers being implicitly pulled.

We have headers that uses types we actually do not want to use
in the kernel.

We have headers that export stuff to userspace they shouldnt.

We have heders defining prototypes for non existing functions.

We have headers defining extern variables that no longer exists.

You could continue the list.
And some of the above topics are really newbies material to fix.

If you then decide to automate it then I would need a good
explanation why we did not use sparse before considering
including the tool in the kernel.

So I do not plan to apply this patch because this should be
done in sparse and not in a random perl script.

> 
> (One thing which might or might not be good is that 'make headerdep' will
>  also compile using CC if they're not already compiled. If this should be
>  fixed, I think you'd know how to do it.)

Not a big deal - we neither support this for sparse.

> +# Output dependency graph in GraphViz language.
> +sub graph {
> +	printf "digraph {\n";
> +
> +	printf "\t/* vertices */\n";
> +	for my $header (keys %deps) {
> +		printf "\t%s [label=\"%s\"];\n",
> +			mangle($header), escape($header);
> +	}
> +
> +	printf "\n";
> +
> +	printf "\t/* edges */\n";
> +	for my $header (keys %deps) {
> +		for my $dep (@{$deps{$header}}) {
> +			printf "\t%s -> %s;\n",
> +				mangle($header), mangle($dep);
> +		}
> +	}
> +
> +	printf "}\n";
> +}

I like this part. I would be nice to see a full dependency graph
for any file that kbuild builds.
But again maybe we should do this as a sparse backend?

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