4 ms·

I have been following unikernel development for sometime. The work done by Atti Kantee and others on Rumpkernels [1] is most promising and has the right abstrac

by crudbug 11y ago

I have been following unikernel development for sometime. The work done by Atti Kantee and others on Rumpkernels [1] is most promising and has the right abstractions (POSIX userspace using NetBSD stack). Also, in the demo video, unikernel folks should acknowledge rumpkernel work as they are using it :) [1] http://rumpkernel.org http://rumpkernel.org

anttiok 11y ago
I sort of agree with you and I sort of don't. For example, I think an interesting future path for the Rumprun unikernel (which, I always stress, is not the same thing as a rump kernel) is running without the POSIX-y userspace interfaces. In fact, that's pretty much where I think e.g. Golang support for Rumprun should go, i.e. remove the userspace abstractions from the stack, since they, conceptually, do exactly nothing. Parts of the implementation of Rumprun are wrong, because I didn't previously see the importance of no-userspace, but I'm slowly converting those. (ironically, Rumprun -- before the codebase was even called Rumprun -- started out as no-userspace, and then grew too much userspace ... but that's really another story) (edit added later so that we get credit going where it's due: It occurred to me that it was Sebastian Wicki who was campaigning for the no-userspace mode last summer as part of his lowRISC project, and did the initial work to be able to again use Rumprun without "userspace". Apparently my memory of events goes only a few weeks back if I don't think about things carefully ...) Now, if I'm allowed to summarize rump kernels, I'd say the goal is to build a framework which incorporates enough of the past to allow things to work, but tries to be as flexible as possible so as to enable the future. I'm a firm believer in "there's no such thing as #1", which means you shouldn't produce software components which work only in one type of tool, because it's easy to foresee that right around the corner you'll have to build components for the next tool. p.s. "Atti"? That one was new, usually it's "Antii" or something like that ;) ;)
- crudbug 11y ago
  Appreciate your take on this "Antii" ;)
- crudbug 11y ago
  From the comment: Having everything in-kernel (single memory space) with POSIX-y API for applications the right direction ? or I just brain farted here ?
  - anttiok 11y ago
    Assuming that was directed at me, what's "the comment"? Anyway, that's the right direction if that's what you want you want to accomplish. Otherwise it's the wrong direction. sincerely, anti
crudbug 11y ago
Excellent post about this - http://thenewstack.io/dockers-unikernel-purchase-changing-role-os/ http://thenewstack.io/dockers-unikernel-purchase-changing-ro...
pjmlp 11y ago
Why should I care at all about POSIX when not using C or porting UNIX software? POSIX is just the part of UNIX that should have been part of the C runtime, but instead they made it into an optional standard. Almost ever other programming language with richer runtimes don't have any need to depend on POSIX. All their APIs for creating processes, threads, accessing file systems, communicating over the network aren't POSIX dependent.

by crudbug 11y ago

anttiok 11y ago

I sort of agree with you and I sort of don't. For example, I think an interesting future path for the Rumprun unikernel (which, I always stress, is not the same thing as a rump kernel) is running without the POSIX-y userspace interfaces. In fact, that's pretty much where I think e.g. Golang support for Rumprun should go, i.e. remove the userspace abstractions from the stack, since they, conceptually, do exactly nothing. Parts of the implementation of Rumprun are wrong, because I didn't previously see the importance of no-userspace, but I'm slowly converting those. (ironically, Rumprun -- before the codebase was even called Rumprun -- started out as no-userspace, and then grew too much userspace ... but that's really another story) (edit added later so that we get credit going where it's due: It occurred to me that it was Sebastian Wicki who was campaigning for the no-userspace mode last summer as part of his lowRISC project, and did the initial work to be able to again use Rumprun without "userspace". Apparently my memory of events goes only a few weeks back if I don't think about things carefully ...) Now, if I'm allowed to summarize rump kernels, I'd say the goal is to build a framework which incorporates enough of the past to allow things to work, but tries to be as flexible as possible so as to enable the future. I'm a firm believer in "there's no such thing as #1", which means you shouldn't produce software components which work only in one type of tool, because it's easy to foresee that right around the corner you'll have to build components for the next tool. p.s. "Atti"? That one was new, usually it's "Antii" or something like that ;) ;)

crudbug 11y ago
Appreciate your take on this "Antii" ;)
crudbug 11y ago
From the comment: Having everything in-kernel (single memory space) with POSIX-y API for applications the right direction ? or I just brain farted here ?
- anttiok 11y ago
  Assuming that was directed at me, what's "the comment"? Anyway, that's the right direction if that's what you want you want to accomplish. Otherwise it's the wrong direction. sincerely, anti

crudbug 11y ago

Excellent post about this - http://thenewstack.io/dockers-unikernel-purchase-changing-role-os/ http://thenewstack.io/dockers-unikernel-purchase-changing-ro...

pjmlp 11y ago

Why should I care at all about POSIX when not using C or porting UNIX software? POSIX is just the part of UNIX that should have been part of the C runtime, but instead they made it into an optional standard. Almost ever other programming language with richer runtimes don't have any need to depend on POSIX. All their APIs for creating processes, threads, accessing file systems, communicating over the network aren't POSIX dependent.