RE: [PATCH 0/6] Ancillary bus implementation and SOF multi-client support

[Parav Pandit <parav@nvidia.com>]

> From: Greg KH <gregkh@linuxfoundation.org>
> Sent: Saturday, October 3, 2020 2:39 PM
> 
> On Fri, Oct 02, 2020 at 08:23:49PM +0000, Ertman, David M wrote:
> > > -----Original Message-----
> > > From: Greg KH <gregkh@linuxfoundation.org>
> > > Sent: Thursday, October 1, 2020 12:14 AM
> > > To: Ertman, David M <david.m.ertman@intel.com>
> > > Cc: alsa-devel@alsa-project.org; tiwai@suse.de; broonie@kernel.org;
> > > pierre- louis.bossart@linux.intel.com; Sridharan, Ranjani
> > > <ranjani.sridharan@intel.com>; jgg@nvidia.com; parav@nvidia.com
> > > Subject: Re: [PATCH 0/6] Ancillary bus implementation and SOF
> > > multi-client support
> > >
> > > On Wed, Sep 30, 2020 at 03:50:45PM -0700, Dave Ertman wrote:
> > > > The ancillary bus (then known as virtual bus) was originally
> > > > submitted along with implementation code for the ice driver and
> > > > irdma drive, causing the complication of also having dependencies in the
> rdma tree.
> > > > This new submission is utilizing an ancillary bus consumer in only
> > > > the sound driver tree to create the initial implementation and a
> > > > single user.
> > >
> > > So this will not work for the ice driver and/or irdma drivers?  It
> > > would be great to see how they work for this as well as getting
> > > those maintainers to review and sign off on this implementation as well.
> > > Don't ignore those developers, that's a bit "odd", don't you think?
> > >
> > > To drop them from the review process is actually kind of rude, what
> > > happens if this gets merged without their input?
> > >
> > > And the name, why was it changed and what does it mean?  For
> > > non-native english speakers this is going to be rough, given that I
> > > as a native english speaker had to go look up the word in a
> > > dictionary to fully understand what you are trying to do with that name.
> >
> > Through our internal review process, objections were raised on naming
> > the new bus virtual bus. The main objection was that virtual bus was
> > too close to virtio, virtchnl, etc., that /sys/bus/virtual would be
> > confused with /sys/bus/virtio, and there is just a lot of 'virt' stuff in the kernel
> already.
> 
> We already have a virtual bus/location in the driver model today, has that
> confused anyone?  I see this as an extension of that logic and ideally, those
> users will be moved over to this interface over time as well.
> 
> > Several names were suggested (like peer bus, which was shot down
> > because in parts on the English speaking world the peerage means
> > nobility), finally "ancillary bus" was arrived at by consensus of not hating it.
> 
> "not hating it", while sometimes is a good thing, for something that I am going
> to have to tell everyone to go use, I would like to at least "like it".  And right now
> I don't like it...
> 
> I think we should go back to "virtual" for now, or, if the people who didn't like it
> on your "internal" reviews wish to participate here and defend their choice, I
> would be glad to listen to that reasoning.
> 
Like Greg and Leon, I was no exception to look up dictionary to understand the meaning on my first review.
But I don't have strong opinion.

Since intended use of the bus is to create sub devices, either for matching service purpose or for actual subdevice usage,

How about naming the bus, 'subdev_bus'?