All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wangnan (F)" <wangnan0@huawei.com>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	<linux-kernel@vger.kernel.org>, <lizefan@huawei.com>,
	<pi3orama@163.com>
Subject: Re: [PATCH 1/3] tools include: Add uapi mman.h for each architecture
Date: Wed, 14 Sep 2016 18:23:32 +0800	[thread overview]
Message-ID: <57D92524.6050704@huawei.com> (raw)
In-Reply-To: <20160914100018.GB21691@naverao1-tp.localdomain>



On 2016/9/14 18:00, Naveen N. Rao wrote:
> On 2016/09/14 05:36PM, Wang Nan wrote:
>>
>> On 2016/9/14 17:28, Naveen N. Rao wrote:
>>> On 2016/09/12 06:15PM, Arnaldo Carvalho de Melo wrote:
>>>> Em Mon, Sep 12, 2016 at 04:07:42PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>>> Em Mon, Sep 12, 2016 at 12:54:29PM +0000, Wang Nan escreveu:
>>>>>> Some mmap related macros have different values for different
>>>>>> architectures. This patch introduces uapi mman.h for each
>>>>>> architectures.
>>>>>>
>>>>>> Three headers are cloned from kernel include to tools/include:
>>>>>>
>>>>>>    tools/include/uapi/asm-generic/mman-common.h
>>>>>>    tools/include/uapi/asm-generic/mman.h
>>>>>>    tools/include/uapi/linux/mman.h
>>>>> Cool, the above was done as copies, why not the rest? IIRC you mentioned
>>>>> some reasoning behind that decision, but we need it spelled out here.
>>>>>
>>>>> For instance, I went on and look at arch/xtensa/include/uapi/asm/mman.h,
>>>>> and couldn't find why we shouldn't copy it just like the three files
>>>>> above.
>>>>>
>>>>> I'm looking now at why the build breaks in so many systems, first hunch
>>>>> is that bits/ part (the ones without the failure details probably have
>>>>> the same errors), alpine uses musl libc, but some that broke are glibc
>>>>> based.
>>>> So, please take a look at my perf/core branch, I applied 1/3 and 3/3,
>>>> but took a different path for 2/3, now it builds for all systems I have
>>>> containers for:
>>> This still fails for me on ppc64. Perhaps we should guard
>>> P_MMAP_FLAG(32BIT) and potentially others with a #ifdef, which was
>>> earlier reverted by commit 256763b0 ("perf trace beauty mmap: Add more
>>> conditional defines")?
>> Perhaps we should set all non-exist flag to 0 in each uapi mman.h?
> Will that work for MADV_* since the macro there is for a case statement?

Then fall back to include/uapi/asm-generic/mman-common.h. And I
realized the missing of MADV_FEEE in tools/perf/trace/beauty/mmap.c.
Is that intentionally?

Thank you.

  reply	other threads:[~2016-09-14 10:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-12 12:54 [PATCH 0/3] perf: Fix mmap related macros Wang Nan
2016-09-12 12:54 ` [PATCH 1/3] tools include: Add uapi mman.h for each architecture Wang Nan
2016-09-12 19:07   ` Arnaldo Carvalho de Melo
2016-09-12 21:15     ` Arnaldo Carvalho de Melo
2016-09-13  6:36       ` Wangnan (F)
2016-09-14  9:28       ` Naveen N. Rao
2016-09-14  9:36         ` Wangnan (F)
2016-09-14 10:00           ` Naveen N. Rao
2016-09-14 10:23             ` Wangnan (F) [this message]
2016-09-14 10:46               ` Naveen N. Rao
2016-09-14 10:49                 ` Wangnan (F)
2016-09-14 13:52         ` Arnaldo Carvalho de Melo
2016-09-14 16:34           ` Naveen N. Rao
2016-09-14 17:00             ` Arnaldo Carvalho de Melo
2016-09-15 14:47               ` Naveen N. Rao
2016-09-20 21:37   ` [tip:perf/core] " tip-bot for Wang Nan
2016-09-12 12:54 ` [PATCH 2/3] tools include: Introduce bits/mman.h Wang Nan
2016-09-12 12:54 ` [PATCH 3/3] perf build: Compare mman.h related headers againest kernel Wang Nan
2016-09-20 21:39   ` [tip:perf/core] perf build: Compare mman.h related headers against kernel originals tip-bot for Wang Nan

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=57D92524.6050704@huawei.com \
    --to=wangnan0@huawei.com \
    --cc=acme@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=pi3orama@163.com \
    /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.