All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Juergen Gross" <jgross@suse.com>,
	StefanoStabellini <sstabellini@kernel.org>,
	"Wei Liu" <wl@xen.org>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE
Date: Mon, 9 Dec 2019 12:38:43 +0000	[thread overview]
Message-ID: <42d4c701-dd1e-2d0a-5cc3-56506bb19893@xen.org> (raw)
In-Reply-To: <2b241b5b-7ca3-e2ae-3642-0d921797a6cd@suse.com>

Hi Jan,

On 09/12/2019 12:11, Jan Beulich wrote:
> On 06.12.2019 22:02, Andrew Cooper wrote:
>> On 12/11/2019 14:03, Jan Beulich wrote:
>>> Bottom line - I'm half convinced and willing to give my ack, but
>>> I'm not convinced you truly thought through the longer term
>>> consequences. I'd therefore be far happier to see this patch
>>> split into a non-controversial part (anything that's not tied to
>>> the ACPI and EFI header imports), an ACPI, and an EFI part.
>>
>> I do not want to writing the same patch again in $N years time because
>> review and CI missed it creeping back in.
>>
>> I don't think this is an unreasonable position to take.
> 
> It for sure isn't. Yet I also don't think though my request how to
> split things is. By asking for the split I'm implying that we may
> still reach agreement on the controversial parts, faod. Sadly once
> again there are no other opinions helping to sort which route may
> be the overall preferred one.

Well, for a first, I don't think I have seen any explicit request for 
opinion so far and not all the relevant maintainers have been CCed here.

In general, I tend to stay clear from argument between you and Andrew to 
avoid been dragged into bikeshedding.

Anyway, while I understand that we want to keep as close as upstream, 
those headers are not resync very often and the changes are minimal. The 
long term consequence is not about resync but keeping bogus code that 
can be used by everyone.

So the patch itself is a good step forward to make Xen better.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-12-09 12:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-11 20:24 [Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE Andrew Cooper
2019-11-11 20:40 ` Stefano Stabellini
2019-11-12  8:35 ` Jan Beulich
2019-11-12 13:39   ` Andrew Cooper
2019-11-12 14:03     ` Jan Beulich
2019-12-06 21:02       ` Andrew Cooper
2019-12-09 12:11         ` Jan Beulich
2019-12-09 12:38           ` Julien Grall [this message]
2020-01-06 19:01           ` Andrew Cooper
2020-01-07  8:35             ` Jan Beulich
2019-11-12 10:42 ` Wei Liu

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=42d4c701-dd1e-2d0a-5cc3-56506bb19893@xen.org \
    --to=julien@xen.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@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.