On Friday, 05.02.2016 at 13:59, Antti Kantee wrote:
> It's simple: things which should work in kernonly mode should be documented
> (now) and implemented (future) as such. Things which can't work in kernonly
> mode shouldn't work in kernonly mode.
I'm going to pass on the question of what (and how) should work in kernonly
mode for now and come back to it later, needs more thinking along with
"portability to other backends".
> >Unless I'm missing some NetBSD-specific uses of sysctl, sysctl is global,
> >am I right? Therefore I wouldn't expect users to need a per-"rc" sysctl
> >block.
> >
> >For rlimits, Off the top of my head, we could do something like this:
> >
> >"rc": [
> > {
> > "rlimit": {
> > "core": ...,
> > "cpu": ...,
> > "data": ...,
> > "nofile": ...,
> > }
> > }
> >]
I presume you're happy with the above suggestion for supporting rlimits?
> >
> >(The keys in "rlimit" would correspond to RLIMIT_XXX from setrlimit().)
>
> sysctl is global, but per-entity values are reachable from there.
> proc.<pid>.whatever is an example of such a case.
So, if we wanted to handle all cases (global and per-process), we'd want:
(per-process)
"rc": [
{
"netbsd":
{
"sysctl": {
"foo.bar": 1
}
}
}
}
]
and (top-level)
"netbsd": {
"sysctl": {
"baz.quux": 1
}
}
}
With the per-process version automatically prepending "proc.<getpid()>." to
the user-specified keys. I.e. the above would set "baz.quux = 1" globally,
and "proc.<getpid()>.foo.bar = 1" for the per-process entry.
I'm deliberately placing the "sysctl" object under a "netbsd" one to
account for the non-portable nature of sysctl().
> [argv[] defaulting to [bin] if not supplied]
>
> Agreed, but like I already wrote above, in the context of this discussion we
> still need to decide if it should be documented and therefore implemented.
Looking at the logic in handle_bin(), argv[0] coming from two possible
sources leads to a lot of if()s. Not sure if it's worth it. Will come back
to this.
> In a shell you cd and then you're there. So if you're running a shell
> pipeline (or sequence of ; or \n separated commands), you don't get the
> behaviour of pwd being $HOME for commands [2..n]. I'm not *sure* that's the
> correct thing to do in our case, but seems to be in supported by POLA at
> least per initial thinking.
The downside of a shell-like cd that I can see is that now an rc[] entry
can have side-effects which potentially alter the state of entries that
follow. This is problematic if you have a higher-level stack which wants to
(for example) add to an existing rc[] configuration.
> No, how can kernonly be an argument against *per-command* envs, but not
> global envs? If an argument doesn't make sense, there's something that
> either the producer or consumer of the argument has missed.
Sorry, I wasn't clear. I wouldn't expect either "env" block to work in
kernonly mode.
> The point is not to worry about solving non-immediate problems, it's
> avoiding painting ourselves in the corner.
>
> But, maybe in this case it's not a corner, we just add the env block to the
> per-program block later when the implementation supports it. The potential
> future behaviour of "per-program env overrides global env" seems sane
> enough.
Agreed.
> What's the argument for "extra visibility"? You certainly don't need to
> always set hostname explicitly, so where do we draw the line of adding
> individual top-level blocks for something that someone might want to set
> some day? Given that the hostname is already supplied by
> rumpuser_getparam(), can we improve that implementation instead?
POLA. I wouldn't go looking for a hostname setting in a "sysctl" block.
However, agreed that it doesn't necessarily belong in the top level. How
about we put it under "net"?
> >Don't know about portability to other backends -- again, relevant also to
> >Mirage/Rump hybrid unikernels and kernonly, need to think about it more. A
> >left-handed attempt for a portable sysctl block would be to put it under a
> >"netbsd" top-level block.
>
> Ok interested to hear what that thinking produces.
I'll be in Cambridge most of next week, so hope to make some progress on
this and discuss with Mirage folks.
