Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190123000057.31477-1-oded.gabbay@gmail.com> <CAPM=9tznaiw+a7rWqfdMMO6Aj3GtsO9vetd=3n9d+bGLW0U8Cg@mail.gmail.com>
 <CAPM=9tybcYSR_xu773W-cV1JfFg1Rcb9NajXhZd+zfZE8+XMRg@mail.gmail.com>
In-Reply-To: <CAPM=9tybcYSR_xu773W-cV1JfFg1Rcb9NajXhZd+zfZE8+XMRg@mail.gmail.com>
From:   Oded Gabbay <oded.gabbay@gmail.com>
Date:   Thu, 24 Jan 2019 00:31:49 +0200
Message-ID: <CAFCwf12FGkc3hDtgeFCn4Z4cgjL8wAf+SRkWqA+04WtuaEdpBA@mail.gmail.com>
Subject: Re: [PATCH 00/15] Habana Labs kernel driver
To:     Dave Airlie <airlied@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Jerome Glisse <jglisse@redhat.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        LKML <linux-kernel@vger.kernel.org>, ogabbay@habana.ai,
        Arnd Bergmann <arnd@arndb.de>, fbarrat@linux.ibm.com,
        andrew.donnellan@au1.ibm.com, Olof Johansson <olof@lixom.net>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jan 24, 2019 at 12:02 AM Dave Airlie <airlied@gmail.com> wrote:
>
> Adding Daniel as well.
>
> Dave.
>
> On Thu, 24 Jan 2019 at 07:57, Dave Airlie <airlied@gmail.com> wrote:
> >
> > On Wed, 23 Jan 2019 at 10:01, Oded Gabbay <oded.gabbay@gmail.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.

Hi Dave,
While I always appreciate your opinion and happy to hear it, I totally
disagree with you on this point.

First of all, as you said, this device is NOT a GPU. Hence, I wasn't
aware that this rule might apply to this driver or to any other driver
outside of drm. Has this rule been applied to all the current drivers
in the kernel tree with userspace facing API via IOCTLs, which are not
in the drm subsystem ?  I see the logic for GPUs as they drive the
display of the entire machine, but this is an accelerator for a
specific purpose, not something generic as GPU. I just don't see how
one can treat them in the same way.

Second, I talked to Greg a couple of weeks ago about this driver and I
definitely didn't get any such requirement from him. Had I gotten such
a requirement, I would have planned this differently.

Third, I think this requirement, while maybe valid for drivers that
are inside an established framework with common userspace library,
such as drm, doesn't apply to a standalone driver which is not part of
any subsystem. There is no way that "someone" will create a userspace
for our H/W without the intimate knowledge of the H/W or without the
ISA of our programmable cores. Maybe for large companies this request
is valid, but for startups complying to this request is not realistic.

To conclude, I think this approach discourage other companies from
open sourcing their drivers and is counter-productive. I'm not sure
you are aware of how difficult it is to convince startup management to
opensource the code...

Thanks,
Oded