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'?