Messages in this thread | | | Date | Tue, 16 Jun 2020 09:21:30 -0400 | From | Sasha Levin <> | Subject | Re: [RFC PATCH 0/4] DirectX on Linux |
| |
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
| |