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

[gregkh at linuxfoundation.org]

On Tue, Oct 06, 2020 at 03:40:58PM -0700, Dan Williams wrote:
> On Mon, Oct 5, 2020 at 4:25 AM gregkh at linuxfoundation.org
> <gregkh at linuxfoundation.org> wrote:
> >
> > On Sun, Oct 04, 2020 at 11:45:41PM +0000, Williams, Dan J wrote:
> > > [ 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 will publically state that without those middle-tier reviews, this
> > would have been a worse submission, which is why I am _REQUIRING_ them
> > from Intel at the moment.
> >
> > So your review did not happen in vain, and if developers complain about
> > this, send them to me please.
> >
> > As for the name, why is everyone ignoring the fact that we have had
> > /sys/devices/virtual/ for decades now, with no one being confused about
> > that name usage?  I see this as an extension of that existing code
> > pattern, is everyone missing that?
> 
> Oh, I was specifically reacting to /sys/devices/virtual being a place
> where un-parented devices land. Things like raid composite devices and
> other devices that just do not fit cleanly in the parent device
> hierarchy, each of them has independent lifetime rules, some do not
> attach to drivers they just exist in an "unbound" state when active...
> it's an anything goes catch all space. This bus is the opposite, all
> devices have a maximum lifetime tied to their parent device bind
> lifetime, and they are not active without drivers. Placing them under
> /sys/bus/virtual/devices confuses what the "virtual" term means to
> sysfs.

"virtual" here means "not real" :)

> "ancillary" devices and drivers has meaning to me, in a way that
> "virtual" devices and drivers does not. If "ancillary" does not hit
> the right tone what about "aux" for "auxiliary"
> (/sys/bus/aux/devices)?

"aux" is nice, I'll think about that.  simple is good, and naming is
hard...

thanks,

greg k-h