linux-kernel - Re: [PATCH 1/7] Documentation: gpio: add chardev userspace API documentation

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]

Date: Wed, 10 Jan 2024 14:20:18 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Phil Howard <phil@...getoid.com>
Cc: Kent Gibson <warthog618@...il.com>, linux-kernel@...r.kernel.org, 
	linux-gpio@...r.kernel.org, linux-doc@...r.kernel.org, brgl@...ev.pl, 
	linus.walleij@...aro.org, andy@...nel.org, corbet@....net
Subject: Re: [PATCH 1/7] Documentation: gpio: add chardev userspace API documentation

On Wed, Jan 10, 2024 at 1:40 PM Phil Howard <phil@...getoid.com> wrote:
> On Tue, 9 Jan 2024 at 14:00, Kent Gibson <warthog618@...il.com> wrote:

..

> > +   Read Documentation/driver-api/gpio/drivers-on-gpio.rst to avoid reinventing
> > +   kernel wheels in userspace.
>
> I realise this is in part an emotional response, but very much
> "citation needed" on
> this one. While I believe Kernel drivers for things are a good idea, I
> don't believe
> userspace libraries are necessarily bad or wrong. They might be the first
> experience a future kernel dev has with hardware. Either way there are multiple
> ecosystems of userspace drivers both existing and thriving right now, and there
> are good reasons to reinvent kernel wheels in userspace.
>
> At least some of these reasons relate to the (incorrectly assumed)
> insurmountable
> nature of kernel development vs just throwing together some Python. Including
> this loaded language just serves to reinforce that.
>
> You catch more flies with honey than with vinegar, so I'd probably soften to:
>
> Before abusing userspace APIs to bitbash drivers for your hardware you should
> read Documentation/driver-api/gpio/drivers-on-gpio.rst to see if your device has
> an existing kernel driver. If not, please consider contributing one.

I believe this note was motivated by the quite popular pyGPIO for RPi
and MRAA for some platforms, which are the examples of how _not_ do
things.

..

> > +Each chip supports a number of GPIO lines,
> > +:c:type:`chip.lines<gpiochip_info>`. Lines on the chip are identified by an
> > +``offset`` in the range from 0 to ``chip.lines - 1``, i.e. `[0,chip.lines)`.
>
> I don't recognise this syntax "`[0,chip.lines)`", typo, or me being clueless?

It's called "open interval", a mathematical term.

..

> > +    -  -  ``EFAULT``

Wondering if these constants can be referenced via % and if it makes sense.

..

> > +The size of the kernel event buffer is fixed at the time of line request
> > +creation, and can be influenced by the
> > +:c:type:`request.event_buffer_size<gpio_v2_line_request>`.
> > +The default size is 16 times the number of lines requested.
>
> This might explain why I could never quite get high-speed pulse counting to feel
> right. Thank you!

GPIO is just not a good tool for this kind of measurement.

-- 
With Best Regards,
Andy Shevchenko