Re: Linux 2.6.0-test6

From: Jörn Engel (joern_at_wohnheim.fh-wedel.de)
Date: 09/28/03

  • Next message: Jurgen Kramer: "[2.6.0-test6] ALSA: Trident (sis7018) depends on gameport?"
    Date:	Sun, 28 Sep 2003 22:00:01 +0200
    To: Linus Torvalds <torvalds@osdl.org>, Geert Uytterhoeven <geert@linux-m68k.org>, Bernardo Innocenti <bernie@develer.com>, Kernel Mailing List <linux-kernel@vger.kernel.org>, Sam Ravnborg <sam@ravnborg.org>, Russell King <rmk@arm.linux.org.uk>
    
    

    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 
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Jurgen Kramer: "[2.6.0-test6] ALSA: Trident (sis7018) depends on gameport?"

    Relevant Pages

    • Re: Linux GPL and binary module exception clause?
      ... > | I didn't exactly specify how the interfacing would be done because that's ... > | with the proper structure offsets etc. ... > that reading the header file and then using absolute numbers isn't ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC][PATCH] Rename PageChecked as PageMiscFS
      ... Pavel Machek wrote: ... I disagree again. ... use (you can't rely on them going and looking in the header file for a ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] Make scsi.h nominally userspace-clean
      ... > scsi/scsi.h does not compile cleanly in userspace programs due to its ... > I do not argue that including this header file in a program is ... but other kernel headers already take as many precautions ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
      ... > to get the thread-safe updates for some architectures. ... because I've gotten queries from some projects that wanted to copy the ... include the header file. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] CKRM 1/10: Base CKRM Events
      ... for improper usage of it. ... Why not use the kernel list structures here instead? ... Why have 2 different sections in the same header file for this check? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)

    Loading