Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1111009ybf;
        Thu, 27 Feb 2020 05:14:50 -0800 (PST)
X-Google-Smtp-Source: APXvYqzS+qMbSGg5DMWmhKaWPxu8sXneAAkaM1r2DniHwesGCutSR3afMBiT3AQ9nizLQoeuzWKr
X-Received: by 2002:aca:d0a:: with SMTP id 10mr3125571oin.50.1582809290238;
        Thu, 27 Feb 2020 05:14:50 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1582809290; cv=none;
        d=google.com; s=arc-20160816;
        b=yyn2a46w0HwjQ6Gi03bf+307OnQNFDyvG4t3R7Qt0IMNaYci2JBDo+sP7QLz+jkJIc
         R8XaJYI5ObyL+JCm0fEa/WGUzlP3Y2bzJHQ3Lfz+Vna98orXihi4AvgMSGHeCPm+8C+5
         Zu36JgXomawgpdmogbpYLRoo3O/Wq9h4JHwEO1DbPXT7cPw7tjAIBn4tJp8+DfqoMA4I
         j4+kT726ueDmJ5JHJlWP6FsEJ0qR4gnFZU5+aBjhF3C5UqCiYoyHgp+7R9zFdTttM6sC
         1X7OmfuvToM9KH2cBNExhf/P58mZyGgyAUmPDN9dL5xpA5dpaQlHhk8Q54fefE9jDhXm
         rKvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:precedence:sender:user-agent:in-reply-to
         :content-transfer-encoding:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date;
        bh=PdBYwQ9L9er5VbJM6dDN8Y5qJDXAtUN42grzVVCRkJ8=;
        b=vckK09ARaz+wKL0oLztaw8WYNI2gDmAzGbGWdYeJcltsb0FppNC8iI9EwK76gQzKcJ
         Bdq0kV9b0EOOmJlt08EMoybz3Kr7ZMmJccrmmiEBua2FekiyHnziMCuqXUh1hqNUkWEv
         hq5XxyQn64b8i1pNYkypG7o6J2PjNEsSga+9zUtLAMwEobRMLvp1xUJKkyIgpwI8sC+Y
         EY2U6OiNeYC7KBuGjtN4tYdEQNt4NAZc9Xg6/V7Fkj4gZQrPCy36NndiSj2Zw6EpywOA
         M1Veer6qX6nQM9vv+fWAzZa21USnwzQNDm9byF/NsAvgXiLOFVYHWq4MqrvRPU3pW+E7
         3IUg==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
        by mx.google.com with ESMTP id v14si1461101oto.127.2020.02.27.05.14.36;
        Thu, 27 Feb 2020 05:14:50 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Authentication-Results: mx.google.com;
       spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1729125AbgB0NOb (ORCPT <rfc822;wxiaokuan@gmail.com> + 99 others);
        Thu, 27 Feb 2020 08:14:31 -0500
Received: from mx2.suse.de ([195.135.220.15]:44912 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1729094AbgB0NOb (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 27 Feb 2020 08:14:31 -0500
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
        by mx2.suse.de (Postfix) with ESMTP id 765DCB18F;
        Thu, 27 Feb 2020 13:14:29 +0000 (UTC)
Date:   Thu, 27 Feb 2020 14:14:28 +0100
From:   Petr Mladek <pmladek@suse.com>
To:     Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc:     Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= 
        <u.kleine-koenig@pengutronix.de>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH v1] lib/vsprintf: update comment about
 simple_strto<foo>() functions
Message-ID: <20200227131428.5nhvslwdmocv6fkb@pathway.suse.cz>
References: <20200221085723.42469-1-andriy.shevchenko@linux.intel.com>
 <20200221145141.pchim24oht7nxfir@pengutronix.de>
 <CAHp75VfR+X6Mw8ywKNW5mTomzmuHSM8ecQUhxtM=LUkWaSe9CA@mail.gmail.com>
 <20200221163334.w7pocmbbw4ymimlc@pengutronix.de>
 <d6c3b369-9777-9986-f41f-3f3a4f85d64c@rasmusvillemoes.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <d6c3b369-9777-9986-f41f-3f3a4f85d64c@rasmusvillemoes.dk>
User-Agent: NeoMutt/20170912 (1.9.0)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat 2020-02-22 01:28:25, Rasmus Villemoes wrote:
> On 21/02/2020 17.33, Uwe Kleine-K?nig wrote:
> > On Fri, Feb 21, 2020 at 05:27:49PM +0200, Andy Shevchenko wrote:
> >> On Fri, Feb 21, 2020 at 4:54 PM Uwe Kleine-K?nig
> >> <u.kleine-koenig@pengutronix.de> wrote:
> >>> On Fri, Feb 21, 2020 at 10:57:23AM +0200, Andy Shevchenko wrote:
> >>>> The commit 885e68e8b7b1 ("kernel.h: update comment about simple_strto<foo>()
> >>>> functions") updated a comment regard to simple_strto<foo>() functions, but
> >>>> missed similar change in the vsprintf.c module.
> >>>>
> >>>> Update comments in vsprintf.c as well for simple_strto<foo>() functions.
> >>
> >> ...
> >>
> >>>> - * This function is obsolete. Please use kstrtoull instead.
> >>>> + * This function has caveats. Please use kstrtoull instead.
> >>
> >>> I wonder if we instead want to create a set of functions that is
> >>> versatile enough to cover kstrtoull and simple_strtoull. i.e. fix the
> >>> rounding problems (that are the caveats, right?) and as calling
> >>> convention use an errorvalued int return + an output-parameter of the
> >>> corresponding type.
> >>
> >> It wouldn't be possible to apply same rules to both. They both are
> >> part of existing ABI.
> > 
> > The idea is to creat a sane set of functions, then convert all users to
> > the sane one and only then strip the strange functions away. (Userspace)
> > ABI isn't affected, is it?
> 
> There are lots of in-tree users of all these interfaces, converting them
> all is never going to happen. And yes, there are also kstrtox_user
> variants which are definitely part of ABI (more or less the whole reason
> kstrox accepts a single trailing newline but is otherwise rather strict
> is so it can parse stuff that is echo'd to a sysfs/procfs/... file).

Thanks a lot for the detailed answer. It seems that there is no easy
solution to the problem.

Is still anyone against the original patch updating the comments in
vsprintf.c. Otherwise, I would queue it for 5.7.

Best Regards,
Petr