> -----Original Message----- > From: Williams, Dan J <dan.j.williams@xxxxxxxxx> > Sent: Sunday, October 4, 2020 4:46 PM > To: Ertman, David M <david.m.ertman@xxxxxxxxx>; > gregkh@xxxxxxxxxxxxxxxxxxx > Cc: pierre-louis.bossart@xxxxxxxxxxxxxxx; parav@xxxxxxxxxx; > broonie@xxxxxxxxxx; jgg@xxxxxxxxxx; Sridharan, Ranjani > <ranjani.sridharan@xxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx; tiwai@xxxxxxx > 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?
