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 08:02:04 +1000
From:   Dave Airlie <airlied@...il.com>
To:     Oded Gabbay <oded.gabbay@...il.com>,
        Jerome Glisse <jglisse@...hat.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>, ogabbay@...ana.ai
Subject: Re: [PATCH 00/15] Habana Labs kernel driver

Adding Daniel as well.

Dave.

On Thu, 24 Jan 2019 at 07:57, Dave Airlie <airlied@...il.com> wrote:
>
> On Wed, 23 Jan 2019 at 10:01, Oded Gabbay <oded.gabbay@...il.com> wrote:
> >
> > Hello,
> >
> > For those who don't know me, my name is Oded Gabbay (Kernel Maintainer
> > for AMD's amdkfd driver, worked at RedHat's Desktop group) and I work at
> > Habana Labs since its inception two and a half years ago.
>
> Hey Oded,
>
> So this creates a driver with a userspace facing API via ioctls.
> Although this isn't a "GPU" driver we have a rule in the graphics
> drivers are for accelerators that we don't merge userspace API with an
> appropriate userspace user.
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>
> I see nothing in these accelerator drivers that make me think we
> should be treating them different.
>
> Having large closed userspaces that we have no insight into means we
> get suboptimal locked for ever uAPIs. If someone in the future creates
> an open source userspace, we will end up in a place where they get
> suboptimal behaviour because they are locked into a uAPI that we can't
> change.
>
> Dave.