[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45390CAC.7090409@s5r6.in-berlin.de>
Date: Fri, 20 Oct 2006 19:51:40 +0200
From: Stefan Richter <stefanr@...6.in-berlin.de>
To: Randy Dunlap <rdunlap@...otime.net>
CC: Al Viro <viro@....linux.org.uk>,
Linus Torvalds <torvalds@...l.org>,
Alexey Dobriyan <adobriyan@...il.com>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: dealing with excessive includes
Randy Dunlap wrote:
> On Fri, 20 Oct 2006 11:26:58 +0200 Stefan Richter wrote:
>> I am afraid in many of these cases a proper cleanup would _replace_ the
>> include by the correct one, not just delete it. For example,
>> drivers/ieee1394/raw1394.c should include linux/spinlock.h. AFAICS it
>> does so at the moment only indirectly via another header.
>
> I don't think that we can fix it all at once. This is just one step.
> AFAICT for raw1394.c, it's not incorrect as is, but more is needed,
> sure.
Yes, it's probably still correct after your patch. I just referred to
the sensible rule that necessary headers should be directly included
where they are used, not indirectly via other headers.
> Yes, we have lots of header include indirection going on.
> I don't know of a good tool to detect/fix it.
Me neither. I manually cleansed the ieee1394 core's and sbp2's includes
recently; this is a mind-numbing janitorial job.
> What Al is doing is good stuff, but I'd still prefer to see an even
> better tool, like gcc-preprocessor or sparse based (I guess).
On the surface, tools like LXR and cscope "know" where function are
declared or macros and types are defined. But oftentimes, other headers
than these tools turn up are to be included by API users. Cf. the
definition of atomic_t. (IOW the "necessary" header is not always the
one which has the actual definition.)
--
Stefan Richter
-=====-=-==- =-=- =-=--
http://arcgraph.de/sr/
-
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