Hacker News Reader

Comment by st_goliath | Hacker News Reader

I'm a bit surprised the bulk of the comments here seem to fixate onto Go specifically, seemingly missing the actual point of the article:

The article demonstrates the Usermode Driver API, showing how a Linux driver can offload work into userspace (with or without access to a working filesystem).

I mentioned this yesterday in the context of the in-kernel codec discussion[1], where the questions "can't this be done in userspace" or "why not sandboxing" were dismissed pretty quickly.

[1] https://news.ycombinator.com/item?id=40174516#40184307

View on HN

It's a sophisticated bike shed. Much more of the population has a working knowledge of go than about the linux kernel's Usermode Driver API

...So what color is their gopher?

So why not Java? It has way more software written in it. :)

Their rationale for Go is explained in the article.

> Strictly speaking, any program will do, but we need to ensure that the program in question has no dependencies on the file system. Linking it statically provides benefits. Go programs are statically linked by default, and to illustrate that the following approach works with any kind of program, we have chosen to embed a Go program into the kernel.

Please refrain from inciting language flamewars.

More to the point, Sun did actually play with the idea of having Java in Solaris.

Android Things had drivers in Java, and Android has a few, although only as userspace.

There were also some Java CPUs, which directly executed bytecode, in which case a "Java driver" would just be the lowest, system-level language available: https://en.m.wikipedia.org/wiki/Java_processor

I recall stumbling across this years ago while working on a Solaris project - the possibility of writing drivers in Java.

It seemed so patently absurd at the time!

Exactly!. It can be written in any language, Cobol if you want, it does not matter. Once compiled the "gas" does the actual magic, not Go.

Reply on news.ycombinator.com