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

[Parav Pandit <parav@nvidia.com>]

> From: Ertman, David M <david.m.ertman@intel.com>
> Sent: Monday, October 5, 2020 6:49 AM
> 
> > -----Original Message-----
> > From: Williams, Dan J <dan.j.williams@intel.com>
> > Sent: Sunday, October 4, 2020 4:46 PM
> > To: Ertman, David M <david.m.ertman@intel.com>;
> > gregkh@linuxfoundation.org
> > Cc: pierre-louis.bossart@linux.intel.com; parav@nvidia.com;
> > broonie@kernel.org; jgg@nvidia.com; Sridharan, Ranjani
> > <ranjani.sridharan@intel.com>; alsa-devel@alsa-project.org;
> > tiwai@suse.de
> > Subject: Re: [PATCH 0/6] Ancillary bus implementation and SOF
> > multi-client support
> >
> > [ Ugh, as other have lameneted, I was not copied on this thread so I
> > could not respond in real time. Let me be another to say, please copy
> > all impacted lists and stakeholders on patches. ]
> >
> > On Sat, 2020-10-03 at 11:08 +0200, Greg KH wrote:
> > [..]
> > >
> > > > 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.
> >
> > I came out strongly against "virtual" because there is nothing virtual
> > about these devices, they are functional partitions of the parent
> > device. Also, /sys/devices/virtual is already the land of unparented
> > / software-defined devices. Having /sys/devices/virtual alongside that
> > is  not quite a namespace collision, but it's certainly namespace
> > confusion in my view.
> >
> > I proposed other names, the team came back with "ancillary" which was
> > not my first choice, but perfectly suitable. In deference to the
> > people doing the work I let their choice stand.
> >
> > It is an uncomfortable position being a middle tier reviewer of pre-
> > release patch sets when the patch set can still be de-railed by
> > preference nits. A lack of deference makes it a difficult job to
> > convince people "hey my internal review will save you some time
> > upstream", when in practice they can see the opposite is true.
> 
> I have to admit that I am biased towards the virtual bus (or virtbus) name as
> that is what I was using during the original implementation of this code.
> 
> That being said, I can also understand Dan's objection to the name.
> 
> At first, I didn't object to Parav's suggestion of subdev bus, but the more I
> think of it, I don't want to have to describe to someone how to use a subdev
> device's sub device element (yikes, what a mouthful!).
We have fair documentation that describes what an ancillary device is in the Documentation file of this patch.
Do you plan to remove that after renaming the bus in spirit of not describing comment above?

As Dan clearly described what devices are ancillary device in previous email -> " they are functional partitions of the parent device ",
How about subfunction_bus or partdev_bus?

So I have 3 simpler names that describes it multiple use cases.
(a) subdev_bus
(b) subfunction_bus
(c) partdev_bus