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:	Thu, 19 Oct 2006 18:52:50 +0200
From:	Denis Vlasenko <vda.linux@...glemail.com>
To:	Al Viro <viro@....linux.org.uk>
Cc:	Dave Jones <davej@...hat.com>, Linus Torvalds <torvalds@...l.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [RFC] typechecking for get_unaligned/put_unaligned

On Wednesday 18 October 2006 08:05, Al Viro wrote:
> That's the point, actually - apparently we have several high-impact includes
> that are easy to sever and that are really worth being severed.  The part
> that was not aproiri obvious:
> 	* there are clusters of headers around certain dependency
> counts.
> 	* such clusters tend to have leaders - header that pulls the
> rest and even though other headers are apparently independently included,
> all such includes end up being hidden by includes of the leader.
> 	* gaps between the clusters are pretty large.
> 	* dependency graph *on* *clusters* is worth being studied; includes
> of cluster leader from cluster around slightly smaller dependency count
> are prime targets for severing.
> 
> That is the new part here.  Not just "dependency graph is a mess and ought
> to be cleaned up" - _that_ is neither new nor particulary useful...

Well, logically for any given .config a set of all kernel header files
define a set of typedefs, structs, functions and so on.
If only we can read and parse them just once, and then reuse
already parsed information when we compile each .c file -
that will give you the biggest time savings.

gcc has some facility for that ("precompiled headers")
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

I don't know how hard it will be to adapt build system to using that
and there is a danger that using this thing will increase
recompile times when you change just a few CONFIG_XXXs.
--
vda
-
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