linux-kernel - Re: [RFC net-next 1/8] subdev: Introducing subdev 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, 26 Mar 2019 11:48:36 +0000
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Parav Pandit <parav@...lanox.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, michal.lkml@...kovi.net,
        davem@...emloft.net, jiri@...lanox.com
Subject: Re: [RFC net-next 1/8] subdev: Introducing subdev bus

On Fri, Mar 01, 2019 at 08:17:27AM +0100, Greg KH wrote:
> On Thu, Feb 28, 2019 at 11:37:45PM -0600, Parav Pandit wrote:
> > Introduce a new subdev bus which holds sub devices created from a
> > primary device. These devices are named as 'subdev'.
> > A subdev is identified similarly to pci device using 16-bit vendor id
> > and device id.
> > Unlike PCI devices, scope of subdev is limited to Linux kernel.
> 
> But these are limited to only PCI devices, right?
> 
> This sounds a lot like that ARM proposal a week or so ago that asked for
> something like this, are you working with them to make sure your
> proposal works for them as well?  (sorry, can't find where that was
> announced, it was online somewhere...)

Thanks for pointing this out and sorry for the delay in chiming in.

Blog post and white paper are available here:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/high-performance-device-virtualization-approach-to-standardization

It would be certainly good to reach a degree of convergence in this
design space, which eventually will be beneficial for the kernel
interfaces required.

Thanks again for pointing this out.

Lorenzo