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]
Message-ID: <20190326114836.GA4000@e107981-ln.cambridge.arm.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ