linux-kernel - Re: [RFC 1/4] counter: Simplify the count_read and count

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]

Date:   Sun, 15 Sep 2019 22:58:23 +0900
From:   William Breathitt Gray <vilhelm.gray@...il.com>
To:     Jonathan Cameron <jic23@...23.retrosnub.co.uk>
Cc:     linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Subject: Re: [RFC 1/4] counter: Simplify the count_read and count_write
 callbacks

On Sun, Sep 15, 2019 at 02:47:00PM +0100, Jonathan Cameron wrote:
> On Sun, 15 Sep 2019 14:39:17 +0100
> Jonathan Cameron <jic23@...23.retrosnub.co.uk> wrote:
> 
> > On Sun, 15 Sep 2019 14:57:56 +0900
> > William Breathitt Gray <vilhelm.gray@...il.com> wrote:
> > 
> > > The count_read and count_write callbacks are simplified to pass val as
> > > unsigned long rather than as an opaque data structure. The opaque
> > > counter_count_read_value and counter_count_write_value structures,
> > > counter_count_value_type enum, and relevant counter_count_read_value_set
> > > and counter_count_write_value_get functions, are removed as they are no
> > > longer used.
> > > 
> > > Signed-off-by: William Breathitt Gray <vilhelm.gray@...il.com>  
> > 
> > Seems like a sensible bit of excessive abstraction removal to me.  I'm not
> > totally sure why these got so complex in the first place though.
> Ah. I should have read the cover letter rather than just diving in the code :)
> All explained there I see.
> 
> > 
> > Can you recall the reason as it might help to judge why we no longer
> > think the same?
> > 
> > Thanks,
> > 
> > Jonathan

The cover letter probably explains it well enough, but it may be good
anyway for posterity to add on a bit about the origins of the opaque
structures.

If I recall correctly, it was from early on when I had a dedicated set
of functions for "quadrature counters" as opposed to "simple counters"
-- eventually we abandoned that design and decided instead to keep the
interface simple since devices could be represented robustly enough with
just the core Count, Signal, and Synapse components.

I decided to keep the opaque structures anyway in the hope that they
could be used in the future to restrict the attributes exposed to a
certain set of "counter types" defined for the Counter subsystems; i.e.
"position" counters would only expose spatial coordinates, "tally"
counters would expose tally units, etc.

However, I've come to realized that this type of organization is best
left to the userspace application and that the kernelspace code should
instead be focused on maintaining a simple and robust interface for
representing the core concept of a "counter" device.

William Breathitt Gray