[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53018ABA.20005@zytor.com>
Date: Sun, 16 Feb 2014 20:06:18 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: mingo@...nel.org, linux-kernel@...r.kernel.org,
stefani@...bold.net, tglx@...utronix.de, hpa@...ux.intel.com,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/vdso] x86, vdso: Instead of dummy functions, include
< linux/spinlock_up.h>
On 02/16/2014 07:51 PM, tip-bot for H. Peter Anvin wrote:
> Commit-ID: bd9ee7fd99f127ee1306289415141d45792c97f3
> Gitweb: http://git.kernel.org/tip/bd9ee7fd99f127ee1306289415141d45792c97f3
> Author: H. Peter Anvin <hpa@...ux.intel.com>
> AuthorDate: Sun, 16 Feb 2014 19:47:01 -0800
> Committer: H. Peter Anvin <hpa@...ux.intel.com>
> CommitDate: Sun, 16 Feb 2014 19:47:01 -0800
>
> x86, vdso: Instead of dummy functions, include <linux/spinlock_up.h>
>
> The list of dummy functions is insufficient. However, instead of
> having a full list of dummy functions we can include
> <linux/spinlock_up.h> which contains the (trivial) implementations
> that we use on uniprocessor.
>
> There aren't supposed to be any spinlocks at all in the VDSO, of
> course.
>
That didn't work either. I thought I was clever, but it didn't work at
all. Multiple build failures across numerous configurations. This is
turning into a total headache.
The "right" way to fix this is presumably to refactor a bunch of header
files so that the vdso code doesn't have to include a bunch of kernel
internal headers, but that is a lot of work.
-hpa
--
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