> -----Original Message----- > From: Jason Gunthorpe <jgg@xxxxxxxx> > Sent: Tuesday, November 12, 2019 1:00 PM > To: Kirsher, Jeffrey T <jeffrey.t.kirsher@xxxxxxxxx> > Cc: davem@xxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; Ertman, David M > <david.m.ertman@xxxxxxxxx>; netdev@xxxxxxxxxxxxxxx; linux- > rdma@xxxxxxxxxxxxxxx; nhorman@xxxxxxxxxx; sassmann@xxxxxxxxxx; > parav@xxxxxxxxxxxx; Patil, Kiran <kiran.patil@xxxxxxxxx> > 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@xxxxxxxxx> > > > > 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@xxxxxxxxx > > 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
