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

  • 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)
    https://www.cultofmac.com/162823/lin...y-macbook-air/

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

    Comment


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



      Comment


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

        Comment


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

          Comment


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

            Comment


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

              Comment


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

                Comment


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

                  Comment


                  • Originally posted by mSparks View Post

                    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.

                    Comment


                    • Originally posted by mdedetrich View Post

                      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.
                      Last edited by mSparks; 16 January 2022, 06:03 AM.

                      Comment

                      Working...
                      X