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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZUbsAhXyk-d4R2M9@rigel>
Date:   Sun, 5 Nov 2023 09:12:34 +0800
From:   Kent Gibson <warthog618@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>,
        Andy Shevchenko <andy@...nel.org>, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] RFC: Do not enable the v1 uAPI by default

On Sat, Nov 04, 2023 at 11:54:40PM +0100, Linus Walleij wrote:
> It's been two years since we introduced the v2 uAPI and
> the major consumer libgpiod is at v2.1.
>

Believe it or not, it is nearly three years.  But libgpiod support for
it, added in v2.x, is less than one year old, and migrating from libgpiod
v1 to v2 is non-trivial as their APIs are very different.
So I would not be surprised to find that the major consumer of the uAPI
remains users of libgpiod v1.x - which requires the old uAPI.

> What about discouraging the old uAPI?
>

If you want to provide the end user with two years to migrate, and given
that libgpiod is the major consumer, you might want to hold off for
another year.

OTOH, if distros/users want to continue including/using libgpiod v1 they
can always re-enable GPIO_CDEV_V1, so I'm not completely against the idea
- just be aware that it may be more disruptive than you might expect.

Cheers,
Kent.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ