Thank you. In the meantime I also noticed the following comment from Dave Airlie on LKML [1]:
> This is a driver that connects a binary blob interface in the Windows kernel drivers to a binary blob that you run inside a Linux guest. It's a binary transport between two binary pieces. [...] I can see why it might be nice to have this upstream, but I don't forsee any other Linux distributor ever enabling it or having to ship it, it's purely a WSL2 pipe.
It's not for the faint of heart or faint of technical skill - different drivers have different behaviors and ways to enter the various capture and raw packet modes needed to do this.
Personally, as long as I stick to supported chipsets, I've almost never had an issue.
No, since the linux kernel is GPL, as far as I understand, their must be some part of their driver that is also available in source form to interact with the kernel API. I haven't investigated this at all, but it feels like it may be possible to hook that. It's a terrible amount of work of course, but would be kinda fun to try. Perhaps an easier thing to try would be to run something like QEMU and have it forward activity on the PCIe bus over the network to a host system. Not sure if that's something people have done before.
Plus it also supports even lower level drivers for a bunch of cards (some are VM virtualised, such as the Intel em), as well as AF_PACKET, oh, and pcap.
There is not even need for a bifurcated driver. The upstream kernel has AF_XDP which Intel and Mellanox NICs support in their drivers, and DPDK has official integration for it as well: https://doc.dpdk.org/guides/nics/af_xdp.html This will make deploying DPDK significantly easier for those that need/want to use it and allows to share the same driver for pushing packets up to DPDK and into the normal kernel stack with very close to "native" (as in user space driver) DPDK performance (target is ~90-95%).
I'd love to know of SoC vendor that does. Intel and Wolfson are the only chip vendor that delivers above and beyond for Linux drivers that come to mind.
Everything else is hack city in proprietary kernel forks that never see the light of mainline.
Has anyone seen open source user space for this? I find the kernel really interesting.
I'm a fan of the way they put device drivers in user space, for example. But I'm curious if anyone has actually written a NIC driver for it. I'd like to take it for a spin and write some sample code, but I'm not sure if I can boot this thing with a network stack for my experiments to use.
The RealWoW stuff requires host cooperation to set the proper configuration fields. The card has very basic functionality to be pre-configured to respond to certain packets, but this needs to be set by the host - it is disabled by default and in fact the Linux driver doesn't even support it.
In addition if he could achieve code execution on the card it wouldn't matter whether the card has this functionality as he could implement it himself if needed.
They're working on it. The company behind C.H.I.P seems to be paying someone to develop drivers for it and get them into upstream Linux, including non-accelerated video drivers. A lot of the hardware on this era of Allwinner SoC actually already has support thanks to community efforts, too.
Should custom USB drivers like this be contributed to the kernel? I wanted to send mine upstream but reading the source code I got the impression user space drivers are preferred. Would appreciate some guidance.
reply