(Full disclosure: I'm one of the researchers working on DIOS and first author on the linked paper above.)

Agreed -- the reliance on Linux is definitely something that we've found to be a mixed blessing.

We actually looked fairly seriously into other candidate OSes as starting points for building DIOS. We considered L4::Fiasco, xv6 and Barrelfish, and investigated Barrelfish in depth. (L4 and xv6, at least at the time, were available for 32-bit only, which clearly wasn't going to cut it for a warehouse-scale OS.) Ultimately, we went with Linux over Barrelfish due to the more comprehensive driver support, better documentation and the fact that it works on our test machines.

Barrelfish had great trouble booting on one of our machines with a lot of physical memory; after patching it, we managed to boot it, but did not have PCIe devices available (required for networking). To their credit, the Barrelfish team were very supportive, but progress was slow and working with Linux allowed us to get started right away.

However, using Linux has also bought us into a bunch of annoying non-scalable implementation choices. For example, DIOS relies on fast memory mapping, but Linux serializes all access to the mm_struct for a process using a single semaphore.

That said, DIOS is (deliberately) written in such a way that it should be possible to port it to other host kernels. Specifically, the kernel code consists of three parts: 1. a small patch to route the new system calls to handlers; 2. a BSD-licensed core module that contains the DIOS logic, but which is implemented in standard ANSI C and does not rely on any Linux-specific kernel features; 3. a GPL-licensed "DIOS abstraction layer" (DAL), which offers access to the Linux kernel facilities for process and memory management, VFS calls, etc.

While our current prototype is for Linux only, we intend to revisit the Barrelfish port and will also look into porting DIOS to a BSD OS in the future. Barrelfish especially should be interesting -- it's a very good fit for DIOS's abstractions.

Thanks for the reply!

As someone involved in computing research (sometimes OS kernel research, even) I can appreciate the need to actually get something going.

Ideally, if I was starting off a project with the intent of focusing on something like distributed data management, I'd want to sit down and figure out what I actually need and write a kernel to do that, rather than pulling in Linux with its DECnet drivers and 300+ system calls and what-not. Maybe a Unix-like system with POSIX calls isn't the best way to approach the problem. The problem is that you end up spending a lot of time dicking around with the scheduler and figuring out why memory allocation sometimes screws up, and less time implementing the real deal.

I've had good experiences working with a 64-bit Plan 9 kernel, since I was already familiar with the code and it was quite minimal, but I still ended up fighting the compatibility/driver crap you mentioned. It's also pretty easy to get functionality, but getting functionality and performance is a pain.