Microsoft Reworks The "DXGKRNL" Driver It Wants To Get Into The Linux Kernel

[mdedetrich]

Clearly you have no idea how lkml works or you would not expect them to have noticed one way or another that directx is required yet.

No one has dimissed the premise of the changeset, if directx truly is optional as others have said there is no problem.

So your whole premise for trolling for 4 pages is that LKML maintainers are stupid.

You are digging that hole pretty hard

[mSparks]

So your whole premise for trolling for 4 pages is that LKML maintainers are stupid.

You are digging that hole pretty hard

lol. no.
"I'll stop here, please fix up this patch series into something that is reviewable. " means the maintainers didnt even LOOK at it before they rejected it.

We here were just discussing what happens when they do. And correcting a few misconceptions for those who thought the linux kernel is lgpl2.1 licenced.

I get the impression maybe you didnt actually read the thread, article or lkml tho. maybe do that before putting words in peoples mouth and generally behaving like a 4 year old. Maybe you would be better on tiktok than phoronix? seems better suited to you.

[mdedetrich]

"I'll stop here, please fix up this patch series into something that is reviewable. " means the maintainers didnt even LOOK at it before they rejected it.

Uhh, he was talking about the size of the patches not the content. The same person also did comment on the content in other messages.

Even without reading the content of the patches its very clear what the feature is, again if it was an issue it would have immediately been shot down without even looking at the code.

Try again please

[mSparks]

Uhh, he was talking about the size of the patches not the content. The same person also did comment on the content in other messages.

Even without reading the content of the patches its very clear what the feature is, again if it was an issue it would have immediately been shot down without even looking at the code.

Try again please

Try again to what?
What other way is there to explain to you the code hasnt been reviewed yet, the patch in the article has already been rejected, and if it isnt compliant with gplv2 has no chance of getting mainlined?

Just because you dont like those basic facts doesnt give you the right to call maintainers stupid or throw a tantrum and expect anyone to care.

[tyolotd]

So, your main line of reasoning why

1. DXGKRNL requires DirectX
2. DirectX requires a closed source userspace component that is not GPLv2 compliant, requiring it makes DXGKRNL non GPLv2 compliant
3. non GPLv2 compliant patches are not suitable for mainlining in the kernel

doesn't become

1. DXGKRNL requires DirectX
2. DirectX is not GPLv2 compliant, requiring it makes DXGKRNL non GPLv2 compliant
3. non GPLv2 compliant patches are not suitable for mainlining in the kernel

So in other words: "Linux maintainers have a high standard that goes above and beyond the GPLv2 and they won't accept GPLv2 code that relies on proprietary code, even if it's technically within the bounds of the GPLv2"

And, hell, you may be right. But I don't think so. I think that this patch skirts around the GPLv2 enough to satisfy the kernel maintainers, and I also think that a lot of Linux users (on WSL) are excited about this feature.

[mSparks]

So in other words: "Linux maintainers have a high standard that goes above and beyond the GPLv2 and they won't accept GPLv2 code that relies on proprietary code, even if it's technically within the bounds of the GPLv2"

And, hell, you may be right. But I don't think so. I think that this patch skirts around the GPLv2 enough to satisfy the kernel maintainers, and I also think that a lot of Linux users (on WSL) are excited about this feature.

Maybe, maybe not. Im more interested to know what this non directx option is people were just talking about.

Part of the comments to this patch was to strip out all the directx/windows naming and use existing linux kernel options and naming.

The most recent example of this kind of attempt I can think of is one of the database companies wanting kernel features for their closed sourced software. went nowhere. That was a Phoronix article but cant find it.

Microsoft were already told they cant rely on closed sourced components last time - I just dont see how they can skirt around it for directx. We also already have vulkan acceleration.

They will also need to replace the cuda with opencl (since no mainlined cuda support in the kernel for the same reasons) and I suspect they will be pushed towards DXVK.

[mdedetrich]

So in other words: "Linux maintainers have a high standard that goes above and beyond the GPLv2 and they won't accept GPLv2 code that relies on proprietary code, even if it's technically within the bounds of the GPLv2"

And, hell, you may be right. But I don't think so. I think that this patch skirts around the GPLv2 enough to satisfy the kernel maintainers, and I also think that a lot of Linux users (on WSL) are excited about this feature.

Well hes wrong because the Hyper-V module wouldn't even exist in the kernel if that was the stance of the maintainers (which its not)

[mSparks]

Well hes wrong because the Hyper-V module wouldn't even exist in the kernel if that was the stance of the maintainers (which its not)

Hyper V was
https://www.redhat.com/en/blog/red-h...l-contribution

This is not even remotely similar, even if we were living in the same world as 13 years ago, which we are not.

Microsoft HAS ALREADY BEEN TOLD they cannot rely on anything closed source for this patch all the way back in May 2020 by Daniel Vetter.

They were also told not to waste their time reinventing the wheel.

I mean sure, if MS wants to opensource directx or there really already is an open source alternative they will be fine when/if it gets to actually be reviewed and tested.

Perhaps you believe MS will release directx as gplv2?

I dont.