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

[sinepgib]

GPL doesn't mean that others have to accept your original work.

No, but it doesn't mean you can't accept them either, and history shows the kernel maintainers are OK with accepting code interfacing with closed source MS technologies, as long as they are just platform support, such as this and Hyper-V's cases.

IF MS really want it, they can fork the Kernel like Google did and put as many tainted patches in as they want - Yes.

If by "tainted" you mean non-GPLv2 compliant, then you're also wrong here. Forks are covered by the GPL just as much as mainline. They wouldn't be able to legally distribute that.

That doesn't mean the mainline Kernel developers will accept tainted patches - they dont. Even (and especially) for Microsoft.

Quackdoc and I have shown you several examples of this kind of "tainted" patches coming specifically from Microsoft that got mainlined. And willingness from Greg KH is no small thing, he's Linus' right hand.

one of us doesn't - dont think its me

OK. Let me explain it in simple terms. Copyleft propagates to forks. That's pretty much the idea. Whether Android forks the kernel is irrelevant. If you really had to ship only copyleft software to ship Linux in a device, Android would have to do the same. It doesn't, because copyleft only works for derivatives, not all the stuff that runs on top of it. At this point I can only assume you're trolling, nobody can be that misguided. I'll desubscribe and stop feeding you after this message.
I will put up a reminder to tell you "fucking told you so" in a few weeks when Michael posts it's been merged :^)

Linux kernel is not GPL2.1
And that's only the start of where you are wrong.

It's 2.0, which is still less restrictive than GPL3. https://git.kernel.org/pub/scm/linux...t/tree/COPYING

what benefit does it bring to the kernel without directx installed?
(because those testing it wont install directx on their machines btw, because they only test in a gplv2 environment, which is how they found the netgpu patch wouldnt even compile)

https://www.cultofmac.com/162823/linux-creator-linus-torvalds-i-love-my-macbook-air/

please refer to

"A position statement on closed-source kernel modules"

which quite clearly explains who disagrees with you.

Which clearly explains the object is about closed-source kernel modules, which _is_ _not_ _the_ _case_.

[mSparks]

No, but it doesn't mean you can't accept them either, and history shows the kernel maintainers are OK with accepting code interfacing with closed source MS technologies, as long as they are just platform support, such as this and Hyper-V's cases.

Absolutely NOT, the policy statement saying exactly the opposite of this has been in place since 2008.
So unless you have a NEW policy statement that overrides that you are talking absolute BS
Hyper-V is open source, Microsoft violates its licence, see "Microsoft accused of being in violation of GPL on Hyper-V code"
Probably not the best example to use eh.

Which clearly explains the object is about closed-source kernel modules, which _is_ _not_ _the_ _case_.

kernel modules, drivers and, since around 2020, applications. No working fully open source alternative to be useful, no mainline. no workarounds, just lots of laughter and a "must try harder" report sheet.

[sinepgib]

Absolutely NOT, the policy statement saying exactly the opposite of this has been in place since 2008.
So unless you have a NEW policy statement that overrides that you are talking absolute BS
Hyper-V is open source, Microsoft violates its licence, see "Microsoft accused of being in violation of GPL on Hyper-V code"
Probably not the best example to use eh.

Hyper-V is not open source. The Linux driver to use Hyper-V on the host is. It's in the same article you named (and please, provide links when you do). Which is the case here, just a driver to interface with Windows.
And the fact this statement predates vastly the Hyper-V driver proves it clearly doesn't apply here. The statement is about closed source kernel modules (not the case) and closed source user space (not the case).

Good bye.

[mSparks]

Hyper-V is not open source. The Linux driver to use Hyper-V on the host is. It's in the same article you named (and please, provide links when you do). Which is the case here, just a driver to interface with Windows.
And the fact this statement predates vastly the Hyper-V driver proves it clearly doesn't apply here. The statement is about closed source kernel modules (not the case) and closed source user space (not the case).

Good bye.

So cute you think that argument will work with them.

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

is its like the Hyper V driver mainlined in 2.6.32 on December 2, 2009.....
And it doesn't strike you as remotely odd you have no other examples since?

Please excuse me for not finding your argument that convincing

[mdedetrich]

So cute you think that argument will work with them.

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



is its like the Hyper V driver mainlined in 2.6.32 on December 2, 2009.....
And it doesn't strike you as remotely odd you have no other examples since?

Please excuse me for not finding your argument that convincing

Can you stop concern trolling? If you think this is a legitimate issue then post it on the kernel mailing list and stop spamming the Phoronix forums.

[mSparks]

Can you stop concern trolling? If you think this is a legitimate issue then post it on the kernel mailing list and stop spamming the Phoronix forums.

Its not the kernel mailing list that needs to worry about Microsoft engineers wasting their time, they already know.

[mdedetrich]

Its not the kernel mailing list that needs to worry about Microsoft engineers wasting their time, they already know.

According to Linux Kernel maintainers you are wrong, check the mailing list.

[mSparks]

According to Linux Kernel maintainers you are wrong, check the mailing list.

according to lkml doesnt look like it even made it past basic code review. including classic sentences like "this is not microsoft".

[mdedetrich]

according to lkml doesnt look like it even made it past basic code review. including classic sentences like "this is not microsoft".

Clearly you have no idea how lkml works or look at any other code reviews at lkml. Almost every single changeset gets the same type of comments/criticism, the authors work on the problems and eventually the changesets get merged. The critical point is that no maintainer dismissed the premise of the changeset.

Sorry to disappoint you and your desperate attempts to discredit the changeset.

[mSparks]

Clearly you have no idea how lkml works or look at any other code reviews at lkml. Almost every single changeset gets the same type of comments/criticism, the authors work on the problems and eventually the changesets get merged. The critical point is that no maintainer dismissed the premise of the changeset.

Sorry to disappoint you and your desperate attempts to discredit the changeset.

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.