[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100810151306.GC6981@wil.cx>
Date: Tue, 10 Aug 2010 11:13:06 -0400
From: Matthew Wilcox <willy@...ux.intel.com>
To: David Miller <davem@...emloft.net>
Cc: cmetcalf@...era.com, willy@...ux.intel.com,
linux-kernel@...r.kernel.org
Subject: Re: perf build broke by list_head changes...
On Mon, Aug 09, 2010 at 11:57:46PM -0700, David Miller wrote:
> Commit:
>
> commit de5d9bf6541736dc7ad264d2b5cc99bc1b2ad958
> Author: Chris Metcalf <cmetcalf@...era.com>
> Date: Fri Jul 2 13:41:14 2010 -0400
>
> Move list types from <linux/list.h> to <linux/types.h>.
>
> broke the build of 'perf'.
>
> If you move "struct list_head" into types.h, this means perf stops
> building because it depends upon being able to include linux/list.h
> from a userland application and at the same time be able to get the
> basic data types without defining __KERNEL__ or similar.
Sorry about that. Obviously, I didn't test-build this patch.
> Now that no longer occurs because the bulk of types.h is __KERNEL__
> protected and thus the build breaks since "struct list_head" is
> never defined.
list.h isn't a header-y file, so it's not an interface we expect userspace
to use. So one reasonable way to fix this is for perf to take its own copy.
Reverting the patch gets us back to the former problem (of not being
able to use list.h in certain cases).
We could do a glibc-like _WANT_LIST_HEAD macro. I don't think the
resulting uglification is reasonable.
perf could pretend that it's real userspace instead of being part of
the kernel and use a list implementation designed for userspace. I
don't know of a good one though.
Any preferences which solution we take?
--
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