Message-ID: <20200503131618.GA4758@shinobu>
Date:   Sun, 3 May 2020 09:16:18 -0400
From:   William Breathitt Gray <vilhelm.gray@...il.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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, May 03, 2020 at 01:54:58PM +0100, Jonathan Cameron wrote:
> 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

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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists