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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 12 Nov 2019 21:18:52 +0000
From:   "Ertman, David M" <david.m.ertman@...el.com>
To:     Jason Gunthorpe <jgg@...pe.ca>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "parav@...lanox.com" <parav@...lanox.com>,
        "Patil, Kiran" <kiran.patil@...el.com>
Subject: RE: [net-next 1/1] virtual-bus: Implementation of Virtual Bus

> -----Original Message-----
> From: Jason Gunthorpe <jgg@...pe.ca>
> Sent: Tuesday, November 12, 2019 1:00 PM
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@...el.com>
> Cc: davem@...emloft.net; gregkh@...uxfoundation.org; Ertman, David M
> <david.m.ertman@...el.com>; netdev@...r.kernel.org; linux-
> rdma@...r.kernel.org; nhorman@...hat.com; sassmann@...hat.com;
> parav@...lanox.com; Patil, Kiran <kiran.patil@...el.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@...el.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