On Sun, May 03, 2020 at 01:54:58PM +0100, Jonathan Cameron wrote: > On Sun, 3 May 2020 11:23:16 +0200 > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Sat, May 02, 2020 at 05:55:36PM +0100, Jonathan Cameron wrote: > > > On Fri, 1 May 2020 11:46:10 -0400 > > > William Breathitt Gray <vilhelm.gray@xxxxxxxxx> wrote: > > > > > > > On Thu, Apr 30, 2020 at 10:13:45PM +0200, Alexandre Belloni wrote: > > > > > Hi, > > > > > > > > > > On 29/04/2020 14:11:34-0400, William Breathitt Gray wrote: > > > > > > 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 Very well, that's an understandable reason to avoid incompatibility issues down the road, and userspace applications apparently care little about the difference between /sys/bus and /sys/class anyway, so I'll keep things as they are now and avoid those unnecessary changes. William Breathitt Gray
Attachment:
signature.asc
Description: PGP signature
