On Tue, Oct 06, 2020 at 03:40:58PM -0700, Dan Williams wrote: > On Mon, Oct 5, 2020 at 4:25 AM gregkh@xxxxxxxxxxxxxxxxxxx > <gregkh@xxxxxxxxxxxxxxxxxxx> 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
