I am pretty unhappy about drivers like this arriving in the tree. I just don't see any trustworthy way to use them, and lacking trust -- I don't understand the worth.
Givings hugs to trustworthy designs is an OpenBSD agenda. Giving scowls to untrustworthy designs is another OpenBSD agenda. Uplifting ones that are semi-trustworthy to become more trustworthy... well you get the idea. So this can run some semi-proprietary code that is uploaded and runs entirely unsafely. Why bother. How many people will use this, in OpenBSD? Besides you, I anticipate noone. The right way to use a device is through deep careful integration of the featureset it has, into natural functionality that can be exposed as a sane driver interface in /dev/, or hidden even further so that it does something which makes the kernel faster. Exposing anything like this raw, is not the unix way. I wonder what we'll see next, along this line. Maybe a way to load AML code from userland on an amd64, be interpreted by the AML interpreter to control fan speeds by twiddling bits in ACPI register spaces? Or a way to load DRM code directly? I think we can all agree those type of things are a much lesser form of "progress". Abstraction is a powerful uplift, raw is raw.
