RE: [net-next 1/1] virtual-bus: Implementation of Virtual Bus

["Ertman, David M" <david.m.ertman@intel.com>]

> -----Original Message-----
> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Tuesday, November 12, 2019 1:00 PM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
> Cc: davem@davemloft.net; gregkh@linuxfoundation.org; Ertman, David M
> <david.m.ertman@intel.com>; netdev@vger.kernel.org; linux-
> rdma@vger.kernel.org; nhorman@redhat.com; sassmann@redhat.com;
> parav@mellanox.com; Patil, Kiran <kiran.patil@intel.com>
> Subject: Re: [net-next 1/1] virtual-bus: Implementation of Virtual Bus
> 
> On Mon, Nov 11, 2019 at 11:22:19AM -0800, Jeff Kirsher wrote:
> > From: Dave Ertman <david.m.ertman@intel.com>
> >
> > This is the initial implementation of the Virtual Bus, virtbus_device
> > and virtbus_driver.  The virtual bus is a software based bus intended
> > to support lightweight devices and drivers and provide matching
> > between them and probing of the registered drivers.
> >
> > Files added:
> > 	drivers/bus/virtual_bus.c
> > 	include/linux/virtual_bus.h
> > 	Documentation/driver-api/virtual_bus.rst
> >
> > The primary purpose of the virual bus is to provide matching services
> > and to pass the data pointer contained in the virtbus_device to the
> > virtbus_driver during its probe call.  This will allow two separate
> > kernel objects to match up and start communication.
> 
> I think this is the 'multi_subsystem_device' idea I threw out in this thread. ie
> pass an opaque void *pointer, done here by
> virtbus_get_devdata():
> 
>  https://lore.kernel.org/r/20191109084659.GB1289838@kroah.com
> 
> And Greg said 'Ick, no'..
> 
> So each driver should makes its own bus, and perhaps we should provide
> some helper stuff for the repeating code, like PM function reflection?
> 
> Jason

This submission is from a thread with GregKH where I put forth a design proposal
of implementing a new software based bus.  I originally was going to name it
generic bus, and he suggested virtual bus.

Here is the meat of the thread:

>> We could add a new module to the kernel named generic_bus.ko.  This 
>> would create a new generic software bus and a set of APIs that would 
>> allow for adding and removing simple generic virtual devices and 
>> drivers, not as a MFD cell or a platform device. The power management 
>> events would also be handled by the generic_bus infrastructure (suspend, resume, shutdown).
>> We would use this for matching up by having the irdma driver register 
>> with this generic bus and hook to virtual devices that were added from 
>> different PCI LAN drivers.
>> 
>> Pros:
>> 1) This would avoid us attaching anything to the platform bus
>> 2) Avoid having each PCI LAN driver creating its own software bus
>> 3) Provide a common matching ground for generic devices and drivers 
>> that eliminates problems caused by load order (all dependent on 
>> generic_bus.ko)
>> 4) Usable by any other entity that wants a lightweight matching system 
>> or information exchange mechanism
>> 
>> Cons:
>> 1) Duplicates part of the platform bus functionality
>> 2) Adds a new software bus to the kernel architecture
>> 
>> Is this path forward acceptable?
>
>Yes, that is much better.  But how about calling it a "virtual bus"?
>It's not really virtualization, but we already have virtual devices today when you look in sysfs for devices that are created that are not >associated with any specific bus.  So this could take those over quite nicely!  Look at how /sys/devices/virtual/ works for specifics, you could >create a new virtual bus of a specific "name" and then add devices to that bus directly.
>
>thanks,
>
>greg k-h

I am hoping that I didn't completely misunderstand him.

-Dave E