On Sun, 3 May 2020 11:23:16 +0200
Greg Kroah-Hartman [off-list ref] wrote:

On Sat, May 02, 2020 at 05:55:36PM +0100, Jonathan Cameron wrote:

quoted

On Fri, 1 May 2020 11:46:10 -0400
William Breathitt Gray [off-list ref] wrote:
  

quoted

On Thu, Apr 30, 2020 at 10:13:45PM +0200, Alexandre Belloni wrote:  

quoted

Hi,

On 29/04/2020 14:11:34-0400, 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.

To quell any concerns from the offset: this patchset makes no changes to
the existing Counter sysfs userspace interface -- existing userspace
applications will continue to work with no modifications necessary. I
request that driver maintainers please test their applications to verify
that this is true, and report any discrepancies if they arise.
    

On that topic, I'm wondering why the counter subsystem uses /sys/bus
instead of /sys/class that would be more natural for a class of devices.
I can't see how counters would be considered busses. I think you should
consider moving it over to /sys/class (even if deprecating
/sys/bus/counter will be long).    

At the time I wasn't quite familiar with sysfs development so I was
following the iio sysfs code rather closely. However, I see now that
you're probably right: this isn't really a bus but rather a collection
of various types of counters -- i.e. a class of devices.

Perhaps I should migrate this then to /sys/class/counter. Of course, the
/sys/bus/counter location will have to remain for compatibility with
existing applications, but I think a simple symlink to the new
/sys/class/counter location should suffice for that.

If anyone sees an issue with this give me a heads up.  

To just address this point as I've not read the rest of the thread yet...

I would resist moving it.  This one is an old argument. 

Some info in https://lwn.net/Articles/645810/
As that puts it a "bus" is better known as a "subsystem".

When we originally considered class vs bus for IIO, the view expressed
at the times was that the whole separation of the two didn't mean anything
and for non trivial cases bus was always preferred.  It's nothing to do
with with whether the thing is a bus or not.  Now I suppose it's possible
opinion has moved on this topic...    However, I'd say there
is really 0 advantage in moving an existing subsystem even if opinion
has changed.

+CC Greg in case he wants to add anything.  

Traditionally classes are a unified way of representing data to
userspace, independant of the physical transport that the data came to
userspace on (i.e. input devices are a class, it doesn't matter if they
came on serial, USB, PS/2, or virtual busses.)

A bus is traditionally a collection of drivers that all talk on a same
physical transport, that then expose data from that transport to a
specific userspace class.  Again, think USB mice drivers, serial mice
drivers, PS/2 mice drivers.

Busses bind a driver to a device it creates based on that "bus".
Classes create virtual devices that export data to userspace for a
specific common protocol.

Does that help?

One can argue (and have properly in the past), that classes and busses
really are not all that different, and there used to be code floating
around that made them the same exact thing in the kernel, with loads of
userspace sysfs symlinks to preserve things, but those are well out of
date and I don't think anyone feels like reviving them.  However I think
systemd might still have code in it to work properly if that ever
happens, haven't looked in a few years...

thanks,

greg k-h

Thanks for the explanation. Here key thing to my mind is counters went
in as a bus and should stay so because there is limited benefit in a move
and it would be ABI breaking.  Maybe it 'should' have been a class, but
too late now.

Jonathan


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