LinuxBIOS + WASMI

[nintyfan]

What about adding support for WASM to LinuxBIOS and allow to write device drivers in WASM? Microsoft have planed to add support for multi-os drivers to UEFI. 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.

Currently many devices are for USB, so potentially it could work on many hardware - we only need drivers. There's one problem: device drivers are still prepared in C/C++ instead of WASM. 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)
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.

SwitchUserTo could been used to switching config of device dependent on current user or current VT.

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.

[bzt]

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).

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.

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.

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.

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.

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.

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

[Octocontrabass]

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.

PCI devices are independent of the host CPU architecture. I know there isn't a lot of non-x86 consumer hardware with PCI slots ever since Apple discontinued the Power Mac, but it's a different story in the enterprise (server) world.

[nintyfan]

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.

You don't understood me. I think about something Intel promises to do with Mesa and CUPS have, so UI in WASM could use GTK+ or Qt and query device driver about variables (and some other things, such like type of variable).

SwitchUserTo could been used to switching config of device dependent on current user or current VT.

Ok. I realize that devices could have small amount of memory - better if os realizes switching user/terminals. It remembers key-value pair for each variable and update device memory, when switching. Probably it's currently done by kernel (I mean Linux, but maybe other kernels too) for graphics card.

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

Thanks.

[bzt]

PCI devices are independent of the host CPU architecture. I know there isn't a lot of non-x86 consumer hardware with PCI slots ever since Apple discontinued the Power Mac, but it's a different story in the enterprise (server) world.

You are right. I just wanted to say although in theory the same device could be used in different computers, in practice this is extremely uncommon, and platforms tend to have their own devices from different manufacturers. The demise of PPC Mac has a great part in this, no doubt. Btw, PPC Macs were never common in the enterprise server world, there the demise of Sparc is much more typical, but ultimately lead to the same result. I remember when I got my Sun Solaris Master Certificate, the server rooms were full of UltraSparcs, then Oracle put his little dirty hand on Sun, and Sparc machines disappeared completely This wasn't the first time btw, before that I got expert on VMS, and then DEC went out of business. Maybe it's time to get some Windows certificate for me?

UI in WASM could use GTK+ or Qt and query device driver about variables

This already works. All you need is a wrapper library to GTK/QT, and you can most definitely compile those with Emscripten, many have already done it. As for the device drivers, under Linux everything is a file, either under /dev, /proc or /sys. So to query ANY device driver variable all you need is standard file operations plus ioctl, which are already covered by WASI. Here's a tutorial on WASI. No need for WASM device drivers for this, besides, the file interface is much more stable than the internal Linux API. Also note that these UI can work from userspace, no need to run them with supervisor privileges.

Ok. I realize that devices could have small amount of memory - better if os realizes switching user/terminals. It remembers key-value pair for each variable and update device memory, when switching.

I'm sorry, but I really don't follow. You mean chvt and vtswitch? Please note that those has absolutely nothing to do with device drivers, they do not care about device memory or variables. They have nothing to do with graphic cards, or any other devices as a matter of fact, they operate on the tty level. You can use VTs regardless if you have an intel-fb, nvidia-fb etc. driver, doesn't matter. You could for example compile chvt's source with WASI right now, no need for WASM device drivers for that.

Cheers,
bzt

[Octocontrabass]

You are right. I just wanted to say although in theory the same device could be used in different computers, in practice this is extremely uncommon, and platforms tend to have their own devices from different manufacturers.

The company I work for uses the same PCIe devices in both x86 and non-x86 servers.

[bzt]

The company I work for uses the same PCIe devices in both x86 and non-x86 servers.

And? What is your point? "uncommon" != "impossible". And just to feed the troll, does your company use the same platform-independent bytecode drivers for those devices in all servers or each platform has its own native PCIe driver?

Cheers,
bzt

[Octocontrabass]

What is your point?

There's a market for it.

And just to feed the troll, does your company use the same platform-independent bytecode drivers for those devices in all servers or each platform has its own native PCIe driver?

Does the EFI bytecode driver in the option ROM count?