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

[Ertman, David M]

> -----Original Message-----
> From: Williams, Dan J <dan.j.williams at intel.com>
> Sent: Sunday, October 4, 2020 4:46 PM
> To: Ertman, David M <david.m.ertman at intel.com>;
> gregkh at linuxfoundation.org
> Cc: pierre-louis.bossart at linux.intel.com; parav at nvidia.com;
> broonie at kernel.org; jgg at nvidia.com; Sridharan, Ranjani
> <ranjani.sridharan at intel.com>; alsa-devel at alsa-project.org; tiwai at 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!).

At this point, I just want a name that is easy to understand and doesn't
generate a lot of confusion or tongue twisting alliteration.

Can we call it the super_useful bus? (j/k 😊 ).

Some possible names:
aggregate (useable across subsystems)
gob (bunch group or block - kinda reminds me of git)
collect (brings together drivers from different subsystems)
flock
heap
sect (splinter group)
not_platform 😉

Any of these interest anybody?