From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B642AC433E1 for ; Tue, 16 Jun 2020 10:52:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9CB6820B80 for ; Tue, 16 Jun 2020 10:52:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728610AbgFPKwM (ORCPT ); Tue, 16 Jun 2020 06:52:12 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:53542 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728435AbgFPKwL (ORCPT ); Tue, 16 Jun 2020 06:52:11 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id C6A1E1C0BD2; Tue, 16 Jun 2020 12:52:09 +0200 (CEST) Date: Tue, 16 Jun 2020 12:51:56 +0200 From: Pavel Machek To: Dave Airlie Cc: Sasha Levin , "Deucher, Alexander" , Chris Wilson , Ville Syrj??l?? , Hawking Zhang , "Ursulin, Tvrtko" , linux-hyperv@vger.kernel.org, sthemmin@microsoft.com, Greg Kroah-Hartman , haiyangz@microsoft.com, LKML , dri-devel , spronovo@microsoft.com, wei.liu@kernel.org, Linux Fbdev development list , iourit@microsoft.com, kys@microsoft.com Subject: Re: [RFC PATCH 0/4] DirectX on Linux Message-ID: <20200616105156.GE1718@bug> References: <20200519163234.226513-1-sashal@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Having said that, I hit one stumbling block: > > "Further, at this time there are no presentation integration. " > > > > If we upstream this driver as-is into some hyperv specific place, and > > you decide to add presentation integration this is more than likely > > going to mean you will want to interact with dma-bufs and dma-fences. > > If the driver is hidden away in a hyperv place it's likely we won't > > even notice that feature landing until it's too late. > > > > I would like to see a coherent plan for presentation support (not > > code, just an architectural diagram), because I think when you > > contemplate how that works it will change the picture of how this > > driver looks and intergrates into the rest of the Linux graphics > > ecosystem. > > > > As-is I'd rather this didn't land under my purview, since I don't see > > the value this adds to the Linux ecosystem at all, and I think it's > > important when putting a burden on upstream that you provide some > > value. > > I also have another concern from a legal standpoint I'd rather not > review the ioctl part of this. I'd probably request under DRI > developers abstain as well. > > This is a Windows kernel API being smashed into a Linux driver. I don't want to be > tainted by knowledge of an API that I've no idea of the legal status of derived works. > (it this all covered patent wise under OIN?) If you can't look onto it, perhaps it is not suitable to merge into kernel...? What would be legal requirements so this is "safe to look at"? We should really require submitter to meet them... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html