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

Message-ID: <rhdrieapetwdr3z7roguf5nex3esazhygjbjx4zklkrjzqrlsv@6vc5zmk3il5e>
Date: Fri, 31 Jan 2025 23:36:27 +0900
From: Koichiro Den <koichiro.den@...onical.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
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 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.

> > 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).

Let me know your thoughts.

Thanks.

-Koichiro

> 
> Bart