Hi Daniel,
On Thursday, 21.03.2019 at 14:04, [email protected] wrote:
> > *Requiring* users to specify a separate stack size up front at run time
> > seems like exposing an unnecessary detail, not to mention that a lot of
> > people will not know what a reasonable value is.
>
> I don't think this is a real problem. For example the C stack also has some
> limit, pthread stacks have a smaller limit and people are aware of that.
> Solo5 could just use a similar value and allow people to increase if needed.
Sure, but we still need to arrive at some equation for determining a
sensible default stack size, while allowing for both small values of
"--mem" (e.g. 8MB, or even less?) and large values. Also, *who* sets the
stack size? The operator or the developer (unikernel provider)? See below
for why this matters.
> I am not sure about the "dynamic part". I would either set the stack from
> outside (as discussed above), or allow some kind of memconfig call, which
> can be executed only once after application startup.
> Alternatively you could provide munmap and munmap_done. Dynamic people would
> just never call munmap_done...
I think we can forget about multiple stacks for now. Having thought about
it, even having a single separate memory region for the stack is tricky
enough:
There are several models involved:
1. On "tendered" targets ('hvt', 'spt') the virtual memory layout is
set up "externally". So, the tender needs to know the (default | desired)
stack size at the time it's loading the ELF binary.
2. On 'virtio', there is no tender. You get X MB of "physical" memory, and
the *bindings* would need to split that up into separate regions during
early init code. Implies writing code to manipulate page tables, as those
are currently static.
3. On 'muen' I'm not actually sure who sets up the page tables, but AFAIK
it's also X MB of "physical" memory. Are the page tables fixed, or can the
guest set up its own? Adrian?
4. On 'genode' I have no idea :-) Emery?
In my mind the way to do this consistently for all targets is to make the
"desired stack size" a property attached to the *unikernel binary* and
initially set by the unikernel developer, with the libOS build system
determining the default. The *operator* should be able to override this.
By "property of the unikernel binary" I mean something that is
declarative(!) and forms part of a "manifest" that is embedded into the
binary as an ELF note.
I have a half-finished design for such a manifest in my notes, and it is
necessary for other things as well (multiple network interfaces). I can try
and write it up into a coherent document, but am leaving on vacation for a
couple of weeks late next week so can't promise it'll happen before then.
Martin
