Date:   Sun, 3 May 2020 13:54:58 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     William Breathitt Gray <vilhelm.gray@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        kamel.bouhara@...tlin.com, gwendal@...omium.org,
        david@...hnology.com, felipe.balbi@...ux.intel.com,
        fabien.lahoudere@...labora.com, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org, syednwaris@...il.com,
        patrick.havelange@...ensium.com, fabrice.gasnier@...com,
        mcoquelin.stm32@...il.com, alexandre.torgue@...com
Subject: Re: [PATCH 0/4] Introduce the Counter character device interface

On Sun, 3 May 2020 11:23:16 +0200
Greg Kroah-Hartman <gregkh@...uxfoundation.org> 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@...il.com> 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

Powered by blists - more mailing lists