[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060923203605.GN29920@ftp.linux.org.uk>
Date: Sat, 23 Sep 2006 21:36:05 +0100
From: Al Viro <viro@....linux.org.uk>
To: Sam Ravnborg <sam@...nborg.org>
Cc: Linus Torvalds <torvalds@...l.org>, rolandd@...co.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] missing includes from infiniband merge
On Sat, Sep 23, 2006 at 10:29:12PM +0200, Sam Ravnborg wrote:
> On Sat, Sep 23, 2006 at 04:44:16PM +0100, Al Viro wrote:
> > indirect chains of includes are arch-specific and can't
> > be relied upon... (hell, even attempt to build it for
> > itanic would trigger vmalloc.h ones; err.h triggers
> > on e.g. alpha).
> >
> > Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
> > ---
> > drivers/infiniband/core/mad_priv.h | 1 +
> > drivers/infiniband/hw/amso1100/c2_provider.c | 1 +
> > drivers/infiniband/hw/amso1100/c2_rnic.c | 1 +
> > drivers/infiniband/hw/ipath/ipath_diag.c | 1 +
> > 4 files changed, 4 insertions(+), 0 deletions(-)
> A better fix would be to avoid the arch dependency in the non-arch .h
> files so that in most cases it just works??
What "it"? Use of vmalloc() without including vmalloc.h since on i386
it just happens to be pulled via the
linux/pci.h -> linux/dmapool.h -> asm-i386/io.h -> linux/vmalloc.h
chain?
Should we replicate it on every platform? Along with all kinds of fun that's
going to cause wrt ordering, BTW...
-
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