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]

Message-ID: <CAOesGMiWqRSxaCQ3nn_Y3Ujan_60dvoiGZ3goBmxXfmOa=yR2Q@mail.gmail.com>
Date:   Fri, 25 Jan 2019 09:13:04 -0800
From:   Olof Johansson <olof@...om.net>
To:     Andrew Donnellan <andrew.donnellan@....ibm.com>
Cc:     Oded Gabbay <oded.gabbay@...il.com>,
        Dave Airlie <airlied@...hat.com>,
        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 Wed, Jan 23, 2019 at 5:03 PM Andrew Donnellan
<andrew.donnellan@....ibm.com> wrote:
>
> 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/?)

How about moving them but keeping a stub in misc that just includes
the moved file?

> 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...

I've lost all lists.ozlabs.org muscle memory these days, but that
seems reasonable to me.



-Olof