linux-kernel - Re: [PATCH 00/15] Habana Labs kernel driver

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:   Thu, 24 Jan 2019 12:03:06 +1100
From:   Andrew Donnellan <andrew.donnellan@....ibm.com>
To:     Olof Johansson <olof@...om.net>,
        Oded Gabbay <oded.gabbay@...il.com>,
        Dave Airlie <airlied@...hat.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ogabbay@...ana.ai, Arnd Bergmann <arnd@...db.de>,
        fbarrat@...ux.ibm.com, linux-accelerators@...ts.ozlabs.org
Subject: Re: [PATCH 00/15] Habana Labs kernel driver

On 24/1/19 8:52 am, Olof Johansson wrote:
> But, I think the largest question I have (for a broader audience) is:
> 
> I predict that we will see a handful of these kind of devices over the
> upcoming future -- definitely from ML accelerators but maybe also for
> other kinds of processing, where there's a command-based, buffer-based
> setup sending workloads to an offload engine and getting results back.
> While the first waves will all look different due to design trade-offs
> made in isolation, I think it makes sense to group them in one bucket
> instead of merging them through drivers/misc, if nothing else to
> encourage more cross-collaboration over time. First steps in figuring
> out long-term suitable frameworks is to get a survey of a few
> non-shared implementations.
> 
> So, I'd like to propose a drivers/accel drivers subtree, and I'd be
> happy to bootstrap it with a small group (@Dave Airlie: I think your
> input from GPU land be very useful, want to join in?). Individual
> drivers maintained by existing maintainers, of course.
> 
> I think it might make sense to move the CAPI/OpenCAPI drivers over as
> well -- not necessarily to change those drivers, but to group them
> with the rest as more show up.

For cxl/ocxl, I have no objection to moving to this new subtree if 
that's what we all agree to do. (what do people do about UAPI headers in 
this situation? keep them where they are in misc/?)

If we do go ahead and set up this new subtree, perhaps we can use the 
mailing list I set up at linux-accelerators@...ts.ozlabs.org but we 
haven't really started using...

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@....ibm.com  IBM Australia Limited