nintyfan wrote:
Microsoft have planed to add support for multi-os drivers to UEFI.
It was more than a plan, and they have failed. Nobody uses EFI bytecode (except for some very specific appliance firmware or pre-boot malware maybe).
nintyfan wrote:
Why don't try this with LinuxBIOS and WASMI (or Linux -- the kernel -- and wasm). I known, currently someone tries to add WASM support to kernel, but I doubt it is addressed to writting device drivers.
Because device drivers are delicate things. There's often a need for precise timings, which you simply can't guarantee with bytecode (JIT or not). Also device drives are ALWAYS platform specific, so you'll never need a PIT driver on ARM, or a PL011 UART driver on x86 for example. The devices that can be used on several platforms and thus would benefit from such a device driver framework are so extremely rare, that such a framework simply doesn't worth the trouble.
nintyfan wrote:
There's one problem: device drivers are still prepared in C/C++ instead of WASM.
For the aforementioned reason. the key here is not C/C++ (a big deal of drivers are written in Assembly), but rather native code.
nintyfan wrote:
Mozilla and Microsoft is planned to create WASM interpreter, which supports POSIX/newer APIs. Is there any change to prepare API to write device drivers for multi-os purpose?
I think we need something like this:
1. WriteToVar(var_name, buffer, buffer_length)
2, ReadFromVar(var_name, buffer, buffer_length)
3. VarSize(var_name)
4. SwitchUserTo(user_id)
These have nothing to do with device drivers, these are just basic RAM access functions. And what does "SwitchUserTo" supposed to do? There's no such thing at kernel level, only tasks. Users (and particularly UID of a process) is in a higher abstraction layer.
nintyfan wrote:
Possible many others (API above is only to configure device). When there will exist WASM interpreter with POSIX support and GTK+/Qt bindings, we could allow to deliver very good user experience by hardware vendor.
Doubtful. First, there'll be no GTK/Qt binding in the kernel, and there shouldn't be. Those things are not supposed to run at supervisor level, nor should be called from supervisor level. Second, "we" could not allow anything about user experience, this would involve all the hardware vendors to implement their drivers using WASM. Running Emscpriten on a device driver's source won't be enough, that's for sure.
nintyfan wrote:
SwitchUserTo could been used to switching config of device dependent on current user or current VT.
What? This makes no sense. I think I get what you intended, but this is just not how driver configuration works.
nintyfan wrote:
Maybe just add API to query about available options, such like in CUPS/DBUS (and possible Mesa in future)? If yes, DE could create custom settings page.
Again, both CUPS and DBUS are so-so much higher level of abstractions than a kernel and device drivers.
I appreciate your idea, I really do, but the truth is, many have tried to create a uniform device driver stack, and so far all of those failed. I think the closest was UDI, but that's "just" at API level. The Linux drivers are mostly Open Source, but not all; and totally unusable to be encapsulated in a bytecode behind a stable API-bridge as the Linux API changes every week. So I think we're on our own for our hobby OS device drivers, don't hope you can "borrow" driver code from Linux.
Cheers,
bzt