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 mdedetrich View Post

    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".

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by mSparks View Post

    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.

    Leave a comment:


  • mSparks
    replied
    Originally posted by mdedetrich View Post

    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.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by mSparks View Post


    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.

    Leave a comment:


  • mSparks
    replied
    Originally posted by sinepgib View Post

    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

    Originally posted by mSparks View Post

    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
    Last edited by mSparks; 15 January 2022, 03:48 PM.

    Leave a comment:


  • sinepgib
    replied
    Originally posted by mSparks View Post
    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.

    Leave a comment:


  • mSparks
    replied
    Originally posted by sinepgib View Post


    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.

    Originally posted by sinepgib View Post

    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.



    Leave a comment:


  • sinepgib
    replied
    Originally posted by mSparks View Post

    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.

    Originally posted by mSparks View Post

    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.

    Originally posted by mSparks View Post

    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.

    Originally posted by mSparks View Post
    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 :^)

    Originally posted by mSparks View Post

    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

    Originally posted by mSparks View Post
    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)
    Linus Torvalds is not a huge fan of Apple products. He is, as he describes himself, a socks and sandal kind of guy, a tinkerer. Even so, the Linux creator


    Originally posted by mSparks View Post

    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_.

    Leave a comment:


  • mSparks
    replied
    Originally posted by Quackdoc View Post

    it no longer relies on upon closed-source CUDA and DirectX user-space

    the issue was never that it was directx, it was that it needed closed source components to function, all components needed are either open sourced, or now optional. I don't know whats so hard to comprehend about that.

    the necessary directx component libdxcore was open sourced. as was already stated, partially, but enough to function without libdxcore. the non opensource component is now optional.
    As long as that newly open sourced userspace component does not rely on any closed source components then there wont be a problem. If it does it wont get mainlined for the same reasons it was rejected last time. They dont accept patches that rely on closed source modules, drivers and recently even applications.

    Good job directx is already open source or all that work would have been for nothing. lol.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by mSparks View Post
    It will also be rejected for relying on any directx component.
    it no longer relies on upon closed-source CUDA and DirectX user-space

    the issue was never that it was directx, it was that it needed closed source components to function, all components needed are either open sourced, or now optional. I don't know whats so hard to comprehend about that.

    the necessary directx component libdxcore was open sourced. as was already stated, partially, but enough to function without libdxcore. the non opensource component is now optional.

    Leave a comment:

Working...
X