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
| ||
|
Date: Sun, 09 Jan 2011 21:55:41 +0000 From: Ben Hutchings <bhutchings@...arflare.com> To: christoph.paasch@...ouvain.be Cc: Randy Dunlap <rdunlap@...otime.net>, davem@...emloft.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style On Sun, 2011-01-09 at 22:32 +0100, Christoph Paasch wrote: > Hello, > > On Sunday, January 09, 2011 wrote Randy Dunlap: > > On Sun, 9 Jan 2011 21:55:34 +0100 Christoph Paasch wrote: > > If there is something in net/tcp.h that uses data or functions from > > <linux/list.h>, then <linux/list.h> should be #included in net/tcp.h, > > whether some other file pulls it in indirectly or not. > > > > etc. etc. etc. > Why? > > IMHO I think that it increases compile-time. > Ok, here in that case it only increases it slightly (probably it isn't even > measurable). The cost of repeated inclusion is minimal. GCC's preprocessor recognises when the entire content of a file is conditional on #ifndef FOO and will not even open it again if FOO is defined. > But, if *all* the files would be more strict in including, I'm > sure that it would make a difference. > The less files you include, the faster the compilation will be. > > In net/tcp.h there were even 4 unnecessary included files. > > And, then we would also need to include: > net/net_namespace.h (for struct net) > > Also, I think that it makes the code more readable and also easier to > maintain. The more files we include, the bigger the chance is that we will end > up with plenty of files unnecessarily included, and thus the compile-time will > explode. If a file directly references definitions that are supposed to be provided by a certain header, changing it to rely on indirect inclusion of that header generally does *not* aid maintenance. (There are some cases where you should rely on indirect inclusion, such as where <linux/foo.h> includes <asm/foo.h>.) Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists