xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Ian Jackson <iwj@xenproject.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	M A Young <m.a.young@durham.ac.uk>
Subject: Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels
Date: Tue, 26 Jan 2021 08:47:07 +0100	[thread overview]
Message-ID: <9f2e20ae-ab61-329e-9894-7c6b964edfbf@suse.com> (raw)
In-Reply-To: <24591.49.238509.216726@mariner.uk.xensource.com>

On 25.01.2021 18:30, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels"):
>> On 25.01.2021 17:17, Ian Jackson wrote:
>>> I think we had concluded not to print a warning ?
>>
>> Yes. Even in the projected new form of using the construct I
>> don't intend to change the description's wording, as the
>> intended use of [true] still looks like that can't be intended
>> usage. IOW my remark extended beyond the warning; I'm sorry if
>> this did end up confusing because you were referring to just
>> the warning.
> 
> I'm afraid I don't understand what you mean.  In particular, what you
> mean by "the intended use of [true] still looks like that can't be
> intended usage".
> 
>   the intended {by whom for what puropose?} use of [true] still looks
>   like that {what?} can't be intended {by whom?} usage
> 
> I have the feeling that I have totally failed to grasp your mental
> model, which naturally underlies your comments.
> 
> Do you mean that with "true" for the 4th argument, the printed output
> is not correct, in the failure case ?  Maybe it needs a call to AC_MSG
> or something (but AIUI most of these PKG_* macros ought to do that for
> us).  I'm just guessing at your meaing here...

Well, I'm afraid I'm ending up confusing you because I'm confused
about the possible intentions here. My initial attempt to avoid
configure failing was to specify [] as the 4th argument. This, to
me, would have felt the half-way natural indication that I don't
mean anything to be done in the failure case, neither autoconf's
default nor anything else. [true], otoh, already feels like a
workaround for some shortcoming.

Anyway - I guess we should continue from v3, which I hope to post
later this morning.

Jan


  reply	other threads:[~2021-01-26  7:47 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19 15:13 [PATCH v2 0/5] zstd decompression for DomU-s + fallout / consolidation Jan Beulich
2021-01-19 15:15 ` [PATCH v2 1/5] libxenguest: support zstd compressed kernels Jan Beulich
2021-01-21 15:01   ` Wei Liu
2021-01-21 15:05     ` Jan Beulich
2021-01-21 15:33       ` Wei Liu
2021-01-19 15:15 ` [PATCH v2 2/5] xen/decompress: make helper symbols static Jan Beulich
2021-01-21 15:01   ` Wei Liu
2021-01-19 15:16 ` [PATCH v2 3/5] libxenguest: "standardize" LZO kernel decompression code Jan Beulich
2021-01-21 15:02   ` Wei Liu
2021-01-25 11:59     ` Ian Jackson
2021-01-25 12:45       ` Jan Beulich
2021-01-25 13:30         ` Ian Jackson
2021-01-19 15:16 ` [PATCH v2 4/5] libxenguest: drop redundant decompression declarations Jan Beulich
2021-01-21 15:02   ` Wei Liu
2021-01-19 15:17 ` [PATCH v2 5/5] libxenguest: simplify kernel decompression Jan Beulich
2021-01-21 15:38   ` Wei Liu
2021-01-21 15:40 ` [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels Jan Beulich
2021-01-25 11:30   ` Ian Jackson
2021-01-25 12:42     ` Jan Beulich
2021-01-25 13:51       ` Ian Jackson
2021-01-25 14:30         ` Jan Beulich
2021-01-25 14:53           ` Ian Jackson
2021-01-25 15:31             ` Jan Beulich
2021-01-25 16:17               ` Ian Jackson
2021-01-25 17:00                 ` Jan Beulich
2021-01-25 17:30                   ` Ian Jackson
2021-01-26  7:47                     ` Jan Beulich [this message]
2021-01-26 12:14                       ` Ian Jackson

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=9f2e20ae-ab61-329e-9894-7c6b964edfbf@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=julien@xen.org \
    --cc=m.a.young@durham.ac.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).