From: Ian Campbell <ian.campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table
Date: Tue, 3 Nov 2015 15:42:28 +0000 [thread overview]
Message-ID: <1446565348.16178.24.camel@citrix.com> (raw)
In-Reply-To: <5638E14A02000078000B1593@prv-mh.provo.novell.com>
On Tue, 2015-11-03 at 08:31 -0700, Jan Beulich wrote:
> > > > On 03.11.15 at 14:39, <ian.campbell@citrix.com> wrote:
> > On Tue, 2015-11-03 at 05:50 -0700, Jan Beulich wrote:
> > > That's certainly an option on x86 too, the more that the x86_64/
> > > subtree is a remnant of x86_32 days only anyway. Just that doing
> > > this will mean quite a bit more work (not the least because, to be
> > > done properly, I think it implies merging files from x86_64/ into
> > > their
> > > [formerly] shared files where sensible).
> >
> > FWIW IMHO compiling arch/x86/x86_64/*.c from arch/x86/Makefile now and
> > then
> > tackling the merging as and when it makes sense would be fine.
>
> Great. It's on my list to do this merge (in steps) anyway. So does
> this mean I can go ahead and commit both this and patch 1, i.e.
> at least kind-of-an-ack?
Acked-by: Ian Campbell <ian.campbell@citrix.com>
with the provisos regarding common code and not setting a precedent for ARM
I mentioned before (which doesn't need reflecting in the ack in the commit
message, I'll just remember it)
Ian.
next prev parent reply other threads:[~2015-11-03 15:42 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-26 10:47 [PATCH v2 0/5] disambiguate symbol names (part 2) Jan Beulich
2015-10-26 11:49 ` [PATCH v2 1/5] symbols: prefix static symbols with their source file names Jan Beulich
2015-10-28 12:55 ` Andrew Cooper
2015-10-28 13:25 ` Jan Beulich
2015-10-28 13:42 ` Andrew Cooper
2015-10-28 14:29 ` Jan Beulich
2015-11-02 13:47 ` Ian Campbell
2015-11-02 13:55 ` Jan Beulich
2015-11-02 14:54 ` Ian Campbell
2015-11-02 14:58 ` Jan Beulich
2015-11-02 15:11 ` Ian Campbell
2015-10-26 11:50 ` [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table Jan Beulich
2015-10-28 13:08 ` Andrew Cooper
2015-11-02 15:20 ` Ian Campbell
2015-11-02 16:11 ` Jan Beulich
2015-11-03 12:22 ` Ian Campbell
2015-11-03 12:50 ` Jan Beulich
2015-11-03 13:39 ` Ian Campbell
2015-11-03 15:31 ` Jan Beulich
2015-11-03 15:42 ` Ian Campbell [this message]
2015-10-26 11:51 ` [PATCH v2 3/5] x86/mm: override stored file names for multiply built sources Jan Beulich
2015-10-26 12:52 ` Andrew Cooper
2015-10-26 14:34 ` Martin Pohlack
2015-10-26 14:57 ` George Dunlap
2015-10-26 15:12 ` Jan Beulich
2015-10-26 16:27 ` George Dunlap
2015-10-26 11:52 ` [PATCH v2 4/5] x86/mm: build map_domain_gfn() just once Jan Beulich
2015-10-26 12:52 ` Andrew Cooper
2015-10-26 14:58 ` George Dunlap
2015-10-26 11:53 ` [PATCH v2 5/5] x86/mm: only a single instance of gw_page_flags[] is needed Jan Beulich
2015-10-26 14:59 ` George Dunlap
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=1446565348.16178.24.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.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.