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@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > On Sun, 15 Sep 2019 14:57:56 +0900 > > William Breathitt Gray <vilhelm.gray@xxxxxxxxx> 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@xxxxxxxxx> > > > > 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
