Microsoft Posts Updated "DXGKRNL" Linux Kernel Driver For WSL/WSA

[mSparks]

If that's who you think maintains the kernel you're in for a big surprise.

Just because a few shaved for the odd photo doesnt change who they are inside.

[sinepgib]

Anyway. Not me that needs convincing, its older more experienced stubborn dudes with beards that wouldnt install windows if you paid them.

If that's who you think maintains the kernel you're in for a big surprise.

[mSparks]

that wasn't them stating it needs to be iouring, or that it cannot be ioctl, simply that it would be better not to.

libdxcore is their umbrella for the interface, libdxg is an opensource alternative they made, dxcore is still needed for cuda and d3d12, but libdxg can be used for the open apis like intel's.

if it was as you said for implementation, the dev's are not stupid, they would not be entertaining the patch set. they have more valuble things, but they have been reviewing it, or do they just like wasting their time?

It says dont use ioctls or it will make a very hard sell harder.
It also says:

• The open-source userspace must not be a toy/test application, but the real thing. Specifically it needs to handle all the usual error and corner cases. These are often the places where new uAPI falls apart and hence essential to assess the fitness of a proposed interface.

That source you linked doesnt remotely come close to even a basic smell test of hitting the #1 requirement. And if it did then it would work on linux hosts.

If you think rejecting this one because it has 2019 in the copyright header is them "entertaining the patch set" then you are going to be very frustrated when they actually start commenting further down.

[Quackdoc]

Heres what they were told back in may 2020. including not to use ioctls
https://lists.freedesktop.org/archiv...ay/266642.html

None of this has been done afaict. still requires libdxcore (even says so in the latest patch notes) which is still closed source. So is the hardware specific part.

Anyway. Not me that needs convincing, its older more experienced stubborn dudes with beards that wouldnt install windows if you paid them.

If you think "you maintain hyperv from more than a decade ago so must do this even though its against your current policy and you hate it" will sway them, all I can say is "good luck with that".

that wasn't them stating it needs to be iouring, or that it cannot be ioctl, simply that it would be better not to.

libdxcore is their umbrella for the interface, libdxg is an opensource alternative they made, dxcore is still needed for cuda and d3d12, but libdxg can be used for the open apis like intel's.

if it was as you said for implementation, the dev's are not stupid, they would not be entertaining the patch set. they have more valuble things, but they have been reviewing it, or do they just like wasting their time?

[mSparks]

uh, no. they are still receiving and implementing hyper-v patches. they only care about linux side. as far as I am aware

Heres what they were told back in may 2020. including not to use ioctls
https://lists.freedesktop.org/archiv...ay/266642.html

None of this has been done afaict. still requires libdxcore (even says so in the latest patch notes) which is still closed source. So is the hardware specific part.

Anyway. Not me that needs convincing, its older more experienced stubborn dudes with beards that wouldnt install windows if you paid them.

If you think "you maintain hyperv from more than a decade ago so must do this even though its against your current policy and you hate it" will sway them, all I can say is "good luck with that".

[Quackdoc]

you said there was a full oss path. Since hyperv the kernel policy chaged to require a full oss path to upstream it.

Upstream will test it on linux hosts. They care exactly zero percent about any other hosts.

uh, no. they are still receiving and implementing hyper-v patches. they only care about linux side. as far as I am aware

[mSparks]

does any hyperv bit work on a linux host?

you said there was a full oss path. Since hyperv the kernel policy chaged to require a full oss path to upstream it.

Upstream will test it on linux hosts. They care exactly zero percent about any other hosts.

[Quackdoc]

so it works on linux hosts now?

does any hyperv bit work on a linux host?

[mSparks]

this provides necessary bits to talk to "compute device abstraction layer" it's stripped down, but you do not any longer need the full dxgcore for the kernel bits to function

so it works on linux hosts now?

[Quackdoc]

did you actually look at the src include folder?
Thats not libdxcore, its a wrapper for it.

this provides necessary bits to talk to "compute device abstraction layer" it's stripped down, but you do not any longer need the full dxgcore for the kernel bits to function