linux-kernel - Re: [PATCH v6 1/4] lib: new helper kstrtodev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VcStj5sE3f0uK2deOWC=ojfx-z1fbrh6Lu6jAor9F9PgA@mail.gmail.com>
Date:   Wed, 19 Feb 2020 21:50:54 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Uwe Kleine-König <uwe@...ine-koenig.org>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Dan Murphy <dmurphy@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sascha Hauer <kernel@...gutronix.de>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>
Subject: Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()

On Thu, Feb 13, 2020 at 11:27 AM Uwe Kleine-König <uwe@...ine-koenig.org> wrote:
>
> This function is in the same spirit as the other kstrto* functions and
> uses the same calling convention. It expects the input string to be in
> the format %u:%u and implements stricter parsing than sscanf as it
> returns an error on trailing data (other than the usual \n).

Can we first split the kstrotox* (and simple_strto*) to the separate
header first?

On top of that, why kstrtodev_t is so important? How many users are
already in the kernel to get an advantage out of it?
What to do with all other possible variants ("%d:%d", "%dx%d" and its
%u variant, etc)?

Why simple_strto*() can't be used?

>  #include <linux/export.h>
>  #include <linux/types.h>
>  #include <linux/uaccess.h>

> +#include <linux/kdev_t.h>

Perhaps preserve order? (It's for the future, since I doubt we will
get this in upstream anyway).

-- 
With Best Regards,
Andy Shevchenko