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). One reason to use bmk_core is convenience: I might be able to use rump_sys_write instead of bmk_printf or rump_sys_mmap (or something else) instead of bmk_memalloc, but it gets cumbersome quick. Yes, I know it's ironic that I remove libc and then immediately complain that invoking syscalls directly is too annoying ;) But I think there is still a use case for debugging, although for debugging the interface might not ought to be completely stable. But there's also a valid case for bmk_sched_*, since this is not provided through the rump kernel. You don't want to have two thread schedulers around, e.g. if a rump syscall blocks, you might want to run a client code thread in the meantime (which is the case if client threads are bmk_sched threads). A preemptive scheduler could circumvent this, but still seems less than ideal to me. One might make the same argument for bmk_memalloc, that you don't want to have two different memory allocators. In my project, I also have a custom rump driver component, which does some low-level I/O that depends on the platform code (e.g. for interrupts). I think the right approach here is to have small platform specific wrapper libraries in-tree that provide a stable interface, i.e. a similar approach to the already existing rumppci hypercalls. No need to expose anything directly from the platform/ directory. Cheers, Sebastian
