* Re: Linux 2.6.0-test6
@ 2003-09-28 10:14 Geert Uytterhoeven
2003-09-28 12:50 ` Russell King
2003-09-28 17:37 ` Linus Torvalds
0 siblings, 2 replies; 37+ messages in thread
From: Geert Uytterhoeven @ 2003-09-28 10:14 UTC (permalink / raw)
To: Bernardo Innocenti; +Cc: Linus Torvalds, Kernel Mailing List
On Sat, 27 Sep 2003, Linus Torvalds wrote:
> Bernardo Innocenti:
> o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h
This change breaks 2.95 for some source files, because <linux/init.h> doesn't
include <linux/compiler.h>. Do you want to have the missing include added to
<linux/init.h>, or to the individual source files that need it?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Linux 2.6.0-test6 2003-09-28 10:14 Linux 2.6.0-test6 Geert Uytterhoeven @ 2003-09-28 12:50 ` Russell King 2003-09-28 13:54 ` Bernardo Innocenti 2003-09-28 17:37 ` Linus Torvalds 1 sibling, 1 reply; 37+ messages in thread From: Russell King @ 2003-09-28 12:50 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Bernardo Innocenti, Linus Torvalds, Kernel Mailing List On Sun, Sep 28, 2003 at 12:14:18PM +0200, Geert Uytterhoeven wrote: > > On Sat, 27 Sep 2003, Linus Torvalds wrote: > > Bernardo Innocenti: > > o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h > > This change breaks 2.95 for some source files, because <linux/init.h> doesn't > include <linux/compiler.h>. Do you want to have the missing include added to > <linux/init.h>, or to the individual source files that need it? It also breaks gcc 3.2.2 / gcc 3.3 as well: arch/arm/mach-sa1100/leds.c:51: error: parse error before "__attribute_used__" arch/arm/mach-pxa/leds.c:29: error: parse error before "__attribute_used__" -- Russell King (rmk@arm.linux.org.uk) http://www.arm.linux.org.uk/personal/ Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 12:50 ` Russell King @ 2003-09-28 13:54 ` Bernardo Innocenti 0 siblings, 0 replies; 37+ messages in thread From: Bernardo Innocenti @ 2003-09-28 13:54 UTC (permalink / raw) To: Russell King; +Cc: Geert Uytterhoeven, Linus Torvalds, Kernel Mailing List Russell King wrote: >>>Bernardo Innocenti: >>> o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h >> >>This change breaks 2.95 for some source files, because <linux/init.h> doesn't >>include <linux/compiler.h>. Do you want to have the missing include added to >><linux/init.h>, or to the individual source files that need it? The golden rule of C headers says that each file should stand on its own, so that you have no errors when compiling the header alone. This is the trivial fix. Sorry for not noticing before. --- include/linux/init.h.orig 2003-09-28 15:48:06.000000000 +0200 +++ include/linux/init.h 2003-09-28 15:48:10.000000000 +0200 @@ -2,6 +2,7 @@ #define _LINUX_INIT_H #include <linux/config.h> +#include <linux/compiler.h> /* These macros are used to mark some functions or * initialized data (doesn't apply to uninitialized data) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 10:14 Linux 2.6.0-test6 Geert Uytterhoeven 2003-09-28 12:50 ` Russell King @ 2003-09-28 17:37 ` Linus Torvalds 2003-09-28 18:46 ` Sam Ravnborg ` (2 more replies) 1 sibling, 3 replies; 37+ messages in thread From: Linus Torvalds @ 2003-09-28 17:37 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: Bernardo Innocenti, Kernel Mailing List On Sun, 28 Sep 2003, Geert Uytterhoeven wrote: > > On Sat, 27 Sep 2003, Linus Torvalds wrote: > > Bernardo Innocenti: > > o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h > > This change breaks 2.95 for some source files, because <linux/init.h> doesn't > include <linux/compiler.h>. Do you want to have the missing include added to > <linux/init.h>, or to the individual source files that need it? Interesting. I'm pretty sure I did a "make allyesconfig" just before the test6 release, so apparently x86 includes it indirectly through some path, and so it only shows up on m68k and arm? This, btw, is a pretty common thing. I wonder what we could do to make sure that different architectures wouldn't have so different include file structures. It's happened _way_ too often. Any ideas? Linus ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 17:37 ` Linus Torvalds @ 2003-09-28 18:46 ` Sam Ravnborg 2003-09-28 18:52 ` Linus Torvalds 2003-09-28 19:16 ` Jörn Engel 2003-09-28 19:28 ` Russell King 2003-09-29 19:19 ` bill davidsen 2 siblings, 2 replies; 37+ messages in thread From: Sam Ravnborg @ 2003-09-28 18:46 UTC (permalink / raw) To: Linus Torvalds Cc: Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List On Sun, Sep 28, 2003 at 10:37:36AM -0700, Linus Torvalds wrote: > > This, btw, is a pretty common thing. I wonder what we could do to make > sure that different architectures wouldn't have so different include file > structures. It's happened _way_ too often. > > Any ideas? Without too much thinking.... Would it help to require all major[1] header files to include all the header files needed for them to compile? We could make that part of the build process or we could make that an optional step. Obviously that would not solve any issues in asm-$(ARCH). [1] There are ~600 files in include/linux - we could pick up the 50 most important and checkcompile them. Sam ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 18:46 ` Sam Ravnborg @ 2003-09-28 18:52 ` Linus Torvalds 2003-09-28 19:44 ` Jamie Lokier 2003-09-28 19:16 ` Jörn Engel 1 sibling, 1 reply; 37+ messages in thread From: Linus Torvalds @ 2003-09-28 18:52 UTC (permalink / raw) To: Sam Ravnborg; +Cc: Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List On Sun, 28 Sep 2003, Sam Ravnborg wrote: > > Would it help to require all major[1] header files to include all the > header files needed for them to compile? It causes tons of extra work for the compiler if the compiler doesn't optimize away redundant header files (same header file being included from a lot of different sources). I did the pruning in sparse, and I think at least gcc-3 does it too, but I'm not sure. If so, then sure, we could just require that the header files compile cleanly, and for extra points verify that the end result is an empty object file (ie no bad declarations anywhere..). Linus ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 18:52 ` Linus Torvalds @ 2003-09-28 19:44 ` Jamie Lokier 0 siblings, 0 replies; 37+ messages in thread From: Jamie Lokier @ 2003-09-28 19:44 UTC (permalink / raw) To: Linus Torvalds Cc: Sam Ravnborg, Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List Linus Torvalds wrote: > On Sun, 28 Sep 2003, Sam Ravnborg wrote: > > Would it help to require all major[1] header files to include all the > > header files needed for them to compile? > > It causes tons of extra work for the compiler if the compiler doesn't > optimize away redundant header files (same header file being included from > a lot of different sources). > > I did the pruning in sparse, and I think at least gcc-3 does it too, but > I'm not sure. GCC does optimise away multiple header file inclusion, and has done for a very long time, oh a decade or so :) GCC will not reparse a header file if these conditions are met: 1. The file has already been parsed at least once. 2. Apart from comments, the entire file is surrounded by "#ifndef symbol ... #endif" or "#if !defined (symbol) ... #endif". 3. "symbol" is defined. 4. The file names are the same after removal of "." and ".." components and other path simplifications. > If so, then sure, we could just require that the header files compile > cleanly, and for extra points verify that the end result is an empty > object file (ie no bad declarations anywhere..). You can also use the "-H" option and check for a "Multiple include guards may be useful for:" message, to check those #ifndefs. -- Jamie ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 18:46 ` Sam Ravnborg 2003-09-28 18:52 ` Linus Torvalds @ 2003-09-28 19:16 ` Jörn Engel 2003-09-28 19:31 ` Sam Ravnborg 2003-09-28 19:42 ` Linux 2.6.0-test6 Russell King 1 sibling, 2 replies; 37+ messages in thread From: Jörn Engel @ 2003-09-28 19:16 UTC (permalink / raw) To: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg On Sun, 28 September 2003 20:46:42 +0200, Sam Ravnborg wrote: > On Sun, Sep 28, 2003 at 10:37:36AM -0700, Linus Torvalds wrote: > > > > This, btw, is a pretty common thing. I wonder what we could do to make > > sure that different architectures wouldn't have so different include file > > structures. It's happened _way_ too often. > > > > Any ideas? > > Without too much thinking.... > Would it help to require all major[1] header files to include all the > header files needed for them to compile? > We could make that part of the build process or we could make that an > optional step. > > Obviously that would not solve any issues in asm-$(ARCH). > > [1] There are ~600 files in include/linux - we could pick up the > 50 most important and checkcompile them. How about a check_headers target that roughly works like this: for (all header files in include/linux and include/asm) { echo "#include <$HEADER>" > header.c make header.o rm header.c header.o } Did a quick test for linux/fs.h in -test5 and it compiled fine, but broke after removing some random #include. Another thing, Sam, "make header.o" causes make to call itself indefinitely. Had to "make somedir/header.o". Not sure if you consider this to be a bug, your decision. Jörn -- Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 19:16 ` Jörn Engel @ 2003-09-28 19:31 ` Sam Ravnborg 2003-09-28 19:44 ` Jörn Engel 2003-09-28 19:42 ` Linux 2.6.0-test6 Russell King 1 sibling, 1 reply; 37+ messages in thread From: Sam Ravnborg @ 2003-09-28 19:31 UTC (permalink / raw) To: Jörn Engel Cc: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg On Sun, Sep 28, 2003 at 09:16:22PM +0200, Jörn Engel wrote: > How about a check_headers target that roughly works like this: > > for (all header files in include/linux and include/asm) { > echo "#include <$HEADER>" > header.c > make header.o > rm header.c header.o > } That should do it. Can you also integrate the check Linus mentioned, to make sure no declarations are present. I would name the target: headercheck: to be consistent with the other targets. It should be fine having it as a separate target, then we can ask John Cherry to include it in his nightly builds. > Another thing, Sam, "make header.o" causes make to call itself > indefinitely. Had to "make somedir/header.o". Not sure if you > consider this to be a bug, your decision. Thanks - I will try to look into it. Sam ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 19:31 ` Sam Ravnborg @ 2003-09-28 19:44 ` Jörn Engel 2003-09-29 13:36 ` [PATCH] check headers for complete includes, etc Jörn Engel 0 siblings, 1 reply; 37+ messages in thread From: Jörn Engel @ 2003-09-28 19:44 UTC (permalink / raw) To: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg On Sun, 28 September 2003 21:31:50 +0200, Sam Ravnborg wrote: > On Sun, Sep 28, 2003 at 09:16:22PM +0200, Jörn Engel wrote: > > How about a check_headers target that roughly works like this: > > > > for (all header files in include/linux and include/asm) { > > echo "#include <$HEADER>" > header.c > > make header.o > > rm header.c header.o > > } > > That should do it. Can you also integrate the check Linus mentioned, > to make sure no declarations are present. If it's simple enough, you'll have it tomorrow. Linus' check might take a bit longer, I'm not sure yet how to define an empty object file. Is it enough if objdump -tT only shows sections? > I would name the target: headercheck: > to be consistent with the other targets. ok. > It should be fine having it as a separate target, then we can ask > John Cherry to include it in his nightly builds. That would be nice, yes. Jörn -- Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. -- Rob Pike ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH] check headers for complete includes, etc. 2003-09-28 19:44 ` Jörn Engel @ 2003-09-29 13:36 ` Jörn Engel 2003-09-29 13:40 ` Jörn Engel 2003-09-29 14:50 ` Sam Ravnborg 0 siblings, 2 replies; 37+ messages in thread From: Jörn Engel @ 2003-09-29 13:36 UTC (permalink / raw) To: Sam Ravnborg, Kernel Mailing List, Linus Torvalds, Russell King, Jamie Lokier On Sun, 28 September 2003 21:44:31 +0200, Jörn Engel wrote: > On Sun, 28 September 2003 21:31:50 +0200, Sam Ravnborg wrote: > > > > That should do it. Can you also integrate the check Linus mentioned, > > to make sure no declarations are present. > > If it's simple enough, you'll have it tomorrow. Linus' check might > take a bit longer, I'm not sure yet how to define an empty object > file. Is it enough if objdump -tT only shows sections? > > > I would name the target: headercheck: > > to be consistent with the other targets. > > ok. First version of the script. Seems to work, but it catches a lot, maybe too much. Jörn -- "Error protection by error detection and correction." -- from a university class --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.0-test5/scripts/checkheader.pl 2003-09-29 15:33:10.000000000 +0200 @@ -0,0 +1,43 @@ +#!/usr/bin/perl -w +use strict; + +my $normsymbols = "^\n" + . "lib/header.o: file format elf32-i386\n" + . "\n" + . "SYMBOL TABLE:\n" + . "00000000 l df \\*ABS\\* 00000000 header.c\n" + . "00000000 l d .text 00000000 \n" + . "00000000 l d .data 00000000 \n" + . "00000000 l d .bss 00000000 \n" + . "00000000 l d .comment 00000000 \n" + . "\n" + . "\n\$"; + +#my @headers = ("linux/fs.h"); +my @headers = sort(split(/\n/, `(cd include/ && find linux -name "*.h")`)); +my $basename = "lib/header"; + +foreach my $h (@headers) { + close(STDERR); + open(STDERR, ">", "$basename.err"); + + open(HC, '>', "$basename.c"); + print(HC "#include <$h>\n"); + close(HC); + + # tests + if (system("make", "$basename.o") != 0) { + print("WARNING: header doesn't build standalone: $h\n"); + next; + } + + my $symbols = `objdump -t $basename.o`; + if ($symbols !~ /$normsymbols/) { + print("WARNING: Symbols may be declared: $h\n"); + } +} continue { + # cleanup + unlink("$basename.c"); + unlink("$basename.err"); + unlink("$basename.o"); +} --- linux-2.6.0-test5/Makefile~headercheck 2003-09-28 21:37:19.000000000 +0200 +++ linux-2.6.0-test5/Makefile 2003-09-29 15:31:13.000000000 +0200 @@ -838,6 +838,9 @@ -name '*.[hcS]' -type f -print | sort \ | xargs $(PERL) -w scripts/checkincludes.pl +headercheck: + $(PERL) scripts/checkheader.pl + versioncheck: find * $(RCS_FIND_IGNORE) \ -name '*.[hcS]' -type f -print | sort \ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] check headers for complete includes, etc. 2003-09-29 13:36 ` [PATCH] check headers for complete includes, etc Jörn Engel @ 2003-09-29 13:40 ` Jörn Engel 2003-09-29 14:50 ` Sam Ravnborg 1 sibling, 0 replies; 37+ messages in thread From: Jörn Engel @ 2003-09-29 13:40 UTC (permalink / raw) To: Sam Ravnborg, Kernel Mailing List, Linus Torvalds, Russell King, Jamie Lokier Russell, you might not like the results from my testrun. Should we really fix all the 286 headers or would that do more harm than good? The declared symbols are a different problem, though. Could be a nice janitor task. WARNING: Symbols may be declared: linux/acpi.h WARNING: Symbols may be declared: linux/atm_idt77105.h WARNING: Symbols may be declared: linux/atmdev.h WARNING: Symbols may be declared: linux/eeprom.h WARNING: Symbols may be declared: linux/efs_fs.h WARNING: Symbols may be declared: linux/ext3_jbd.h WARNING: Symbols may be declared: linux/ip.h WARNING: Symbols may be declared: linux/ipv6.h WARNING: Symbols may be declared: linux/isdn.h WARNING: Symbols may be declared: linux/ixjuser.h WARNING: Symbols may be declared: linux/mroute.h WARNING: Symbols may be declared: linux/netfilter_ipv4/ip_tables.h WARNING: Symbols may be declared: linux/netfilter_ipv4/ipt_multiport.h WARNING: Symbols may be declared: linux/netfilter_ipv6/ip6_tables.h WARNING: Symbols may be declared: linux/netfilter_ipv6/ip6t_multiport.h WARNING: Symbols may be declared: linux/nfsd/nfsfh.h WARNING: Symbols may be declared: linux/raid/linear.h WARNING: Symbols may be declared: linux/raid/md.h WARNING: Symbols may be declared: linux/raid/multipath.h WARNING: Symbols may be declared: linux/raid/raid0.h WARNING: Symbols may be declared: linux/raid/raid1.h WARNING: Symbols may be declared: linux/raid/raid5.h WARNING: Symbols may be declared: linux/raid/xor.h WARNING: Symbols may be declared: linux/tcp.h WARNING: Symbols may be declared: linux/udp.h WARNING: header doesn't build standalone: linux/ac97_codec.h WARNING: header doesn't build standalone: linux/acpi_serial.h WARNING: header doesn't build standalone: linux/adfs_fs.h WARNING: header doesn't build standalone: linux/adfs_fs_i.h WARNING: header doesn't build standalone: linux/adfs_fs_sb.h WARNING: header doesn't build standalone: linux/affs_fs_sb.h WARNING: header doesn't build standalone: linux/affs_hardblocks.h WARNING: header doesn't build standalone: linux/agp_backend.h WARNING: header doesn't build standalone: linux/agpgart.h WARNING: header doesn't build standalone: linux/aio.h WARNING: header doesn't build standalone: linux/amigaffs.h WARNING: header doesn't build standalone: linux/arcdevice.h WARNING: header doesn't build standalone: linux/atalk.h WARNING: header doesn't build standalone: linux/atm_tcp.h WARNING: header doesn't build standalone: linux/atm_zatm.h WARNING: header doesn't build standalone: linux/bfs_fs.h WARNING: header doesn't build standalone: linux/brlvger.h WARNING: header doesn't build standalone: linux/byteorder/big_endian.h WARNING: header doesn't build standalone: linux/byteorder/generic.h WARNING: header doesn't build standalone: linux/byteorder/little_endian.h WARNING: header doesn't build standalone: linux/byteorder/pdp_endian.h WARNING: header doesn't build standalone: linux/byteorder/swab.h WARNING: header doesn't build standalone: linux/byteorder/swabb.h WARNING: header doesn't build standalone: linux/cciss_ioctl.h WARNING: header doesn't build standalone: linux/cdev.h WARNING: header doesn't build standalone: linux/coda_fs_i.h WARNING: header doesn't build standalone: linux/coda_proc.h WARNING: header doesn't build standalone: linux/coda_psdev.h WARNING: header doesn't build standalone: linux/compat_ioctl.h WARNING: header doesn't build standalone: linux/console_struct.h WARNING: header doesn't build standalone: linux/cramfs_fs.h WARNING: header doesn't build standalone: linux/cramfs_fs_sb.h WARNING: header doesn't build standalone: linux/cyclades.h WARNING: header doesn't build standalone: linux/cycx_drv.h WARNING: header doesn't build standalone: linux/cycx_x25.h WARNING: header doesn't build standalone: linux/device-mapper.h WARNING: header doesn't build standalone: linux/devpts_fs.h WARNING: header doesn't build standalone: linux/dirent.h WARNING: header doesn't build standalone: linux/divert.h WARNING: header doesn't build standalone: linux/dma-mapping.h WARNING: header doesn't build standalone: linux/efs_dir.h WARNING: header doesn't build standalone: linux/efs_fs_i.h WARNING: header doesn't build standalone: linux/efs_fs_sb.h WARNING: header doesn't build standalone: linux/efs_vh.h WARNING: header doesn't build standalone: linux/eisa.h WARNING: header doesn't build standalone: linux/elevator.h WARNING: header doesn't build standalone: linux/errqueue.h WARNING: header doesn't build standalone: linux/etherdevice.h WARNING: header doesn't build standalone: linux/ethtool.h WARNING: header doesn't build standalone: linux/eventpoll.h WARNING: header doesn't build standalone: linux/ext2_fs.h WARNING: header doesn't build standalone: linux/ext3_fs.h WARNING: header doesn't build standalone: linux/ext3_fs_i.h WARNING: header doesn't build standalone: linux/fcdevice.h WARNING: header doesn't build standalone: linux/fcntl.h WARNING: header doesn't build standalone: linux/fddidevice.h WARNING: header doesn't build standalone: linux/filter.h WARNING: header doesn't build standalone: linux/flat.h WARNING: header doesn't build standalone: linux/fs_struct.h WARNING: header doesn't build standalone: linux/fsfilter.h WARNING: header doesn't build standalone: linux/ftape-header-segment.h WARNING: header doesn't build standalone: linux/futex.h WARNING: header doesn't build standalone: linux/gameport.h WARNING: header doesn't build standalone: linux/generic_serial.h WARNING: header doesn't build standalone: linux/hash.h WARNING: header doesn't build standalone: linux/hayesesp.h WARNING: header doesn't build standalone: linux/hdlc/ioctl.h WARNING: header doesn't build standalone: linux/hfs_fs_i.h WARNING: header doesn't build standalone: linux/hfs_fs_sb.h WARNING: header doesn't build standalone: linux/hiddev.h WARNING: header doesn't build standalone: linux/hpfs_fs_i.h WARNING: header doesn't build standalone: linux/hpfs_fs_sb.h WARNING: header doesn't build standalone: linux/i2c-dev.h WARNING: header doesn't build standalone: linux/i2o-dev.h WARNING: header doesn't build standalone: linux/i2o.h WARNING: header doesn't build standalone: linux/ibmtr.h WARNING: header doesn't build standalone: linux/icmp.h WARNING: header doesn't build standalone: linux/idr.h WARNING: header doesn't build standalone: linux/if_arcnet.h WARNING: header doesn't build standalone: linux/if_eql.h WARNING: header doesn't build standalone: linux/if_fc.h WARNING: header doesn't build standalone: linux/if_fddi.h WARNING: header doesn't build standalone: linux/if_frad.h WARNING: header doesn't build standalone: linux/if_ppp.h WARNING: header doesn't build standalone: linux/if_pppvar.h WARNING: header doesn't build standalone: linux/if_shaper.h WARNING: header doesn't build standalone: linux/if_strip.h WARNING: header doesn't build standalone: linux/if_tr.h WARNING: header doesn't build standalone: linux/if_tun.h WARNING: header doesn't build standalone: linux/if_tunnel.h WARNING: header doesn't build standalone: linux/if_wanpipe.h WARNING: header doesn't build standalone: linux/if_wanpipe_common.h WARNING: header doesn't build standalone: linux/in_systm.h WARNING: header doesn't build standalone: linux/inet.h WARNING: header doesn't build standalone: linux/inetdevice.h WARNING: header doesn't build standalone: linux/ip6_tunnel.h WARNING: header doesn't build standalone: linux/ipc.h WARNING: header doesn't build standalone: linux/ipmi_smi.h WARNING: header doesn't build standalone: linux/ipv6_route.h WARNING: header doesn't build standalone: linux/irda.h WARNING: header doesn't build standalone: linux/irq_cpustat.h WARNING: header doesn't build standalone: linux/isdn_divertif.h WARNING: header doesn't build standalone: linux/isicom.h WARNING: header doesn't build standalone: linux/iso_fs_sb.h WARNING: header doesn't build standalone: linux/istallion.h WARNING: header doesn't build standalone: linux/ite_gpio.h WARNING: header doesn't build standalone: linux/jffs2.h WARNING: header doesn't build standalone: linux/jffs2_fs_i.h WARNING: header doesn't build standalone: linux/jhash.h WARNING: header doesn't build standalone: linux/kernelcapi.h WARNING: header doesn't build standalone: linux/kmalloc_sizes.h WARNING: header doesn't build standalone: linux/kobj_map.h WARNING: header doesn't build standalone: linux/llc.h WARNING: header doesn't build standalone: linux/lockd/bind.h WARNING: header doesn't build standalone: linux/lockd/lockd.h WARNING: header doesn't build standalone: linux/lockd/share.h WARNING: header doesn't build standalone: linux/lockd/sm_inter.h WARNING: header doesn't build standalone: linux/mbcache.h WARNING: header doesn't build standalone: linux/mc6821.h WARNING: header doesn't build standalone: linux/minix_fs.h WARNING: header doesn't build standalone: linux/mm_inline.h WARNING: header doesn't build standalone: linux/mount.h WARNING: header doesn't build standalone: linux/mpage.h WARNING: header doesn't build standalone: linux/msdos_fs_sb.h WARNING: header doesn't build standalone: linux/msg.h WARNING: header doesn't build standalone: linux/mtd/cfi.h WARNING: header doesn't build standalone: linux/mtd/ftl.h WARNING: header doesn't build standalone: linux/mtd/nand_ecc.h WARNING: header doesn't build standalone: linux/mtd/partitions.h WARNING: header doesn't build standalone: linux/namei.h WARNING: header doesn't build standalone: linux/namespace.h WARNING: header doesn't build standalone: linux/nbd.h WARNING: header doesn't build standalone: linux/ncp_fs_i.h WARNING: header doesn't build standalone: linux/ncp_fs_sb.h WARNING: header doesn't build standalone: linux/netbeui.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_802_3.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_arp.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_arpreply.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_ip.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_log.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_mark_m.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_nat.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_pkttype.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_stp.h WARNING: header doesn't build standalone: linux/netfilter_bridge/ebt_vlan.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_conntrack.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_conntrack_ftp.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_conntrack_helper.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_conntrack_irc.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_conntrack_protocol.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_conntrack_tcp.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_conntrack_tftp.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_conntrack_tuple.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_nat_helper.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_nat_rule.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ip_queue.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipchains_core.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipfwadm_core.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_CLASSIFY.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_DSCP.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_ECN.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_SAME.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_TCPMSS.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_TOS.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_ULOG.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_ah.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_conntrack.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_dscp.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_ecn.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_esp.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_iprange.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_length.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_limit.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_mac.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_mark.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_owner.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_recent.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_tcpmss.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_tos.h WARNING: header doesn't build standalone: linux/netfilter_ipv4/ipt_ttl.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_ah.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_esp.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_frag.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_hl.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_ipv6header.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_length.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_limit.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_mac.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_mark.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_opts.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_owner.h WARNING: header doesn't build standalone: linux/netfilter_ipv6/ip6t_rt.h WARNING: header doesn't build standalone: linux/netrom.h WARNING: header doesn't build standalone: linux/nfs.h WARNING: header doesn't build standalone: linux/nfs_fs_sb.h WARNING: header doesn't build standalone: linux/nfs_idmap.h WARNING: header doesn't build standalone: linux/nfs_page.h WARNING: header doesn't build standalone: linux/nfs_xdr.h WARNING: header doesn't build standalone: linux/nfsd/const.h WARNING: header doesn't build standalone: linux/nfsd/export.h WARNING: header doesn't build standalone: linux/nfsd/nfsd.h WARNING: header doesn't build standalone: linux/nfsd/state.h WARNING: header doesn't build standalone: linux/nfsd/syscall.h WARNING: header doesn't build standalone: linux/nfsd/xdr.h WARNING: header doesn't build standalone: linux/nfsd/xdr3.h WARNING: header doesn't build standalone: linux/nfsd/xdr4.h WARNING: header doesn't build standalone: linux/nls.h WARNING: header doesn't build standalone: linux/nubus.h WARNING: header doesn't build standalone: linux/pagevec.h WARNING: header doesn't build standalone: linux/parport_pc.h WARNING: header doesn't build standalone: linux/pid.h WARNING: header doesn't build standalone: linux/pipe_fs_i.h WARNING: header doesn't build standalone: linux/pkt_cls.h WARNING: header doesn't build standalone: linux/pkt_sched.h WARNING: header doesn't build standalone: linux/pmu.h WARNING: header doesn't build standalone: linux/ppp.h WARNING: header doesn't build standalone: linux/ppp_defs.h WARNING: header doesn't build standalone: linux/qic117.h WARNING: header doesn't build standalone: linux/qnx4_fs.h WARNING: header doesn't build standalone: linux/qnxtypes.h WARNING: header doesn't build standalone: linux/quota.h WARNING: header doesn't build standalone: linux/quotaio_v2.h WARNING: header doesn't build standalone: linux/radix-tree.h WARNING: header doesn't build standalone: linux/raid/md_k.h WARNING: header doesn't build standalone: linux/raid/md_p.h WARNING: header doesn't build standalone: linux/random.h WARNING: header doesn't build standalone: linux/reiserfs_fs_i.h WARNING: header doesn't build standalone: linux/reiserfs_fs_sb.h WARNING: header doesn't build standalone: linux/romfs_fs.h WARNING: header doesn't build standalone: linux/root_dev.h WARNING: header doesn't build standalone: linux/rose.h WARNING: header doesn't build standalone: linux/rtnetlink.h WARNING: header doesn't build standalone: linux/rwsem-spinlock.h WARNING: header doesn't build standalone: linux/scc.h WARNING: header doesn't build standalone: linux/sctp.h WARNING: header doesn't build standalone: linux/sdla_asy.h WARNING: header doesn't build standalone: linux/sdla_chdlc.h WARNING: header doesn't build standalone: linux/sdla_fr.h WARNING: header doesn't build standalone: linux/sdla_ppp.h WARNING: header doesn't build standalone: linux/sdla_x25.h WARNING: header doesn't build standalone: linux/sdladrv.h WARNING: header doesn't build standalone: linux/selection.h WARNING: header doesn't build standalone: linux/sem.h WARNING: header doesn't build standalone: linux/serial.h WARNING: header doesn't build standalone: linux/serial167.h WARNING: header doesn't build standalone: linux/serial_core.h WARNING: header doesn't build standalone: linux/shm.h WARNING: header doesn't build standalone: linux/shmem_fs.h WARNING: header doesn't build standalone: linux/smb.h WARNING: header doesn't build standalone: linux/smb_fs.h WARNING: header doesn't build standalone: linux/smb_fs_sb.h WARNING: header doesn't build standalone: linux/smb_mount.h WARNING: header doesn't build standalone: linux/stallion.h WARNING: header doesn't build standalone: linux/sunrpc/clnt.h WARNING: header doesn't build standalone: linux/sunrpc/gss_api.h WARNING: header doesn't build standalone: linux/sunrpc/gss_asn1.h WARNING: header doesn't build standalone: linux/sunrpc/msg_prot.h WARNING: header doesn't build standalone: linux/sunrpc/name_lookup.h WARNING: header doesn't build standalone: linux/sunrpc/rpc_pipe_fs.h WARNING: header doesn't build standalone: linux/swapops.h WARNING: header doesn't build standalone: linux/synclink.h WARNING: header doesn't build standalone: linux/sysfs.h WARNING: header doesn't build standalone: linux/sysrq.h WARNING: header doesn't build standalone: linux/sysv_fs.h WARNING: header doesn't build standalone: linux/tcp_diag.h WARNING: header doesn't build standalone: linux/times.h WARNING: header doesn't build standalone: linux/trdevice.h WARNING: header doesn't build standalone: linux/tty_driver.h WARNING: header doesn't build standalone: linux/tty_flip.h WARNING: header doesn't build standalone: linux/udf_fs_i.h WARNING: header doesn't build standalone: linux/udf_fs_sb.h WARNING: header doesn't build standalone: linux/ufs_fs_i.h WARNING: header doesn't build standalone: linux/uinput.h WARNING: header doesn't build standalone: linux/umem.h WARNING: header doesn't build standalone: linux/umsdos_fs.h WARNING: header doesn't build standalone: linux/un.h WARNING: header doesn't build standalone: linux/usb_gadget.h WARNING: header doesn't build standalone: linux/usbdevice_fs.h WARNING: header doesn't build standalone: linux/utime.h WARNING: header doesn't build standalone: linux/video_decoder.h WARNING: header doesn't build standalone: linux/video_encoder.h WARNING: header doesn't build standalone: linux/vt_buffer.h WARNING: header doesn't build standalone: linux/watchdog.h WARNING: header doesn't build standalone: linux/writeback.h WARNING: header doesn't build standalone: linux/x25.h WARNING: header doesn't build standalone: linux/zorro.h Jörn -- When in doubt, use brute force. -- Ken Thompson ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] check headers for complete includes, etc. 2003-09-29 13:36 ` [PATCH] check headers for complete includes, etc Jörn Engel 2003-09-29 13:40 ` Jörn Engel @ 2003-09-29 14:50 ` Sam Ravnborg 2003-09-29 15:00 ` Jörn Engel 2003-10-01 9:48 ` [PATCH v2] " Jörn Engel 1 sibling, 2 replies; 37+ messages in thread From: Sam Ravnborg @ 2003-09-29 14:50 UTC (permalink / raw) To: Jörn Engel Cc: Sam Ravnborg, Kernel Mailing List, Linus Torvalds, Russell King, Jamie Lokier On Mon, Sep 29, 2003 at 03:36:24PM +0200, Jörn Engel wrote: > First version of the script. Seems to work, but it catches a lot, > maybe too much. What about adding a negative list, so headerfiles that we decide shall not be able to compile stand-alone are filtered away. But new headers are added. Sam ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] check headers for complete includes, etc. 2003-09-29 14:50 ` Sam Ravnborg @ 2003-09-29 15:00 ` Jörn Engel 2003-09-29 17:10 ` Dominik Kubla 2003-10-01 9:48 ` [PATCH v2] " Jörn Engel 1 sibling, 1 reply; 37+ messages in thread From: Jörn Engel @ 2003-09-29 15:00 UTC (permalink / raw) To: Sam Ravnborg, Kernel Mailing List, Linus Torvalds, Russell King, Jamie Lokier On Mon, 29 September 2003 16:50:57 +0200, Sam Ravnborg wrote: > On Mon, Sep 29, 2003 at 03:36:24PM +0200, Jörn Engel wrote: > > First version of the script. Seems to work, but it catches a lot, > > maybe too much. > > What about adding a negative list, so headerfiles that we decide > shall not be able to compile stand-alone are filtered away. > But new headers are added. Would work. But I'd prefer to have that information inside the header files, under some syntax. /* attr: indirect header */ Is this acceptable? Jörn -- Happiness isn't having what you want, it's wanting what you have. -- unknown ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] check headers for complete includes, etc. 2003-09-29 15:00 ` Jörn Engel @ 2003-09-29 17:10 ` Dominik Kubla 0 siblings, 0 replies; 37+ messages in thread From: Dominik Kubla @ 2003-09-29 17:10 UTC (permalink / raw) To: Jörn Engel, Kernel Mailing List Am Montag, 29. September 2003 17:00 schrieb Jörn Engel: > > Would work. But I'd prefer to have that information inside the header > files, under some syntax. > > /* attr: indirect header */ > > Is this acceptable? Just a suggestion: Make it a define. Comments tend to be re-formatted, "improved", deleted, etc. You get the picture. So I think that: #define PRAGMA_INDIRECT_HEADER TRUE (or something similiar) would be better suited. Regards, Dominik -- Those who can make you believe absurdities can make you commit atrocities. (Francois Marie Arouet aka Voltaire, 1694-1778) ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v2] check headers for complete includes, etc. 2003-09-29 14:50 ` Sam Ravnborg 2003-09-29 15:00 ` Jörn Engel @ 2003-10-01 9:48 ` Jörn Engel 2003-10-01 16:39 ` Sam Ravnborg 1 sibling, 1 reply; 37+ messages in thread From: Jörn Engel @ 2003-10-01 9:48 UTC (permalink / raw) To: Sam Ravnborg, Kernel Mailing List On Mon, 29 September 2003 16:50:57 +0200, Sam Ravnborg wrote: > On Mon, Sep 29, 2003 at 03:36:24PM +0200, Jörn Engel wrote: > > First version of the script. Seems to work, but it catches a lot, > > maybe too much. > > What about adding a negative list, so headerfiles that we decide > shall not be able to compile stand-alone are filtered away. > But new headers are added. New version, picking up suggestions from you, Dominik and Arnd Bergmann: - checks all headers from include/linux and include/asm. - uses nm to find declarations. - ignores headers that "#define PRAGMA_INDIRECT_HEADER" If there are no big complaints, I consider this version to be final. Sam, will you check this and pass it on to Linus? Jörn -- Mundie uses a textbook tactic of manipulation: start with some reasonable talk, and lead the audience to an unreasonable conclusion. -- Bruce Perens --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.0-test5/scripts/checkheader.pl 2003-09-30 21:41:14.000000000 +0200 @@ -0,0 +1,54 @@ +#!/usr/bin/perl -w +use strict; + +my $verbose = 1; # TODO make this optional + +sub prune($) +{ + my $h = shift; + chomp($h); + open(HDR, "include/$h") + or return; + while (<HDR>) { + if ($_ =~ /^#\s*define\s+PRAGMA_INDIRECT_HEADER\s/) { + return; + } + } + close(HDR); + return $h; +} + +my @headers = sort(map({prune($_);} + `(cd include/ && find linux -name "*.h" ; find asm/ -name "*.h")`)); +my $basename = "lib/header"; + +foreach my $h (@headers) { + close(STDERR); + open(STDERR, ">", "$basename.err"); + + open(HC, '>', "$basename.c"); + print(HC "#include <$h>\n"); + close(HC); + + # tests + if (system("make", "$basename.o") != 0) { + print("WARNING: header doesn't build standalone: $h\n"); + if ($verbose) { + system("cat", "$basename.err"); + } + next; + } + + my $symbols = `nm $basename.o`; + if ($symbols !~ /^$/) { + print("WARNING: Symbols may be declared: $h:\n"); + if ($verbose) { + print("$symbols"); + } + } +} continue { + # cleanup + unlink("$basename.c"); + unlink("$basename.err"); + unlink("$basename.o"); +} --- linux-2.6.0-test5/Makefile~headercheck 2003-09-28 21:37:19.000000000 +0200 +++ linux-2.6.0-test5/Makefile 2003-09-29 15:31:13.000000000 +0200 @@ -838,6 +838,9 @@ -name '*.[hcS]' -type f -print | sort \ | xargs $(PERL) -w scripts/checkincludes.pl +headercheck: + $(PERL) scripts/checkheader.pl + versioncheck: find * $(RCS_FIND_IGNORE) \ -name '*.[hcS]' -type f -print | sort \ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v2] check headers for complete includes, etc. 2003-10-01 9:48 ` [PATCH v2] " Jörn Engel @ 2003-10-01 16:39 ` Sam Ravnborg 2003-10-01 17:00 ` Jörn Engel 2003-10-01 18:01 ` [PATCH v3] " Jörn Engel 0 siblings, 2 replies; 37+ messages in thread From: Sam Ravnborg @ 2003-10-01 16:39 UTC (permalink / raw) To: Jörn Engel; +Cc: Sam Ravnborg, Kernel Mailing List On Wed, Oct 01, 2003 at 11:48:25AM +0200, Jörn Engel wrote: > > If there are no big complaints, I consider this version to be final. Some small comments.. > --- /dev/null 1970-01-01 01:00:00.000000000 +0100 > +++ linux-2.6.0-test5/scripts/checkheader.pl 2003-09-30 21:41:14.000000000 +0200 > @@ -0,0 +1,54 @@ > +#!/usr/bin/perl -w > +use strict; > + > +my $verbose = 1; # TODO make this optional Could you make this controlable with option -verbose, see below. > +my @headers = sort(map({prune($_);} > + `(cd include/ && find linux -name "*.h" ; find asm/ -name "*.h")`)); 1) you uses include but asm/ - use final '/' for consistency. 2) Using asm/ you require the symlink to be present. Which obvious it a most when doing this check, so we better secure that. > +my $basename = "lib/header"; I much rather have it be: include/headercheck then people realise where eventual temporary files comes from. So we need something like the following here: (untested) > > +headercheck: prepare-all > + $(PERL) scripts/checkheader.pl $(if $(KBUILD_VERBOSE),-verbose) > + > versioncheck: > find * $(RCS_FIND_IGNORE) \ > -name '*.[hcS]' -type f -print | sort \ With respect to passing on to Linus. I would like to have a bunch of files converted first so we can see the effect of requiring this check. Also I am still a bit uncertain if this is the right approach, but until now this is the only patch... Sam ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v2] check headers for complete includes, etc. 2003-10-01 16:39 ` Sam Ravnborg @ 2003-10-01 17:00 ` Jörn Engel 2003-10-01 18:01 ` [PATCH v3] " Jörn Engel 1 sibling, 0 replies; 37+ messages in thread From: Jörn Engel @ 2003-10-01 17:00 UTC (permalink / raw) To: Sam Ravnborg, Kernel Mailing List On Wed, 1 October 2003 18:39:30 +0200, Sam Ravnborg wrote: > On Wed, Oct 01, 2003 at 11:48:25AM +0200, Jörn Engel wrote: > > > > If there are no big complaints, I consider this version to be final. > Some small comments.. > > > --- /dev/null 1970-01-01 01:00:00.000000000 +0100 > > +++ linux-2.6.0-test5/scripts/checkheader.pl 2003-09-30 21:41:14.000000000 +0200 > > @@ -0,0 +1,54 @@ > > +#!/usr/bin/perl -w > > +use strict; > > + > > +my $verbose = 1; # TODO make this optional > Could you make this controlable with option -verbose, see below. ok. > > +my @headers = sort(map({prune($_);} > > + `(cd include/ && find linux -name "*.h" ; find asm/ -name "*.h")`)); > 1) you uses include but asm/ - use final '/' for consistency. ^^^^^^^ You meant linux, right? Agreed. > 2) Using asm/ you require the symlink to be present. Which obvious > it a most when doing this check, so we better secure that. ok. > > +my $basename = "lib/header"; > I much rather have it be: include/headercheck > then people realise where eventual temporary files comes from. ok. > So we need something like the following here: (untested) > > > > +headercheck: prepare-all > > + $(PERL) scripts/checkheader.pl $(if $(KBUILD_VERBOSE),-verbose) > > + > > versioncheck: > > find * $(RCS_FIND_IGNORE) \ > > -name '*.[hcS]' -type f -print | sort \ > > With respect to passing on to Linus. > I would like to have a bunch of files converted first so we can see the > effect of requiring this check. > Also I am still a bit uncertain if this is the right approach, > but until now this is the only patch... I share your doubts. Considering that the header files only rarely cause problems, some hundred hits sound a bit too much. Also, this should be extended to also warn on unnecessary headers being included, so it drives us both ways. But then again, this is not important enough to me right now to spend too much time on it. Jörn -- Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. -- Rob Pike ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v3] check headers for complete includes, etc. 2003-10-01 16:39 ` Sam Ravnborg 2003-10-01 17:00 ` Jörn Engel @ 2003-10-01 18:01 ` Jörn Engel 2003-10-01 21:09 ` Sam Ravnborg 1 sibling, 1 reply; 37+ messages in thread From: Jörn Engel @ 2003-10-01 18:01 UTC (permalink / raw) To: Sam Ravnborg, Kernel Mailing List On Wed, 1 October 2003 18:39:30 +0200, Sam Ravnborg wrote: > On Wed, Oct 01, 2003 at 11:48:25AM +0200, Jörn Engel wrote: > > > > +my $verbose = 1; # TODO make this optional > Could you make this controlable with option -verbose, see below. -v or --verbose > > +my @headers = sort(map({prune($_);} > > + `(cd include/ && find linux -name "*.h" ; find asm/ -name "*.h")`)); > 1) you uses include but asm/ - use final '/' for consistency. > 2) Using asm/ you require the symlink to be present. Which obvious > it a most when doing this check, so we better secure that. A bit better now, but still not too nice. > > +my $basename = "lib/header"; > I much rather have it be: include/headercheck > then people realise where eventual temporary files comes from. Doesn't work in include/, there is no include/Makefile. But lib/ is a hack, I agree. > So we need something like the following here: (untested) > > > > +headercheck: prepare-all > > + $(PERL) scripts/checkheader.pl $(if $(KBUILD_VERBOSE),-verbose) > > + What is prepare-all supposed to do? Target doesn't exist. Changed option to --verbose, see above. make headercheck, make V=0 headercheck and make V=1 headercheck are all verbose. Is this intended? Jörn -- Victory in war is not repetitious. -- Sun Tzu --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.0-test5/scripts/checkheader.pl 2003-10-01 19:54:26.000000000 +0200 @@ -0,0 +1,63 @@ +#!/usr/bin/perl -w +use strict; +use Getopt::Long; + +Getopt::Long::Configure("no_auto_abbrev"); # Could cause unexpected things +Getopt::Long::Configure("bundling"); # We want -sA to work +Getopt::Long::Configure("no_ignore_case"); # We don't want -a == -A + +my $verbose = 0; + +GetOptions('v|verbose' => \$verbose) || die("bad options"); + + +sub prune($) +{ + my $h = shift; + chomp($h); + open(HDR, "include/$h") + or return; + while (<HDR>) { + if ($_ =~ /^#\s*define\s+PRAGMA_INDIRECT_HEADER\s/) { + return; + } + } + close(HDR); + return $h; +} + +my @headers = sort(map({prune($_);} `(cd include/ && + [ -d linux/ ] && find linux/ -name "*.h" && + [ -d asm/ ] && find asm/ -name "*.h")`)); # XXX this is fragile +my $basename = "lib/headercheck"; + +foreach my $h (@headers) { + close(STDERR); + open(STDERR, ">", "$basename.err"); + + open(HC, '>', "$basename.c"); + print(HC "#include <$h>\n"); + close(HC); + + # tests + if (system("make", "$basename.o") != 0) { + print("WARNING: header doesn't build standalone: $h\n"); + if ($verbose) { + system("cat", "$basename.err"); + } + next; + } + + my $symbols = `nm $basename.o`; + if ($symbols !~ /^$/) { + print("WARNING: Symbols may be declared: $h:\n"); + if ($verbose) { + print("$symbols"); + } + } +} continue { + # cleanup + unlink("$basename.c"); + unlink("$basename.err"); + unlink("$basename.o"); +} --- linux-2.6.0-test5/Makefile~headercheck 2003-10-01 19:48:46.000000000 +0200 +++ linux-2.6.0-test5/Makefile 2003-10-01 19:53:38.000000000 +0200 @@ -833,6 +833,9 @@ -name '*.[hcS]' -type f -print | sort \ | xargs $(PERL) -w scripts/checkconfig.pl +headercheck: + $(PERL) scripts/checkheader.pl $(if $(KBUILD_VERBOSE),--verbose) + includecheck: find * $(RCS_FIND_IGNORE) \ -name '*.[hcS]' -type f -print | sort \ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v3] check headers for complete includes, etc. 2003-10-01 18:01 ` [PATCH v3] " Jörn Engel @ 2003-10-01 21:09 ` Sam Ravnborg 2003-10-02 8:37 ` [PATCH v4] " Jörn Engel 0 siblings, 1 reply; 37+ messages in thread From: Sam Ravnborg @ 2003-10-01 21:09 UTC (permalink / raw) To: Jörn Engel; +Cc: Sam Ravnborg, Kernel Mailing List On Wed, Oct 01, 2003 at 08:01:14PM +0200, Jörn Engel wrote: > > > +my $basename = "lib/header"; > > I much rather have it be: include/headercheck > > then people realise where eventual temporary files comes from. > > Doesn't work in include/, there is no include/Makefile. But lib/ is a > hack, I agree. Sigh, OK. > > So we need something like the following here: (untested) > > > > > > +headercheck: prepare-all > > > + $(PERL) scripts/checkheader.pl $(if $(KBUILD_VERBOSE),-verbose) > > > + Forgot that KBUILD_VERBOSE is always defined. Try: $(if $(KBUILD_VERBOSE:0=),--verbose) prepare-all exist in BK-latest. The purpose is to create the asm-$(ARCH) -> asm symlink. Add an dependency on include/asm, that should do it. Try: make mrproper make headercheck To test it before and after. Sam ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v4] check headers for complete includes, etc. 2003-10-01 21:09 ` Sam Ravnborg @ 2003-10-02 8:37 ` Jörn Engel 0 siblings, 0 replies; 37+ messages in thread From: Jörn Engel @ 2003-10-02 8:37 UTC (permalink / raw) To: Sam Ravnborg, Kernel Mailing List On Wed, 1 October 2003 23:09:26 +0200, Sam Ravnborg wrote: > On Wed, Oct 01, 2003 at 08:01:14PM +0200, Jörn Engel wrote: > > > > Doesn't work in include/, there is no include/Makefile. But lib/ is a > > hack, I agree. > > Sigh, OK. Things can be so simple: touch include/Makefile :) > > > So we need something like the following here: (untested) > > > > > > > > +headercheck: prepare-all > > > > + $(PERL) scripts/checkheader.pl $(if $(KBUILD_VERBOSE),-verbose) > > > > + > > Forgot that KBUILD_VERBOSE is always defined. > Try: > $(if $(KBUILD_VERBOSE:0=),--verbose) Works, except for one oddity/bug. Not defining V=something on the command line sets KBUILD_VERBOSE = "0 ". Note the space behind the 0. Suggestions? > prepare-all exist in BK-latest. > The purpose is to create the asm-$(ARCH) -> asm symlink. > Add an dependency on include/asm, that should do it. Too lazy to move to BK-Latest for now. Dependency on include/asm it is. :) One more thing: Since the Makefile target is *check, not check*, I've renamed the script to headercheck.pl. This is inconsistent with the existing scripts, but makes more sense to me. Hope you don't mind. Jörn -- Time? What's that? Time is only worth what you do with it. -- Theo de Raadt --- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.0-test5/scripts/headercheck.pl 2003-10-02 10:27:54.000000000 +0200 @@ -0,0 +1,65 @@ +#!/usr/bin/perl -w +use strict; +use Getopt::Long; + +Getopt::Long::Configure("no_auto_abbrev"); # Could cause unexpected things +Getopt::Long::Configure("bundling"); # We want -sA to work +Getopt::Long::Configure("no_ignore_case"); # We don't want -a == -A + +my $verbose = 0; + +GetOptions('v|verbose' => \$verbose) || die("bad options"); + + +sub prune($) +{ + my $h = shift; + chomp($h); + open(HDR, "include/$h") + or return; + while (<HDR>) { + if ($_ =~ /^#\s*define\s+PRAGMA_INDIRECT_HEADER\s/) { + return; + } + } + close(HDR); + return $h; +} + +my @headers = sort(map({prune($_);} `(cd include/ && + [ -d linux/ ] && find linux/ -name "*.h" && + [ -d asm/ ] && find asm/ -name "*.h")`)); # XXX this is fragile +my $basename = "include/headercheck"; +system("touch", "include/Makefile"); + +foreach my $h (@headers) { + close(STDERR); + open(STDERR, ">", "$basename.err"); + + open(HC, '>', "$basename.c"); + print(HC "#include <$h>\n"); + close(HC); + + # tests + if (system("make", "$basename.o") != 0) { + print("WARNING: header doesn't build standalone: $h\n"); + if ($verbose) { + system("cat", "$basename.err"); + } + next; + } + + my $symbols = `nm $basename.o`; + if ($symbols !~ /^$/) { + print("WARNING: Symbols may be declared: $h:\n"); + if ($verbose) { + print("$symbols"); + } + } +} continue { + # cleanup + unlink("$basename.c"); + unlink("$basename.err"); + unlink("$basename.o"); +} +unlink("system/Makefile"); --- linux-2.6.0-test5/Makefile~headercheck 2003-10-02 10:27:19.000000000 +0200 +++ linux-2.6.0-test5/Makefile 2003-10-02 10:35:27.000000000 +0200 @@ -833,6 +833,9 @@ -name '*.[hcS]' -type f -print | sort \ | xargs $(PERL) -w scripts/checkconfig.pl +headercheck: include/asm + $(PERL) scripts/headercheck.pl $(if $(KBUILD_VERBOSE:0=),--verbose) + includecheck: find * $(RCS_FIND_IGNORE) \ -name '*.[hcS]' -type f -print | sort \ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 19:16 ` Jörn Engel 2003-09-28 19:31 ` Sam Ravnborg @ 2003-09-28 19:42 ` Russell King 2003-09-28 20:00 ` Jörn Engel 2003-09-29 15:08 ` Linux 2.6.0-test6 Chris Friesen 1 sibling, 2 replies; 37+ messages in thread From: Russell King @ 2003-09-28 19:42 UTC (permalink / raw) To: Jörn Engel Cc: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg On Sun, Sep 28, 2003 at 09:16:22PM +0200, Jörn Engel wrote: > How about a check_headers target that roughly works like this: > > for (all header files in include/linux and include/asm) { > echo "#include <$HEADER>" > header.c > make header.o > rm header.c header.o > } > > Did a quick test for linux/fs.h in -test5 and it compiled fine, but > broke after removing some random #include. > > Another thing, Sam, "make header.o" causes make to call itself > indefinitely. Had to "make somedir/header.o". Not sure if you > consider this to be a bug, your decision. I have a bad feeling about this, so I'll make the following comments up front before all the reports start rolling in. It may be a good idea to document this somewhere. (Coding style?) If a header has something like these: struct my_headers_struct { struct task_struct *tsk; }; void my_function(struct task_struct *tsk); and gcc warns that "struct task_struct" has not been declared, please don't think about adding another header. Just declare the structure in the header file which needs it like this: struct task_struct; and that will prevent the #include maze of 2.4, which resulted in everything being rebuilt just because one header file was touched. -- Russell King (rmk@arm.linux.org.uk) http://www.arm.linux.org.uk/personal/ Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 19:42 ` Linux 2.6.0-test6 Russell King @ 2003-09-28 20:00 ` Jörn Engel 2003-09-28 21:43 ` Tim Schmielau 2003-10-02 16:16 ` [PATCH] remove unnecessary #includes from <linux/fs.h> Jörn Engel 2003-09-29 15:08 ` Linux 2.6.0-test6 Chris Friesen 1 sibling, 2 replies; 37+ messages in thread From: Jörn Engel @ 2003-09-28 20:00 UTC (permalink / raw) To: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg, Russell King On Sun, 28 September 2003 20:42:24 +0100, Russell King wrote: > > I have a bad feeling about this, so I'll make the following comments > up front before all the reports start rolling in. It may be a good > idea to document this somewhere. (Coding style?) > > If a header has something like these: > > struct my_headers_struct { > struct task_struct *tsk; > }; > > void my_function(struct task_struct *tsk); > > and gcc warns that "struct task_struct" has not been declared, please > don't think about adding another header. Just declare the structure > in the header file which needs it like this: > > struct task_struct; > > and that will prevent the #include maze of 2.4, which resulted in > everything being rebuilt just because one header file was touched. Ok, how about this: for each header file { make header.o 1) if it doesn't build { print out a warning continue } for each #include line { remove the #include line make header.o 2) if it build { print out a warning } 3) if there are less than x gcc warnings { print out a warning } } } 1) is my old proposal. 2) is the natural counterpart. 3) could be what you want. If some header is only needed for something like your example, we may be able to catch it this way. Would this work? Would something else work even better? Jörn -- Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 20:00 ` Jörn Engel @ 2003-09-28 21:43 ` Tim Schmielau 2003-09-28 21:54 ` Arnaldo Carvalho de Melo 2003-10-02 16:16 ` [PATCH] remove unnecessary #includes from <linux/fs.h> Jörn Engel 1 sibling, 1 reply; 37+ messages in thread From: Tim Schmielau @ 2003-09-28 21:43 UTC (permalink / raw) To: Jörn Engel Cc: Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg, Russell King > Ok, how about this: > > for each header file { > make header.o > 1) if it doesn't build { > print out a warning > continue > } > for each #include line { > remove the #include line > make header.o > 2) if it build { > print out a warning > } > 3) if there are less than x gcc warnings { > print out a warning > } > } > } > > 1) is my old proposal. 2) is the natural counterpart. 3) could be > what you want. If some header is only needed for something like your > example, we may be able to catch it this way. > > Would this work? Would something else work even better? Problem is, this depends too much on the specific configuration, and thus will never be a general solution (will generate false positives and false negatives). Might be a good start, though. Tim P.S.: My secret plan is to write a parser or hack sparse to do this for both #if and #else branches of conditionals at the same time. This however, is a big project, and I don't think of even _starting_ this before next year. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 21:43 ` Tim Schmielau @ 2003-09-28 21:54 ` Arnaldo Carvalho de Melo 0 siblings, 0 replies; 37+ messages in thread From: Arnaldo Carvalho de Melo @ 2003-09-28 21:54 UTC (permalink / raw) To: Tim Schmielau Cc: Jörn Engel, Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg, Russell King Em Sun, Sep 28, 2003 at 11:43:08PM +0200, Tim Schmielau escreveu: > P.S.: My secret plan is to write a parser or hack sparse to do this for > both #if and #else branches of conditionals at the same time. This > however, is a big project, and I don't think of even _starting_ this > before next year. Well, I plan to work on a sparse tool that builds a ctags like database from all the headers, removes the includes and puts the necessary ones, some spurious cases can happen, as we don't have the best namespace in the world in our includes, but hey, janitors could handle such a task, fixing the namespace :-) - Arnaldo ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH] remove unnecessary #includes from <linux/fs.h> 2003-09-28 20:00 ` Jörn Engel 2003-09-28 21:43 ` Tim Schmielau @ 2003-10-02 16:16 ` Jörn Engel 2003-10-02 17:22 ` Sam Ravnborg 2003-10-03 15:03 ` Tim Schmielau 1 sibling, 2 replies; 37+ messages in thread From: Jörn Engel @ 2003-10-02 16:16 UTC (permalink / raw) To: Russell King, Kernel Mailing List, Sam Ravnborg On Sun, 28 September 2003 22:00:01 +0200, Jörn Engel wrote: > On Sun, 28 September 2003 20:42:24 +0100, Russell King wrote: > > > > and that will prevent the #include maze of 2.4, which resulted in > > everything being rebuilt just because one header file was touched. > > Ok, how about this: > > for each header file { > make header.o > 1) if it doesn't build { > print out a warning > continue > } > for each #include line { > remove the #include line > make header.o > 2) if it build { > print out a warning > } > 3) if there are less than x gcc warnings { > print out a warning > } > } > } You didn't comment on my suggestion, so I've done it manually once for linux/fs.h and was shocked. It still passes my compile-standalone test after removing 11! #include lines. Another one was a false hit, because I compiled UP only, and some of the remaining may be as well, but it looks like we recompile way too much after changes to a random header. Russell, can you comment this time, or should I shove the patch to Linus and wait if anyone starts screaming? Jörn -- Sometimes, asking the right question is already the answer. -- Unknown --- linux-2.6.0-test5/include/linux/fs.h~include_prune 2003-10-02 18:07:20.000000000 +0200 +++ linux-2.6.0-test5/include/linux/fs.h 2003-10-02 18:09:41.000000000 +0200 @@ -6,20 +6,11 @@ * structures etc. */ -#include <linux/config.h> -#include <linux/linkage.h> -#include <linux/limits.h> -#include <linux/wait.h> -#include <linux/types.h> #include <linux/kdev_t.h> -#include <linux/ioctl.h> -#include <linux/list.h> #include <linux/dcache.h> #include <linux/stat.h> -#include <linux/cache.h> #include <linux/radix-tree.h> #include <linux/kobject.h> -#include <asm/atomic.h> struct iovec; struct nameidata; @@ -208,7 +199,6 @@ #ifdef __KERNEL__ #include <asm/semaphore.h> -#include <asm/byteorder.h> /* Used to be a macro which just called the function, now just a function */ extern void update_atime (struct inode *); @@ -1236,8 +1226,6 @@ extern int is_subdir(struct dentry *, struct dentry *); extern ino_t find_inode_number(struct dentry *, struct qstr *); -#include <linux/err.h> - /* needed for stackable file system support */ extern loff_t default_llseek(struct file *file, loff_t offset, int origin); ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] remove unnecessary #includes from <linux/fs.h> 2003-10-02 16:16 ` [PATCH] remove unnecessary #includes from <linux/fs.h> Jörn Engel @ 2003-10-02 17:22 ` Sam Ravnborg 2003-10-02 17:26 ` Jörn Engel 2003-10-03 15:03 ` Tim Schmielau 1 sibling, 1 reply; 37+ messages in thread From: Sam Ravnborg @ 2003-10-02 17:22 UTC (permalink / raw) To: Jörn Engel; +Cc: Russell King, Kernel Mailing List, Sam Ravnborg On Thu, Oct 02, 2003 at 06:16:39PM +0200, Jörn Engel wrote: > > You didn't comment on my suggestion, so I've done it manually once for > linux/fs.h and was shocked. It still passes my compile-standalone > test after removing 11! #include lines. Be careful here. Maybe fs.h passes your compile test, but it may break other users of fs.h, that relyed on a certain .h file to be included by fs.h. This kind of clean-up belongs to 2.7. Sam ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] remove unnecessary #includes from <linux/fs.h> 2003-10-02 17:22 ` Sam Ravnborg @ 2003-10-02 17:26 ` Jörn Engel 0 siblings, 0 replies; 37+ messages in thread From: Jörn Engel @ 2003-10-02 17:26 UTC (permalink / raw) To: Russell King, Kernel Mailing List, Sam Ravnborg On Thu, 2 October 2003 19:22:19 +0200, Sam Ravnborg wrote: > On Thu, Oct 02, 2003 at 06:16:39PM +0200, Jörn Engel wrote: > > > > You didn't comment on my suggestion, so I've done it manually once for > > linux/fs.h and was shocked. It still passes my compile-standalone > > test after removing 11! #include lines. > > Be careful here. > Maybe fs.h passes your compile test, but it may break other users of > fs.h, that relyed on a certain .h file to be included by fs.h. > This kind of clean-up belongs to 2.7. Agreed. Maybe Tim has his check-both-branches approach finished by then, too. Jörn -- Good warriors cause others to come to them and do not go to others. -- Sun Tzu ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] remove unnecessary #includes from <linux/fs.h> 2003-10-02 16:16 ` [PATCH] remove unnecessary #includes from <linux/fs.h> Jörn Engel 2003-10-02 17:22 ` Sam Ravnborg @ 2003-10-03 15:03 ` Tim Schmielau 1 sibling, 0 replies; 37+ messages in thread From: Tim Schmielau @ 2003-10-03 15:03 UTC (permalink / raw) To: Jörn Engel; +Cc: Russell King, Kernel Mailing List, Sam Ravnborg > You didn't comment on my suggestion, so I've done it manually once for > linux/fs.h and was shocked. It still passes my compile-standalone > test after removing 11! #include lines. A compile-standalone test is a necessary condition but not a sufficient one. There can be many reasons why the includes might still be needed: - the compile-test might depend on the specific configuration. - the included header might be needed when the macros are used, not when they are defined. - indirect includes - ... As you probably know, I tried to clean up sched.h, and it was extremely complicated to get right. So this definitely is 2.7 material. Tim ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 19:42 ` Linux 2.6.0-test6 Russell King 2003-09-28 20:00 ` Jörn Engel @ 2003-09-29 15:08 ` Chris Friesen 2003-09-29 15:14 ` Geert Uytterhoeven 1 sibling, 1 reply; 37+ messages in thread From: Chris Friesen @ 2003-09-29 15:08 UTC (permalink / raw) To: Russell King Cc: Jörn Engel, Linus Torvalds, Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg Russell King wrote: > If a header has something like these: > > struct my_headers_struct { > struct task_struct *tsk; > }; > > void my_function(struct task_struct *tsk); > > and gcc warns that "struct task_struct" has not been declared, please > don't think about adding another header. Just declare the structure > in the header file which needs it like this: > > struct task_struct; If I do that, make a change to task_struct, then run make, will the file get rebuilt? Chris -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen@nortelnetworks.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-29 15:08 ` Linux 2.6.0-test6 Chris Friesen @ 2003-09-29 15:14 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2003-09-29 15:14 UTC (permalink / raw) To: Chris Friesen Cc: Russell King, Jörn Engel, Linus Torvalds, Bernardo Innocenti, Kernel Mailing List, Sam Ravnborg On Mon, 29 Sep 2003, Chris Friesen wrote: > Russell King wrote: > > If a header has something like these: > > > > struct my_headers_struct { > > struct task_struct *tsk; > > }; > > > > void my_function(struct task_struct *tsk); > > > > and gcc warns that "struct task_struct" has not been declared, please > > don't think about adding another header. Just declare the structure > > in the header file which needs it like this: > > > > struct task_struct; > > If I do that, make a change to task_struct, then run make, will the file > get rebuilt? No. But using that definition all you can do (without warnings) is passing pointers to the struct around, which is OK. If you want to play with the internals of the structure, you have to include the right header file anyway. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 17:37 ` Linus Torvalds 2003-09-28 18:46 ` Sam Ravnborg @ 2003-09-28 19:28 ` Russell King 2003-09-29 8:52 ` Geert Uytterhoeven 2003-09-29 19:19 ` bill davidsen 2 siblings, 1 reply; 37+ messages in thread From: Russell King @ 2003-09-28 19:28 UTC (permalink / raw) To: Linus Torvalds Cc: Geert Uytterhoeven, Bernardo Innocenti, Kernel Mailing List On Sun, Sep 28, 2003 at 10:37:36AM -0700, Linus Torvalds wrote: > On Sun, 28 Sep 2003, Geert Uytterhoeven wrote: > > On Sat, 27 Sep 2003, Linus Torvalds wrote: > > > Bernardo Innocenti: > > > o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h > > > > This change breaks 2.95 for some source files, because <linux/init.h> doesn't > > include <linux/compiler.h>. Do you want to have the missing include added to > > <linux/init.h>, or to the individual source files that need it? > > Interesting. I'm pretty sure I did a "make allyesconfig" just before the > test6 release, so apparently x86 includes it indirectly through some path, > and so it only shows up on m68k and arm? > > This, btw, is a pretty common thing. I wonder what we could do to make > sure that different architectures wouldn't have so different include file > structures. It's happened _way_ too often. > > Any ideas? The two files that it showed up in on ARM are fairly simple in nature and don't include may headers. Making the ARM include structure identical to x86 wouldn't have removed the problem from ARM. -- Russell King (rmk@arm.linux.org.uk) http://www.arm.linux.org.uk/personal/ Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 19:28 ` Russell King @ 2003-09-29 8:52 ` Geert Uytterhoeven 0 siblings, 0 replies; 37+ messages in thread From: Geert Uytterhoeven @ 2003-09-29 8:52 UTC (permalink / raw) To: Russell King; +Cc: Linus Torvalds, Bernardo Innocenti, Kernel Mailing List On Sun, 28 Sep 2003, Russell King wrote: > On Sun, Sep 28, 2003 at 10:37:36AM -0700, Linus Torvalds wrote: > > On Sun, 28 Sep 2003, Geert Uytterhoeven wrote: > > > On Sat, 27 Sep 2003, Linus Torvalds wrote: > > > > Bernardo Innocenti: > > > > o GCC 3.3.x/3.4 compatiblity fix in include/linux/init.h > > > > > > This change breaks 2.95 for some source files, because <linux/init.h> doesn't > > > include <linux/compiler.h>. Do you want to have the missing include added to > > > <linux/init.h>, or to the individual source files that need it? > > > > Interesting. I'm pretty sure I did a "make allyesconfig" just before the > > test6 release, so apparently x86 includes it indirectly through some path, > > and so it only shows up on m68k and arm? > > > > This, btw, is a pretty common thing. I wonder what we could do to make > > sure that different architectures wouldn't have so different include file > > structures. It's happened _way_ too often. > > > > Any ideas? > > The two files that it showed up in on ARM are fairly simple in nature and > don't include may headers. Making the ARM include structure identical to > x86 wouldn't have removed the problem from ARM. Same for m68k. The offender was a m68k-specific file (arch/m68k/sun3/sbus.c), which just included <linux/types.h> and <linux/init.h>, and uses subsys_initcall(). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-28 17:37 ` Linus Torvalds 2003-09-28 18:46 ` Sam Ravnborg 2003-09-28 19:28 ` Russell King @ 2003-09-29 19:19 ` bill davidsen 2003-09-30 10:42 ` Jörn Engel 2 siblings, 1 reply; 37+ messages in thread From: bill davidsen @ 2003-09-29 19:19 UTC (permalink / raw) To: linux-kernel In article <Pine.LNX.4.44.0309281035370.6307-100000@home.osdl.org>, Linus Torvalds <torvalds@osdl.org> wrote: | Interesting. I'm pretty sure I did a "make allyesconfig" just before the | test6 release, so apparently x86 includes it indirectly through some path, | and so it only shows up on m68k and arm? | | This, btw, is a pretty common thing. I wonder what we could do to make | sure that different architectures wouldn't have so different include file | structures. It's happened _way_ too often. | | Any ideas? If CPU cycles are no object the include names and order can be picked out of the preprocessor output, add "-E" to the gcc call, pick only the lines starting with "1" and a header name, save in a text file. The problem is that config option (including arch) change the output, so it's only useful as a rough check. It does run fast enough so that allyes, allno, and allmod configs take a very short time, so it can be used for "find some of the problems." Don't know if this is what you wanted, it does allow the comparison between arch's. Oh, it also shows that some headers are used a lot more than they need be, a few more ifdef's in the low level header files could reduce filesystem thrashing during a build. Some folks have machines which don't keep everything in memory :-( -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-29 19:19 ` bill davidsen @ 2003-09-30 10:42 ` Jörn Engel 2003-09-30 15:17 ` Bill Davidsen 0 siblings, 1 reply; 37+ messages in thread From: Jörn Engel @ 2003-09-30 10:42 UTC (permalink / raw) To: bill davidsen; +Cc: linux-kernel On Mon, 29 September 2003 19:19:30 +0000, bill davidsen wrote: > In article <Pine.LNX.4.44.0309281035370.6307-100000@home.osdl.org>, > Linus Torvalds <torvalds@osdl.org> wrote: > > | Interesting. I'm pretty sure I did a "make allyesconfig" just before the > | test6 release, so apparently x86 includes it indirectly through some path, > | and so it only shows up on m68k and arm? > | > | This, btw, is a pretty common thing. I wonder what we could do to make > | sure that different architectures wouldn't have so different include file > | structures. It's happened _way_ too often. > | > | Any ideas? > > If CPU cycles are no object the include names and order can be picked > out of the preprocessor output, add "-E" to the gcc call, pick only the > lines starting with "1" and a header name, save in a text file. The > problem is that config option (including arch) change the output, so > it's only useful as a rough check. How is this better than adding "-H", as Jamie suggested? > Don't know if this is what you wanted, it does allow the comparison > between arch's. Oh, it also shows that some headers are used a lot more > than they need be, a few more ifdef's in the low level header files > could reduce filesystem thrashing during a build. Some folks have > machines which don't keep everything in memory :-( How do you find the correct places to prune include lines? Jörn -- A defeated army first battles and then seeks victory. -- Sun Tzu ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-30 10:42 ` Jörn Engel @ 2003-09-30 15:17 ` Bill Davidsen 2003-10-01 9:08 ` Jörn Engel 0 siblings, 1 reply; 37+ messages in thread From: Bill Davidsen @ 2003-09-30 15:17 UTC (permalink / raw) To: Jörn Engel; +Cc: linux-kernel [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 1385 bytes --] On Tue, 30 Sep 2003, [iso-8859-1] Jörn Engel wrote: > On Mon, 29 September 2003 19:19:30 +0000, bill davidsen wrote: > > In article <Pine.LNX.4.44.0309281035370.6307-100000@home.osdl.org>, > > Linus Torvalds <torvalds@osdl.org> wrote: > > > > | Interesting. I'm pretty sure I did a "make allyesconfig" just before the > > | test6 release, so apparently x86 includes it indirectly through some path, > > | and so it only shows up on m68k and arm? > > | > > | This, btw, is a pretty common thing. I wonder what we could do to make > > | sure that different architectures wouldn't have so different include file > > | structures. It's happened _way_ too often. > > | > > | Any ideas? > > > > If CPU cycles are no object the include names and order can be picked > > out of the preprocessor output, add "-E" to the gcc call, pick only the > > lines starting with "1" and a header name, save in a text file. The > > problem is that config option (including arch) change the output, so > > it's only useful as a rough check. > > How is this better than adding "-H", as Jamie suggested? I didn't see that in Linus' post, and still don't. I suspect you're thinking of some post which came later. Linus asked for ideas, I supplied one, sorry it offends you. -- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Linux 2.6.0-test6 2003-09-30 15:17 ` Bill Davidsen @ 2003-10-01 9:08 ` Jörn Engel 0 siblings, 0 replies; 37+ messages in thread From: Jörn Engel @ 2003-10-01 9:08 UTC (permalink / raw) To: Bill Davidsen; +Cc: linux-kernel On Tue, 30 September 2003 11:17:51 -0400, Bill Davidsen wrote: > On Tue, 30 Sep 2003, [iso-8859-1] J?rn Engel wrote: > > > > How is this better than adding "-H", as Jamie suggested? > > I didn't see that in Linus' post, and still don't. I suspect you're > thinking of some post which came later. Linus asked for ideas, I supplied > one, sorry it offends you. Ok, my bad. I wasn't offended, just curious, which one of the suggestions would be the best. Jamie's idea of using -H looks better to me than yours, but maybe I have missed something, so I asked. For some reason, I often miss the tone. Any emotional stuff in my posts is unintended, useless and should be removed before sending. Sorry! Jörn PS: So, does your idea have advantages over Jamie's that I missed? -- "Translations are and will always be problematic. They inflict violence upon two languages." (translation from German) ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2003-10-03 15:04 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-09-28 10:14 Linux 2.6.0-test6 Geert Uytterhoeven 2003-09-28 12:50 ` Russell King 2003-09-28 13:54 ` Bernardo Innocenti 2003-09-28 17:37 ` Linus Torvalds 2003-09-28 18:46 ` Sam Ravnborg 2003-09-28 18:52 ` Linus Torvalds 2003-09-28 19:44 ` Jamie Lokier 2003-09-28 19:16 ` Jörn Engel 2003-09-28 19:31 ` Sam Ravnborg 2003-09-28 19:44 ` Jörn Engel 2003-09-29 13:36 ` [PATCH] check headers for complete includes, etc Jörn Engel 2003-09-29 13:40 ` Jörn Engel 2003-09-29 14:50 ` Sam Ravnborg 2003-09-29 15:00 ` Jörn Engel 2003-09-29 17:10 ` Dominik Kubla 2003-10-01 9:48 ` [PATCH v2] " Jörn Engel 2003-10-01 16:39 ` Sam Ravnborg 2003-10-01 17:00 ` Jörn Engel 2003-10-01 18:01 ` [PATCH v3] " Jörn Engel 2003-10-01 21:09 ` Sam Ravnborg 2003-10-02 8:37 ` [PATCH v4] " Jörn Engel 2003-09-28 19:42 ` Linux 2.6.0-test6 Russell King 2003-09-28 20:00 ` Jörn Engel 2003-09-28 21:43 ` Tim Schmielau 2003-09-28 21:54 ` Arnaldo Carvalho de Melo 2003-10-02 16:16 ` [PATCH] remove unnecessary #includes from <linux/fs.h> Jörn Engel 2003-10-02 17:22 ` Sam Ravnborg 2003-10-02 17:26 ` Jörn Engel 2003-10-03 15:03 ` Tim Schmielau 2003-09-29 15:08 ` Linux 2.6.0-test6 Chris Friesen 2003-09-29 15:14 ` Geert Uytterhoeven 2003-09-28 19:28 ` Russell King 2003-09-29 8:52 ` Geert Uytterhoeven 2003-09-29 19:19 ` bill davidsen 2003-09-30 10:42 ` Jörn Engel 2003-09-30 15:17 ` Bill Davidsen 2003-10-01 9:08 ` Jörn Engel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).