Okay folks. We have decided to give G+ pages a try as a blogging tool... We'll start by an article from Lord Glauber of Sealand on the subject of "What about C?". Enjoy

It's been almost a week since OSv has been officially released, and we are very excited about the reception and positive comments we have been seeing. Many people are asking questions, and we plan to answer them all in the next couple of weeks.

Today I want to start with one that is probably the one we have received the most: What is up with the Java thing? Can I run other runtimes? Can I run C?

The short answer is yes, you can. We aim to be as compliant with the Linux interface as we can, so in theory many Linux applications should be able to run unmodified. The main difference, obviously, is that by calling those Linux system calls you won't pay the full price of a system call. Because OSv runs everything in the same address space, it's just a function call away. We also have no users, and a single process. Therefore our implementation can be a lot simpler. Take for instance the following two examples from runtime.cc:

int getpid()
{
    return 0;
}

uid_t getuid()
{
    return 0;
}

So where are the caveats? First, there is one fundamental limitation: because we run everything in a single address space, we cannot run new processes, just new threads. This means we cannot call anything like fork() and vfork(). We currently don't implement clone(), although we could as long as we would error out on the right set of flags. But in any case, the most common interface for thread creation is pthread, and that is supported.

Secondly, we cannot run ELF executables, because, well, we cannot execute any other binaries other than "the one" we execute. So the way OSv execute things is by loading a shared library and jumping to its main() entry point. This means that your program needs to be at least recompiled to generate not an executable, but a shared library.

The last caveat is that the interface is not complete, although this is not only fixable, but will be fixed in the future. As a good example, links are not yet supported by our filesystem. So if your program needs to create links (either symbolic or hard), it probably won't run. We are working on this one but there may be others. If you hit a syscall that is not yet implemented by OSv, you will either receive an explicit error message that the call is not present, or an error message from the loader saying that the symbol isn't found.

We don't keep a list of missing syscalls because we are proudly moving quite fast. If you happen to hit something that isn't there, please report it to us together with the application you are trying to run. Or even better: send us patches. We would be delighted, and I will even pay you a beer if we ever meet in person. Just make sure to warn us beforehand so you don't start working on a duplicate effort.

So provided you are not doing any of the forbidden syscalls, porting your C app to OSv is very simple. Just make sure it is not doing any fork()s and exec()s, recompile it
with CFLAGS="-fPIC -shared" so to generate a shared library, and ... debug. Also, any shared libraries that you use as dependencies would have to be copied to the image.

So what is up with the Java thing? As explained above, C is doable, but not convenient or easy. Java basically allows us to have a stable interface for deploying applications to OSv. They don't have to be changed at all, they don't need to be recompiled, and the interface can be fully supported. The eventual native calls through JNI can be reasonably isolated and - as long as it is not fork()/exec() - is easily supportable without any change. We also foresee a very good path in the future by allowing the JVM to merge a bit more with the OS. By running it in Kernel Space, we can allow the JVM access to facilities such as the page table, more control over used memory and even drive the process of garbage collecting in a more efficient way.

Another advantage is that while an unbounded memory access in a C application would crash your VM (in a normal OS it would crash your app, but for us your app and your VM are pretty much the same. So no, we are not less secure because of that), the JRE can catch those accesses and at least fail gracefully, or in most cases throw exceptions and allow your application to recover. Obviously, Java is not the only runtime out there that can display such properties. It is just one that is commonly deployed in the Cloud in important applications and fits our model quite nicely. We ourselves don't plan to support another runtime, but we would be more than happy to review your patches.

Keep sending your questions, and we'll do our best to answer them
Shared publiclyView activity