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.4 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 AEB63C433E0 for ; Fri, 5 Feb 2021 14:20:47 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 CE2C7650CE for ; Fri, 5 Feb 2021 14:20:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE2C7650CE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l81yX-0005iJ-Ff for qemu-devel@archiver.kernel.org; Fri, 05 Feb 2021 09:20:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36740) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l81x4-0005DN-OA for qemu-devel@nongnu.org; Fri, 05 Feb 2021 09:19:14 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:56669) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1l81x3-0007wU-4r for qemu-devel@nongnu.org; Fri, 05 Feb 2021 09:19:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612534752; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rzkkZ51OzraIPr2AwAPhAZG3mXBU6mJn/R0B2jdOqaU=; b=c9een87r+BnKptznK5TV4A1LriuaB6KWjhDJXuLLpiKQNFSQ0apkoQED2NjHrdYFu9ZlJt UkGZAiiYJ8pOPHjez7iYDeHVww0lDpw2Uh5uE37FIO7N6GnyEHqRMjAkYY7tQSbF5BzUCQ tEvc7wPIM8WMft8vm4txEESVpIH9f2o= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-242-BidmUxPWOYuEJaDdUxLp_Q-1; Fri, 05 Feb 2021 09:19:10 -0500 X-MC-Unique: BidmUxPWOYuEJaDdUxLp_Q-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A7B05192CC41; Fri, 5 Feb 2021 14:19:09 +0000 (UTC) Received: from [10.3.112.253] (ovpn-112-253.phx2.redhat.com [10.3.112.253]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0F37460C76; Fri, 5 Feb 2021 14:19:09 +0000 (UTC) Subject: Re: [PATCH 3/3] utils: Deprecate inexact fractional suffix sizes To: "Richard W.M. Jones" References: <20210204190708.1306296-1-eblake@redhat.com> <20210204190708.1306296-4-eblake@redhat.com> <20210205103446.GC30079@redhat.com> From: Eric Blake Organization: Red Hat, Inc. Message-ID: <68bd33b1-8c79-0307-49c6-d4d38ab4b89c@redhat.com> Date: Fri, 5 Feb 2021 08:19:08 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210205103446.GC30079@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=eblake@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=63.128.21.124; envelope-from=eblake@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.352, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.33, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: vsementsov@virtuozzo.com, berrange@redhat.com, qemu-block@nongnu.org, tao3.xu@intel.com, qemu-devel@nongnu.org, armbru@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 2/5/21 4:34 AM, Richard W.M. Jones wrote: > On Thu, Feb 04, 2021 at 01:07:08PM -0600, Eric Blake wrote: >> The value '1.1k' is inexact; 1126.4 bytes is not possible, so we >> happen to truncate it to 1126. Our use of fractional sizes is >> intended for convenience, but when a user specifies a fraction that is >> not a clean translation to binary, truncating/rounding behind their >> backs can cause confusion. Better is to deprecate inexact values, >> which still leaves '1.5k' as valid, but alerts the user to spell out >> their values as a precise byte number in cases where they are >> currently being rounded. >> >> Note that values like '0.1G' in the testsuite need adjustment as a >> result. >> >> Sadly, since qemu_strtosz() does not have an Err** parameter, we >> pollute to stderr. > > Does "deprecate" mean there's a plan to eventually remove this? If so > I think it should say that (in docs/system/deprecated.rst I think). Yes (well, if we agree to the patch; Dan has already voiced concern that we may not want 3/3 after all). And that's why I posted a followup message mentioning that I failed to commit that docs/ change before sending my v1. It will be in v2. > > I think it would be better to remove this now or in the future since > it's a trap for users. It's borderline - Markus has expressed a desire to remove inexact fractions, while Dan has expressed the desire that user convenience is important (as long as we are clear that non-fractional values are ALWAYS exact, and that the use of a fraction is for convenience at which point you KNOW you are risking rounding, then allowing both 1.1M and 1.5M instead of only one of the two is nicer). I submitted this patch because of IRC discussion, but if it is up to just me, I'd keep 2/3 but drop 3/3 (that is, I'm happy to deprecate 0x4000M, but not happy to deprecate 0.1G, but rather merely posted the patch to see what the fallout is because the question had been asked on IRC). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org