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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 3C5B1C433DF for ; Tue, 16 Jun 2020 13:21:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1799D20B1F for ; Tue, 16 Jun 2020 13:21:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592313695; bh=NzmkbhpV6gQ0cqf7U1NrQrUNv6zLElTT90CV/gT2kXo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=CzMWOS1lLoJlq1HuHHy2pQKPBk2x44oYpqjZeCBfIYDtAuJe2a+KY37UUxOhreOJ+ 6fqMkLdwcGwgzIWngZtMxfMtdCCGHQzYt3GNad18Ab0huZf5/6PkJCXceRWKACzKdN MxASiF6TTOoNd6G+nsR/S1qdj04VByKuTYYWg12s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728707AbgFPNVd (ORCPT ); Tue, 16 Jun 2020 09:21:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:41500 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726452AbgFPNVd (ORCPT ); Tue, 16 Jun 2020 09:21:33 -0400 Received: from localhost (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1472D206F1; Tue, 16 Jun 2020 13:21:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592313692; bh=NzmkbhpV6gQ0cqf7U1NrQrUNv6zLElTT90CV/gT2kXo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ofTlfOUw8BPhx2Iu5uPfykNaA7iGUrhxxKy/hPpiDlwfnFVJh00fKYFJlUK9WaU7g wWH/Kw5fsg5b0N0Iee63zhTBNEd4mQraUaXU3u+9ASbhkS64YuHwRgqAi0NryX6IRJ YgEi0dom95iZDI/5Z8TMtN4r7+AjR9G/CHQGGiOM= Date: Tue, 16 Jun 2020 09:21:30 -0400 From: Sasha Levin To: Pavel Machek Cc: Dave Airlie , "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: <20200616132130.GO1931@sasha-vm> References: <20200519163234.226513-1-sashal@kernel.org> <20200616105156.GE1718@bug> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200616105156.GE1718@bug> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 16, 2020 at 12:51:56PM +0200, Pavel Machek wrote: >> > 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... Could you walk me through your view on what the function of the "Signed-off-by" tag is? -- Thanks, Sasha