From: Al Viro <viro@ftp.linux.org.uk>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: dealing with excessive includes
Date: Thu, 19 Oct 2006 17:23:08 +0100 [thread overview]
Message-ID: <20061019162308.GT29920@ftp.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.64.0610180926380.3962@g5.osdl.org>
On Wed, Oct 18, 2006 at 09:32:08AM -0700, Linus Torvalds wrote:
> That said, I'd rather do any lock_super() cleanup totally _independently_
> of a include file cleanup.
>
> So since it's clearly not performance-critical, how about just making it
> be out-of-line in fs/super.c, and turn the header file into just a
> declaration?
Next fun question on strategy: we have a very good bunch of candidates on
killable includes in skbuff.h - highmem.h, mm.h and poll.h. I've done
preliminary variants on amd64 and they give nice reductions of deps
counts with small patches. The tricky part is a couple of helpers -
k{un,}map_skb_frag(). They require highmem.h; nothing else in skbuff.h
does. Only two places are using them - net/core/skbuff.c and
net/appletalk/ddp.c (the latter in one function - dealing with Apple's
take on checksums[1]).
Possible variants:
* turn into macros. Works for a test run, not nice for final
variant.
* new header just for those two in include/net
* new header in net/core, with ddp.c including ../core/skb_kmap.h
* inline in net/core/skbuff.h, extern in ddp.c; then normal paths
get it inlined and appletalk can live with uninlined version.
Preferences?
[1] appletalk: the proof that Vogon neuroanatomy was not entirely fictional.
next prev parent reply other threads:[~2006-10-19 16:23 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-17 0:50 [RFC] typechecking for get_unaligned/put_unaligned Al Viro
2006-10-17 1:50 ` Linus Torvalds
2006-10-17 4:37 ` Al Viro
2006-10-17 15:12 ` Bogus deps checking (was Re: [RFC] typechecking for get_unaligned/put_unaligned) Ray Lehtiniemi
2006-10-17 15:24 ` [RFC] typechecking for get_unaligned/put_unaligned Linus Torvalds
2006-10-18 4:40 ` dealing with excessive includes Al Viro
2006-10-18 9:19 ` Alexey Dobriyan
2006-10-18 9:31 ` Al Viro
2006-10-18 10:00 ` Alexey Dobriyan
2006-10-18 17:42 ` Al Viro
2006-10-18 21:48 ` Alexey Dobriyan
2006-10-18 15:04 ` Linus Torvalds
2006-10-18 15:13 ` Matthew Wilcox
2006-10-18 16:06 ` Al Viro
2006-10-18 16:32 ` Linus Torvalds
2006-10-18 17:44 ` Al Viro
2006-10-19 16:23 ` Al Viro [this message]
2006-10-19 18:24 ` Andreas Gruenbacher
2006-10-20 0:53 ` Al Viro
2006-10-20 0:57 ` Al Viro
2006-10-20 12:43 ` Matthew Wilcox
2006-10-20 0:58 ` Al Viro
2006-10-20 0:59 ` Al Viro
2006-10-20 1:02 ` Al Viro
2006-10-20 4:35 ` Randy Dunlap
2006-10-20 9:26 ` Stefan Richter
2006-10-20 16:13 ` Randy Dunlap
2006-10-20 17:51 ` Stefan Richter
2006-10-22 17:58 ` Geert Uytterhoeven
2006-10-22 22:59 ` Andi Kleen
2006-10-23 8:29 ` Geert Uytterhoeven
2006-10-23 16:09 ` Linus Torvalds
2006-10-23 16:13 ` Geert Uytterhoeven
2006-10-23 16:31 ` Linus Torvalds
2006-10-23 16:52 ` Geert Uytterhoeven
2006-10-23 17:05 ` Linus Torvalds
2006-10-23 0:31 ` Matthew Wilcox
2006-10-23 0:42 ` Andi Kleen
2006-10-23 1:08 ` Matthew Wilcox
2006-10-23 1:31 ` Andi Kleen
2006-10-23 1:36 ` Matthew Wilcox
2006-10-23 1:41 ` Andi Kleen
2006-10-23 8:34 ` Geert Uytterhoeven
2006-10-23 1:48 ` Randy Dunlap
2006-10-23 1:49 ` Nick Piggin
2006-10-23 6:34 ` Stefan Richter
2006-10-18 16:15 ` Jan Engelhardt
2006-10-18 16:21 ` Matthew Wilcox
2006-10-18 5:42 ` [RFC] typechecking for get_unaligned/put_unaligned Dave Jones
2006-10-18 6:05 ` Al Viro
2006-10-19 16:52 ` Denis Vlasenko
2006-10-19 16:58 ` Al Viro
2006-10-17 9:04 ` David Howells
2006-10-17 15:28 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2006-10-28 15:24 dealing with excessive includes Tim Schmielau
2006-10-30 10:45 Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061019162308.GT29920@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=adobriyan@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.