Originally posted by mdedetrich
View Post
Announcement
Collapse
No announcement yet.
Microsoft Reworks The "DXGKRNL" Driver It Wants To Get Into The Linux Kernel
Collapse
X
-
-
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.
Leave a 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.
Leave a 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
- Likes 1
Leave a 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
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:
-
Originally posted by mSparks View PostAbsolutely 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.
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:
-
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.
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_.
Leave a comment:
-
Originally posted by mSparks View Post
GPL doesn't mean that others have to accept your original work.
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.
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.
Originally posted by mSparks View Postone of us doesn't - dont think its me
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.
Originally posted by mSparks View Postwhat 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.
Leave a comment:
-
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.
Good job directx is already open source or all that work would have been for nothing. lol.
Leave a comment:
-
Originally posted by mSparks View PostIt will also be rejected for relying on any directx component.
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.
- Likes 1
Leave a comment:
Leave a comment: