From: Sam Ravnborg <sam@ravnborg.org>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: Linus Torvalds <torvalds@osdl.org>,
rolandd@cisco.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] missing includes from infiniband merge
Date: Sun, 24 Sep 2006 23:56:25 +0200 [thread overview]
Message-ID: <20060924215625.GA27605@uranus.ravnborg.org> (raw)
In-Reply-To: <20060924213508.GR29920@ftp.linux.org.uk>
> > Or we could stick to current mess where one has
> > to have a shitload of crosscompiles and CPU power to check even trivial
> > changes to a few include files.
>
> We _are_ stuck with it.
For old stuff - to a high degree yes.
> > Partly this could be fixed by making header files in asm-$(ARCH)
> > second class citizen - that always got included via their linux/
> > counterpart.
>
> Which only makes dependency graph fatter... What's the difference
> between including asm/uaccess.h and linux/uaccess.h?
It makes it fatter on the horizontal level - yes.
But then files do not rely on files being included by asm-* files
anymore - so less difference between architecutes.
> Basically, you pull tons of includes into linux/blah.h because it
> happens to include asm/foo.h and _that_ depends on having linux/barf.h
> for $WEIRD_TARGET.
That would be wrong. Any file in asm-* that needs a file from linux/
should pull that include to the linux/ counterpart and in this way
we are on track again.
It boils down to something simple as:
Do we want to keep arch independence lower on the price of higher number
includes in asm- counter part files in linux/?
> And guess what? You are back to the same cross-compiles,
> since attempt to remove blah.h -> barf.h will break $WEIRD_TARGET, but
> you won't notice that unless you cross-compile for it.
No.
There is a huge difference modifying architecture independent code like
infiniband or module.c and to try to clean up headers.
Cleaning up headers really really require that one cross compile
a lot no matter how files are organized.
> So all you get is a bunch of harder to explain includes between linux/*.h,
> _and_ extra dependencies that make no sense whatsoever.
They are easy to explain: They are there to keep arch independence lower -
and the cost is a number (tons?) of extra includes.
OK - this was a fun thread talking about arch specific includes.
But since I do not plan to follow-up with patches I will
drop of for now. bugzilla and others tell me I should concentrate
on other things.
Sam
prev parent reply other threads:[~2006-09-24 21:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-23 15:44 Al Viro
2006-09-23 17:35 ` Roland Dreier
2006-09-23 20:29 ` Sam Ravnborg
2006-09-23 20:36 ` Al Viro
2006-09-23 20:54 ` Al Viro
2006-09-24 6:44 ` Sam Ravnborg
2006-09-24 19:19 ` Al Viro
2006-09-24 20:52 ` Sam Ravnborg
2006-09-24 21:35 ` Al Viro
2006-09-24 21:56 ` Sam Ravnborg [this message]
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=20060924215625.GA27605@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rolandd@cisco.com \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®