linux-kernel - Re: [PATCH 3/3] Documentation: ABI: sysfs-driver-regulator-output

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]

Date:   Sun, 10 Sep 2023 13:50:37 -0700
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Mark Brown <broonie@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Naresh Solanki <naresh.solanki@...ements.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] Documentation: ABI: sysfs-driver-regulator-output

On Mon, Sep 04, 2023 at 05:24:31AM PDT, Mark Brown wrote:
>On Sun, Sep 03, 2023 at 05:48:14PM -0700, Zev Weiss wrote:
>> On Sun, Sep 03, 2023 at 06:04:23AM PDT, Greg Kroah-Hartman wrote:
>
>> > But yes, reading a sysfs should almost never cause a side affect at all.
>
>> > But what do you mean by "clear events?"
>
>> I mean that when the sysfs file is read, the state variable whose value it
>> exposes is also cleared as a side-effect (so the read operation "consumes"
>> the value it returns) -- see the implementation in patch 2 of this series
>> (specifically the 'data->events = 0' assignment in events_show()):
>
>It's a clear on read interrupt.

Sure, analogous behavior in hardware is reasonably common, but that 
doesn't strike me as a very compelling reason to design the 
kernel<->userspace interface to mimic it -- providing nicer interfaces 
than the raw hardware is one of the main reasons for having an OS in the 
first place, after all.


Zev