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

[Greg KH <gregkh@linuxfoundation.org>]

On Sat, Oct 03, 2020 at 11:08:55AM +0200, Greg KH wrote:
> 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.

Also, the fact that we are even talking about a core kernel function on
only the alsa-devel list is pretty horrible.  I'm just going to drop
this whole thread and wait until you can submit it properly before
responding anymore on it.

greg k-h