All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: Sam Ravnborg <sam@ravnborg.org>
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 22:35:08 +0100	[thread overview]
Message-ID: <20060924213508.GR29920@ftp.linux.org.uk> (raw)
In-Reply-To: <20060924205244.GA26774@uranus.ravnborg.org>

On Sun, Sep 24, 2006 at 10:52:44PM +0200, Sam Ravnborg wrote:
> The only thing I like to see is minimal suprise. And minimal suprise in
> this case is to be considered as "works on almost all archs if not all".
> In practical terms it could be that users of asm/* had to include
> baz.h before bar.h.

Even though dependency on baz.h is due to implementation of one of the
helpers in bar.h on a few targets and makes no sense whatsoever for
everything else?

> 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.

> 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?

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.  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.

So all you get is a bunch of harder to explain includes between linux/*.h,
_and_ extra dependencies that make no sense whatsoever.

  reply	other threads:[~2006-09-24 21:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-23 15:44 [PATCH] missing includes from infiniband merge 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 [this message]
2006-09-24 21:56             ` Sam Ravnborg

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=20060924213508.GR29920@ftp.linux.org.uk \
    --to=viro@ftp.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rolandd@cisco.com \
    --cc=sam@ravnborg.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.