> -----Original Message----- > From: kvm-owner@xxxxxxxxxxxxxxx <kvm-owner@xxxxxxxxxxxxxxx> On Behalf > Of Jakub Kicinski > Sent: Sunday, November 10, 2019 9:46 PM > On Sun, 10 Nov 2019 10:18:55 +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote: [..] > The nice thing about having a fake bus is you can load out-of-tree drivers to > operate extra protocols quite cleanly. > This series does NOT intent to do any out of tree driver. Please do not think in that direction for this series. > I'm not saying that's what the code in question is doing, I'm saying I'd > personally like to understand the motivation more clearly before every > networking driver out there starts spawning buses. The only argument I've > heard so far for the separate devices is reloading subset of the drivers, which > I'd rate as moderately convincing. Primary objectives behind using a bus in this series is: 1. get same level of device view as PF/VF/SF by devlink instance 2. to not re-invent already matured pm (suspend/resume) in devlink and/or vendor driver 3. ability to bind a sub-function to different drivers depending on use case based on 'in-kernel' defined class-id (mdev/virtio/kernel) - just like vfio-pci and regular PF driver, by following standard driver model (Ofcourse, It can be done using 3 or more buses as one virtual mdev bus appears an abuse) 4. create->configure->bind process of an sub function (just like a VF) 5. persistent naming of sf's netdev and rdmadev (again like PF and VF) I will wait for Jason's and Jiri's view on the alternative proposal I sent few hours back to omit bus for in-kernel use of sf; and see how far can we run without a bus :-)
