On 04/09/15 12:34, Sebastian Wicki wrote:
2015-09-04 1:28 GMT+02:00 Antti Kantee <[email protected]>:
I'd still argue it's a unikernel, it's just not a unikernel with a POSIX API
towards the "application". But then again, Rumprun is almost the odd one in
the unikernel family for providing a POSIX API (which is now optional ;)
There's one important point to raise: which interfaces do you think are (or
should be) stable?
Besides the entry point (which I think should be stabilized), the only
#include-able library is libbmk_core (there might be other code in
Xen, I don't know).
[snip]
Sure, I can understand why the interfaces would be useful, which is why
I asked. After thinking about it for a while, I can guarantee that the
interfaces will be available in some form, but I think it's too early to
declare them stable. So, you might have to adjust your code to work
against newer versions at some future date. I don't really want to have
to start maintaining compat interfaces for something which is still
clearly unfinished, because that also restricts the thinking to
something which can be implemented in terms of the compat interfaces.
That said, the door swings both ways, and if you notice something where
the bmk interfaces don't provide what you need in an efficient form, we
can change the interfaces very easily.
Adding RISC-V support should help in convincing that the machine-facing
interfaces are good enough to be considered stable ;)
(I had to change a few things for ARM support to be sensible, so
interesting to see what RISC-V brings)
The unified memory allocator and support for "killing" applications (to
get them to shut down cleanly) are the two other thorns on my list of
things standing in the way of understanding enough about bmk to consider
its external interfaces stable.
