> From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxx> > > > Sent: Thursday, October 1, 2020 12:14 AM > > > To: Ertman, David M <david.m.ertman@xxxxxxxxx> > > > Cc: alsa-devel@xxxxxxxxxxxxxxxx; tiwai@xxxxxxx; broonie@xxxxxxxxxx; > > > pierre- louis.bossart@xxxxxxxxxxxxxxx; Sridharan, Ranjani > > > <ranjani.sridharan@xxxxxxxxx>; jgg@xxxxxxxxxx; parav@xxxxxxxxxx > > > 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'?
