From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AAE2C433DB for ; Mon, 25 Jan 2021 17:30:42 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C15E422B3F for ; Mon, 25 Jan 2021 17:30:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C15E422B3F Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=xenproject.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.74226.133366 (Exim 4.92) (envelope-from ) id 1l45h8-0007XG-QS; Mon, 25 Jan 2021 17:30:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 74226.133366; Mon, 25 Jan 2021 17:30:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l45h8-0007X9-M3; Mon, 25 Jan 2021 17:30:30 +0000 Received: by outflank-mailman (input) for mailman id 74226; Mon, 25 Jan 2021 17:30:29 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l45h7-0007X4-17 for xen-devel@lists.xenproject.org; Mon, 25 Jan 2021 17:30:29 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l45h6-0001Cn-TR for xen-devel@lists.xenproject.org; Mon, 25 Jan 2021 17:30:28 +0000 Received: from iwj (helo=mariner.uk.xensource.com) by xenbits.xenproject.org with local-bsmtp (Exim 4.92) (envelope-from ) id 1l45h6-000568-SZ for xen-devel@lists.xenproject.org; Mon, 25 Jan 2021 17:30:28 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.89) (envelope-from ) id 1l45h3-0004HN-HR; Mon, 25 Jan 2021 17:30:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=References:In-Reply-To:Subject:Cc:To:Date :Message-ID:Content-Transfer-Encoding:Content-Type:MIME-Version:From; bh=Lc0C8IWNKpMjkpd/4whW0H5yvf6tll/G6UcAdZsWh68=; b=xQcHtZ/3eyji2D9C2VDL9T9czf scs9hw25iMFOJG9IXn+BJyw6+OyTuRGx9h/WeXejwPP9e02sC+Ai4WTIbO+fNJTHA4v002G8Q+lSa qbPyGUQHf7mnV1TZI2nPo5PwxDsN2RWQ/Tue5R6P1qUxYiI0ghGFe0iIBm5g4WjStI2E=; From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24591.49.238509.216726@mariner.uk.xensource.com> Date: Mon, 25 Jan 2021 17:30:25 +0000 To: Jan Beulich Cc: "xen-devel\@lists.xenproject.org" , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , M A Young Subject: Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels In-Reply-To: References: <24590.44019.51460.33930@mariner.uk.xensource.com> <24590.52459.194044.857442@mariner.uk.xensource.com> <6895299a-f2fd-7090-d0fa-dc7b2e54d1ba@suse.com> <24590.56183.458644.60628@mariner.uk.xensource.com> <6e988e9e-f8c2-13cb-79a4-1d8ae4e8a403@suse.com> <24590.61205.393750.544294@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) The quoted-reply part of this message may be going off into the weeds. Feel free to ignore it, or parts of it, if you think you can make progress without disabusing me of what I think are my misunderstandings... Jan Beulich writes ("Re: [PATCH v2.5 1/5] libxenguest: support zstd compressed kernels"): > On 25.01.2021 17:17, Ian Jackson wrote: > > I don't understand why this > > situation should be handled differently for zstd than for any of the > > other calls to *PKG* (glib, pixman, libnl). > > The difference is that glib and pixman aren't optional (if > building qemu), i.e. we want configure to fail if they can't > be found or are too old. Yes, but I think that just means adding the [true] fourth argument, to make failure to find the library a no-op. I don't think it needs any more complex handling. At least, I have not yet understood a need for more complex handling... > > Perhaps you experienced some issue which would have been fixed by the > > addition of the missing PKG_PROG_PKG_CONFIG ? > > I don't think so, no, as I've not tried configuring in a way > where the earlier PKG_CHECK_MODULES() would be bypassed. I guess I should take care of this then, since I think it's probably an accident waiting to happen. > >> I can, but it feels wrong, in particular if I gave it a > >> generic looking name (get_unaligned_le32() or some such, > > > > That would seem perfect to me. I don't know what would be wrong > > with it. > > Using this (most?) natural name has two issues in my view: > For one, it'll likely cause conflicts with how other code > (using hypervisor files) gets built. And then I consider it > odd to have just one out of a larger set of functions, but > I would consider it odd as well if I had to introduce them > all right here. If you put this new definition in xg_private.h for now then it ought not to conflict with anyone else. (Assuming it's a static inline, or a macro. If it will have external linkage then it will need a name prefix which I would prefer to avoid.) I think it best to add this one macro/inline now. When someone wants more of these, they can add them. If someone want them elsewhere they can do the work of finding or making a suitably central place. If it weren't for the release timing I might think it better to add more, but my general rule is that steps towards the best possible situation are better than steps that go away from the best possible situation, even if the former are not complete. I think a reasonable alternative would be to arrange to import a comprehensive set from somewhere. > > 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... > >>>>> I mean the inclusion of $libzstd_PKG_ERRORS in the output. > >>>> > >>>> I see no point in the warning without including this. In fact > >>>> I added the AC_MSG_WARN() just so that the contents of this > >>>> variable (and hence an indication to the user of what to do) > >>>> was easily accessible. > >>> > >>> This is not usual autoconf practice. The usual approach is to > >>> consider that missing features are just to be dealt with with a > >>> minimum of fuss. > >> > >> Which is why I made the description say what it says. Just > >> that - as per above - I don't see viable alternatives (yet). Quoting this because I think it may still be relevant for understanding the foregoing... Ian.