linux-kernel - Re: [RFC PATCH 0/2] Introduce configfs-based interface for gpio-aggregator

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] [day] [month] [year] [list]

Message-ID: <CAMRc=MeRBABW6JCScGvsRR_4+W6u5QMWJwA7yMB9gj7=uOeD0g@mail.gmail.com>
Date: Fri, 31 Jan 2025 18:22:50 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Koichiro Den <koichiro.den@...onical.com>
Cc: linux-gpio@...r.kernel.org, geert+renesas@...der.be, 
	linus.walleij@...aro.org, maciej.borzecki@...onical.com, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Introduce configfs-based interface for gpio-aggregator

On Fri, Jan 31, 2025 at 3:36 PM Koichiro Den <koichiro.den@...onical.com> wrote:
>
> On Thu, Jan 30, 2025 at 09:47:47PM GMT, Bartosz Golaszewski wrote:
> > On Thu, Jan 30, 2025 at 7:40 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > >
>
> (Small reply to the previous comment:)
> Yes, I understand your point about why you think 'num_lines' is
> unnecessary. What I meant was more of a UX (User eXperience) consideration.
>

If anything this sounds like worse user experience - having to provide
duplicate information.

> > > While at it: there's no reason to impose a
> > > naming convention of lineX, lineY etc., the names don't matter for the
> > > aggregator setup (unlike gpio-sim where they indicate the offset of
> > > the line they concern).
> > >
> >
> > Scratch that part. There's a good reason for that - the ordering of
> > lines within the aggregator. [...]
>
> You're right, that's exactly the intention of the strict naming, 'line0',
> 'line1', ..., 'line<Y>'.
>
> > [...] I'm just not sure whether we should
> > impose a strict naming where - for an aggregator of 3 lines total - we
> > expect there to exist groups named line0, line1 and line2 or if we
> > should be more lenient and possibly sort whatever names the user
> > provides alphabetically?
>
> As Maciej pointed out:
>
>   (https://lore.kernel.org/all/CAFGk_a0U=jSQD85UKC1e=pSWr8W9y_MMAFyPVFOcE-fUZry7-Q@mail.gmail.com/#t)
>   > [...] if free form names were for e.g. [1, 02, 10].
>
> we would need a well-defined rule to avoid ambiguity, which could
> potentially unnecessarily impose burden on users to understand how to
> properly use the interface.
>
>
> Regardless, the point is that we need to make it clear to users which GPIO
> line a specific line<Y> of an aggregator forwards operations to. Since
> requiring users to explicitly set the offset within the aggregator for each
> virtual line (e.g. besides 'key'/'offset'/'name' attributes, by adding
> 'idx' attribute, which users would need to set explicitly) would be
> cumbersome, this RFC implementation instead just makes use of directory
> naming. I believe we agree on this approach (i.e., using directory naming
> to establish ordering). Correct me if I'm wrong.
>
> So, to move forward, let me outline the possible approaches we can take:
>
> Option (a). Drop 'num_lines' attribute and:
>
>   (a-1). Impose strict naming rule for line directories
>
>          Users can only create directories with a predefined naming
>          convention. This could be 'line0', 'line1', ... 'line<Y>' (as in
>          the RFC implementation), or simply '0', '1', ..., '<Y>'.
>
>   (a-2). Allow arbitrary naming for line directories
>
>          This would require a well-defined rule to avoid ambiguity. As
>          Maciej pointed out:
>
>          (from https://lore.kernel.org/all/CAFGk_a0U=jSQD85UKC1e=pSWr8W9y_MMAFyPVFOcE-fUZry7-Q@mail.gmail.com/#t)
>          > if free form names were for e.g. [1, 02, 10]
>
>          Users would need to understand these rules, which might impose
>          unnecessary burden on users.
>
> Option (b). Keep 'num_lines' attribute but:
>
>     (b-1). Prohibit manual creation of line directories
>
>            Users would no longer run 'mkdir line0', etc. Instead, writing
>            <Y+1> (Y >= 0) to 'num_lines' would automatically set up the
>            required directories.  convention. This could be 'line0',
>            'line1', ... 'line<Y>' (as in this RFC implementation), or
>            simply '0', '1', ..., '<Y>'.
>
>     (b-2). Keep manual 'mkdir' for each line, in the same manner as (a-1)
>            (as in the RFC implementation) or (a-2). Seems that no-one is
>            favor of this option.
>
>
>     Note: (b-1) is a new idea. Considering what really needs to be
>     configured by users, this could be the least burdensome and simplest,
>     especially when configuring many lines. I'm including it here for
>     broader discussion.
>
> Personally, now I'm inclined towards (a-1) with the simplest naming scheme:
> non-zero-padded integers ('./0', './1', './2', ..., './<Y>'). Or even (b-1).
>

I too think a-1 is the best option. However, I'd go for line0, line1
etc. convention as for computers it doesn't make any difference while
for humans it's more readable.

Bartosz

> Let me know your thoughts.
>
> Thanks.
>
> -Koichiro
>
> >
> > Bart