Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mSparks
    replied
    Originally posted by Quackdoc View Post
    if it was an issue, it would have already been turned away, but it hasn't been.
    It was, they think they can rework it.
    Which brings us right back to my OP. How do they plan on making it useful without requiring DirectX? - because that is the only way they will get it mainlined.

    Leave a comment:


  • Quackdoc
    replied
    if it was an issue, it would have already been turned away, but it hasn't been.

    Leave a comment:


  • mSparks
    replied
    Originally posted by mdedetrich View Post
    GPL 2.1
    Linux kernel is not GPL2.1
    And that's only the start of where you are wrong.

    Leave a comment:


  • mSparks
    replied
    Originally posted by mdedetrich View Post

    Incorrect, GPL only cares about derivative works. .
    GPL doesn't mean that others have to accept your original work.
    IF MS really want it, they can fork the Kernel like Google did and put as many tainted patches in as they want - Yes.

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



    Leave a comment:


  • mdedetrich
    replied
    Originally posted by mSparks View Post

    GPL covers the entirety of what the patch does in its functional form, so requiring DirectX to function (even if it isnt bundled) makes the patch "non GPL", even if all the code in the patch itself is GPL.
    Incorrect, GPL only cares about derivative works. Again see Hyper-V which requires Windows to actually do anything (it is "implemented" in Windows), however there is a Kernel module for Hyper-V in the linux kernel to do this transation

    Originally posted by mSparks View Post
    "spirit" of the GPL.
    Subjective and irrelevant

    Originally posted by mSparks View Post
    You cant just stick a small non functioning patch into the kernel if it doesn't work without non GPLv2 modules. Numerous examples of these getting rejected over the years. No amount of refactoring will change that unless the patch can be made useful in and of itself.
    Yes you can and sorry to say, its happened many times (at least if we ignore your incorrect classification of what GPL 2.1 is). Also these recent changes have nothing to do with GPL 2.1 or superstitious/made up issue you came up with.

    The primary goal/premise of the Microsoft feature has already been accepted, the only issue with the original patch was it not using the Linux graphics stack (the original patch used CUDA directly). This update fixes that.
    Last edited by mdedetrich; 14 January 2022, 09:57 PM.

    Leave a comment:


  • mSparks
    replied
    Originally posted by mdedetrich View Post

    And by definition this is not a non GPL module, try again. Microsoft is not putting the entire DirectX into the Linux kernel, this is just a translation layer for API which it in of itself is completely separate.
    GPL covers the entirety of what the patch does in its functional form, so requiring DirectX to function (even if it isnt bundled) makes the patch "non GPL", even if all the code in the patch itself is GPL.

    "spirit" of the GPL.

    You cant just stick a small non functioning patch into the kernel if it doesn't work without non GPLv2 modules. Numerous examples of these getting rejected over the years. No amount of refactoring will change that unless the patch can be made useful in and of itself.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by mSparks View Post

    Not talking about the licence, we're talking about kernel policy.
    Since at least 2006 it has been kernel policy to not mainline non GPLv2 compliant patches

    "Linus rejects the idea of non GPL kernel modules" December 15, 2006

    "After January 1, 2008, the Linux kernel will no longer allow non-GPL modules to be linked in. To be clear, this applies to all kernels released after that date and your existing modules won’t come to a screaming halt. Prime examples of non-GPL modules are the proprietary nVidia and ATI graphics drivers."
    And by definition this is not a non GPL module, try again. Microsoft is not putting the entire DirectX into the Linux kernel, this is just a translation layer for API which it in of itself is completely separate.

    Leave a comment:


  • mSparks
    replied
    Originally posted by mdedetrich View Post

    Thats not how GPL 2.1 works, read the license. GPL only cares about derivative works, not if something "requires" something else. DirectX is not considered a derivative work if DXGKRNL is included in the Kernel, so your point is completely invalid and incorrect.

    As stated previously, Hyper-V (which is a microsoft virtualization product) whos implementation in Windows is proprietary also contains a translation layer in the kernel. Thats because the implementation of Hyper-V in Windows is not a derivative work of the Linux kernel.

    The main reason/s why the original path was refused had nothing to do with the DirectX part of it but rather it was implemented using closed source CUDA instead of the open source graphics stack in the Linux kernel which Microsoft rectified with this recent patch.
    Not talking about the licence, we're talking about kernel policy.
    Since at least 2006 it has been kernel policy to not mainline non GPLv2 compliant patches

    "Linus rejects the idea of non GPL kernel modules" December 15, 2006

    "After January 1, 2008, the Linux kernel will no longer allow non-GPL modules to be linked in. To be clear, this applies to all kernels released after that date and your existing modules won’t come to a screaming halt. Prime examples of non-GPL modules are the proprietary nVidia and ATI graphics drivers."

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by mSparks View Post

    The points are

    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

    Which point do you disagree with?
    Thats not how GPL 2.1 works, read the license. GPL only cares about derivative works, not if something "requires" something else. DirectX is not considered a derivative work if DXGKRNL is included in the Kernel, so your point is completely invalid and incorrect.

    As stated previously, Hyper-V (which is a microsoft virtualization product) whos implementation in Windows is proprietary also contains a translation layer in the kernel. Thats because the implementation of Hyper-V in Windows is not a derivative work of the Linux kernel.

    The main reason/s why the original path was refused had nothing to do with the DirectX part of it but rather it was implemented using closed source CUDA instead of the open source graphics stack in the Linux kernel which Microsoft rectified with this recent patch.

    Leave a comment:


  • mSparks
    replied
    Originally posted by Quackdoc View Post

    the entire point, is that it isn't how it works, the kernel dev's don't care about you or I, they care about the linux itself, and this will make it better on hyper-v servers
    The points are

    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

    Which point(s) do you disagree with?
    Last edited by mSparks; 14 January 2022, 09:29 PM.

    Leave a comment:

Working...
X