On Linux you could create a tun/tap device from your application and translate data sent over that to requests sent to the ethernet adapter.

Of course, when you're doing these things in userspace you either need some way of communicating with the Kernel or for the other subsystems to be in userspace as well.

▲

Neywiny 6 hours ago | parent [-]

Not to be too facetious but a great place for communicating with the kernel where there are a ton of other driver subsystems is... the kernel.

Possibly a good addition to the article would be parallel development of an lkm. I guess it wouldn't have that windows interop but I would also be interested to see how this driver would be implemented on Windows. If it's idk 10x as many lines in the kernel vs userspace, that's a great benefit to the userspace approach.

▲

pjc50 5 hours ago | parent | next [-]

Driver signing is a killer issue on Windows; if you put your machine into dev/unsigned mode you get an ugly banner that can't be turned off.

Much easier to design the device to avoid that. E.g. by abusing USB-HID. The desktop USB missile launcher toy is USB HID, for example.

	▲	kam a few seconds ago \| parent [-]
		No need to pretend to be HID. Windows has WinUSB for userspace USB drivers that don't need special signing.

▲

WerWolv 5 hours ago | parent | prev | next [-]

Arguably all these other subsystems shouldn't be in the Kernel either but that's a different topic :)

There are quite a few benefits to doing these things in userspace over the Kernel, not really necessarily just because of the code size:

- The code is much easier to write and debug, you just write code like you always would.

- Bugs don't have the possibility to taking down your entire system or introduce vulnerabilities

- Especially on Windows, everyone can do this without requiring an impossible to get driver signing certificate

	▲	fleahunter 5 hours ago \| parent [-]
		[dead]

▲

dist-epoch 5 hours ago | parent | prev [-]

In HFT user-space networking drivers have a long history - there is too much latency induced by switching from kernel to user space to handle networking.

> OpenOnload: A user-space network stack that intercepts socket calls to bypass the kernel network stack, accelerating standard socket operations for faster networking.

> Netmap: A framework providing a simple API for high-speed packet I/O in user space, bypassing much of the kernel overhead for efficient packet forwarding and filtering.

https://dysnix.com/blog/high-frequency-trading-infrastructur...