4 ms·

You can do what Rump kernels do: write a shim layer. The linux/netbsd drivers think they are talking to their host kernel, when in reality they are talking to

You can do what Rump kernels do: write a shim layer. The linux/netbsd drivers think they are talking to their host kernel, when in reality they are talking to a shim that translates linux syscalls into the equivalent "RustOS" syscalls. Or you could just implement the linux syscalls directly in the kernel, but that seems a bit self-defeating if you want to explore new ideas.

drzaiusapelord 11y ago
Is this feasible for a production server or just POC? Its worrying to think of a layer between the OS and its video driver, raid controller driver, sound driver, network driver, etc. Any real decrease in performance or stability will be a non-starter for most.
- polyfractal 11y ago
  Well, that's how all the NetBSD rump drivers work. IIUC, a while back they refactored all the drivers to interact with the NetBSD kernel through the Rump interface. Which means that all the drivers can work in a traditional monolithic kernel, or can be extracted and used piecemeal in your own kernel, or compiled directly into the application as a unikernel. Checkout http://rumpkernel.org/ http://rumpkernel.org/ for more info. I dunno about performance impact, but I bet it is fairly negligible in the grand scheme of things. In the rump kernel case, these shims really don't do anything, they just pass the call through. Think of it as an API facade. In a hobby OS it might be heavier, if your OS doesn't have a 1:1 mapping of the POSIX/linux syscall to an equivalent. Also, we virtualize this stuff all the time in cloud environments. Your java app uses the JVM to execute a linux syscall which the kernel translates into a Xen hypercall which Xen uses to call a native driver which talks to the disk, etc etc. You obviously do pay a performance penalty for stacking more and more layers, but it isn't as bad as you'd think (or as good as you hope, take your pick). But the point is that layering abstractions like this is very much alive and tolerated today in moderately high performance systems :)
bluejekyll 11y ago
The reason this seems valid, is that it takes a long time to get the full system of device drivers you need to run on anything more than just a single platform. Just seems like a good starting point than reworking the entire world. Also, on the question of "how" you'd do this, I'm not a kernel hacker, but I thought it would be possible to expose FFI, i.e. the shim you talk about, that would allow drivers to be used from something like NetBSD. But you're right that it could be self-defeating in that supporting all of those interfaces might end up constraining the OS in it's attempt to deliver on these features. On a side note, it seems like it would be nice to expose POSIX FFI hooks to make porting software to a Rust OS easier.
- polyfractal 11y ago
  Agreed, that's why I personally like the rump kernel idea. Pick and choose the various NetBSD drivers that you need, automatically gain battle-tested drivers for a wide variety of devices. Bonus points that they are POSIX-compliant which helps with porting code.
steveklabnik 11y ago
Rumprun already has Rust support.

drzaiusapelord 11y ago

Is this feasible for a production server or just POC? Its worrying to think of a layer between the OS and its video driver, raid controller driver, sound driver, network driver, etc. Any real decrease in performance or stability will be a non-starter for most.

polyfractal 11y ago
Well, that's how all the NetBSD rump drivers work. IIUC, a while back they refactored all the drivers to interact with the NetBSD kernel through the Rump interface. Which means that all the drivers can work in a traditional monolithic kernel, or can be extracted and used piecemeal in your own kernel, or compiled directly into the application as a unikernel. Checkout http://rumpkernel.org/ http://rumpkernel.org/ for more info. I dunno about performance impact, but I bet it is fairly negligible in the grand scheme of things. In the rump kernel case, these shims really don't do anything, they just pass the call through. Think of it as an API facade. In a hobby OS it might be heavier, if your OS doesn't have a 1:1 mapping of the POSIX/linux syscall to an equivalent. Also, we virtualize this stuff all the time in cloud environments. Your java app uses the JVM to execute a linux syscall which the kernel translates into a Xen hypercall which Xen uses to call a native driver which talks to the disk, etc etc. You obviously do pay a performance penalty for stacking more and more layers, but it isn't as bad as you'd think (or as good as you hope, take your pick). But the point is that layering abstractions like this is very much alive and tolerated today in moderately high performance systems :)

bluejekyll 11y ago

The reason this seems valid, is that it takes a long time to get the full system of device drivers you need to run on anything more than just a single platform. Just seems like a good starting point than reworking the entire world. Also, on the question of "how" you'd do this, I'm not a kernel hacker, but I thought it would be possible to expose FFI, i.e. the shim you talk about, that would allow drivers to be used from something like NetBSD. But you're right that it could be self-defeating in that supporting all of those interfaces might end up constraining the OS in it's attempt to deliver on these features. On a side note, it seems like it would be nice to expose POSIX FFI hooks to make porting software to a Rust OS easier.

polyfractal 11y ago
Agreed, that's why I personally like the rump kernel idea. Pick and choose the various NetBSD drivers that you need, automatically gain battle-tested drivers for a wide variety of devices. Bonus points that they are POSIX-compliant which helps with porting code.

steveklabnik 11y ago

Rumprun already has Rust support.