[quoting a number of mails. hopefully it's parseable]
On 26/01/16 13:25, Martin Lucina wrote:
## rc: Program invocation
Is this block intended to work in kernonly mode, or with userspace only?
"rc": [
{
"bin": <string>,
"argv": [ <string>, ... ],
"runmode": "" | "&" | "|"
},
...
]
One thing that Vincent brought up was rlimits. Should there be a sysctl
block in here, or should we call it rlimit? pwd that David mentioned is
similar. Are there any other per-process things? We don't have to
think of all of them this moment, but the more we think of them, the
more confident we can be in things being extensible in the future.
* _argv[]_: Argument list passed to program. At a minimum, a single string
is required, which will be passed to the program as _argv[0]_.
Would it make sense to default argv[] to binname if argv is not present?
I can see both pros and cons. How about if it's implemented but not
documented? (not that we need to worry about undocumented things in
this thread, but the question is more if we should document it)
On 26/01/16 19:09, Martin Lucina wrote:
Related question #1 that came up while working on this -- should I
implement rumprun-bake functionality to record/a tool to query the binaries
baked into a unikernel image? Without this information the user cannot
specify rc[].bin.
Probably, but it could be a more general tool displaying other
information too, such as bake configuration name and components
included. Not high priority (just remember what you baked ;), but anyway.
On 27/01/16 07:11, David Halls wrote:
In multi-bake images, there will likely be information other than just the
name required in order to run it. For example, how to chain them, what the
command line options are, what env vars it supports. I think the name
should be specified along with those, outside the image - in a free-text
description or some manifest format.
Well, you can do "ls /bin" even though you don't get the manpage of ps
that way.
On 27/01/16 10:41, Martin Lucina wrote:
Rumprun-bake could do that, I just hadn't done it in my initial
implementation since implementing "is this set of names unique" in bash is
a PITA.
The following should work:
ubins="${bins}"
_uniq ubins
[ "${bins}" = "${ubins}" ] || die not unique
(I guess _uniq could have a smarter calling convention to make that a
one-liner instead of a 3-liner PITA)
On 27/01/16 20:05, Barbu Paul - Gheorghe wrote:
In my opinion having the binaries run one after the other with just the
binary name passed in as argv would be a good default when no configuration is
given.
Great suggestion. Thank you!
On 28/01/16 10:17, Martin Lucina wrote:
"Working directory" is very much a setting, so yeah. However, we need to
account for a default otherwise a previous workdir would affect the next
invocation(s), so I propose:
"workdir": <string> (optional, default: "/")
This means that there's an implicit chdir("/") done before each invocation,
unless you specify a workdir.
Well, first of all, if you implement that approach sanely, you don't
need an "implicit chdir".
However, is that approach really the most natural way of thinking about
working directories? Why not make it behave like "cd" on a shell?
On 26/01/16 13:25, Martin Lucina wrote:
## env: Environment variables
Open issues:
- Justin Cormack mentioned that the "env" key should be made "per-process",
i.e. each "rc" entry should have it's own "env" subkey.
I don't this this is possible or desirable as:
a) The environment is a libc construct, so it's not applicable to e.g.
kernonly mode.
If that's an argument, why have the env block at all?
b) An "rc" invocation is not a "process" and as such does not have it's
own address space. The environment is a global construct in libc, thus
cannot be made "per-process" in rumprun without patching libc which we
want to minimize.
I don't think you definition of "process" matches mine.
As long the "global" environ *symbol* is reachable only from one
process, it should work just fine. Don't need a patched libc, just need
a libc per process. That's a good idea anyway for other globals like
stdio. I think it *should* work, but it's a different story what sort
of can of worms it might be. Only one way to find out. For extra
credit, shared text/rodata, which should also be possible without much
lost hair.
## hostname: Kernel hostname
"hostname": <string>
* _hostname_: Sets the hostname returned by the `gethostname()` call.
- Nothing controversial here ...
Does that need its own top-level entity? If we're adding a sysctl
block, you can just set kern.hostname there.
The only advantage I see is that if we ever get a non-NetBSD backend
(which I hope we do, though not holding by breath just yet), the above
representation is portable. However, I'm not convinced that the fs/net
blocks will be portable, so maybe it's not a goal worth shooting for.
General: are you updating the spec somewhere as the discussion
progresses? Since I took a few days, I'm not sure I commented on the
current proposal.
