On Wed, 29 Apr 2020 15:21:05 -0500
David Lechner [off-list ref] wrote:

On 4/29/20 1:11 PM, William Breathitt Gray wrote:

quoted

Over the past couple years we have noticed some shortcomings with the
Counter sysfs interface. Although useful in the majority of situations,
there are certain use-cases where interacting through sysfs attributes
can become cumbersome and inefficient. A desire to support more advanced
functionality such as timestamps, multi-axis positioning tables, and
other such latency-sensitive applications, has motivated a reevaluation
of the Counter subsystem. I believe a character device interface will be
helpful for this more niche area of counter device use.  

Nice to see some progress being made. :-)

quoted

Interaction with Counter character devices occurs via ioctl commands.
This allows userspace applications to access and set counter data using
native C datatypes rather than working through string translations.  

For most aspects of the counter subsystem, this is not an issue since
configuring a counter is not a time-sensitive operation. Instead of
ioctls, I was expecting to just be able to read the character device
and receive counter events or poll to wait for events similar to how
the input subsystem works or how buffers work in the iio subsystem.

I'm afraid I don't really see much use in having ioctls that do
exactly what sysfs already does. And my intuition tells me that the
extra work needed to maintain it will probably cost more than any
benefit gained. (Maybe other have a different experience that leads
to a different conclusion?)

I agree with David here.  The ioctls are currently doing what could have
been done nicely with a userspace library.  Moving away from the string
based internal interface is a good move to my mind, because it ensures
consistency in they sysfs interface and provides for in kernel users
when they make sense.  The step of then using that to simplify providing
an IOCTL interface to do the same things doesn't seem particularly useful.
So what do we gain?

Jonathan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel