On 01/02/16 11:21, Martin Lucina wrote:
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?
It *should* work in kernonly mode, with the exception that if we end up
specifying a per-process "env" block for each "rc" entry, then that will
have to be emulated somehow.
Regarding kernonly mode in general, I've not really thought through what
facilities (including a config parser) should or should not be provided.
I'd be interested in knowing more about your plans and thoughts on this
(possibly for a different subthread?)
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.
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.
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": ...,
}
}
]
(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.
* _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)
What's the motivation for this? A "developer" shortcut to save typing?
There are already enough alternative behaviours in rc[] (e.g. when none is
passed at all), that I'd prefer not adding more. Having said that, argv[] =
[binname] is consitent with precisely the "no rc" case, so I have no strong
opinion either way.
I think that was the motivation, but I don't really remember what I was
thinking about last week. If I can't remember, odds are it wasn't very
important.
Regarding undocumented behaviour, I've deliberately written the following
text about undocumented behaviours into the spec:
Configuration interfaces and/or behaviours not documented here are
considered unofficial and experimental, and may be removed without
warning.
Therefore, in the context of this discussion, if we implement it then it
should be documented.
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.
However, is that approach really the most natural way of thinking about
working directories? Why not make it behave like "cd" on a shell?
Not sure what you mean by that, can you elaborate?
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.
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?
Because it's useful for a known case with many examples (existing
unmodified software which accepts e.g. verbosity / debug / other toggles
via the environment).
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.
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.
Reading the libc implementation (stdlib/_env.c), it's not just environ but
also all the other static symbols in that module. So, at the very least
we'd have to patch/provide a replacement _env.c to use __thread for its
static data, make sure that the right thing gets done whenever a new
process context is initialised *and* figure out how to do all that in a way
that's acceptable to upstream.
Like I wrote: "libc per process". You don't have to start patching
anything, just make sure the libc global data is reachable from only the
process in question. And that can be done by linking libc with the
program (instead of globally like we do now) and privatizing the symbols.
That seems like a bunch of work solving a problem I don't see an
immediate need for?
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.
## 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.
I'd keep hostname in the top-level for extra visibility, rather than
"hiding" it in a sysctl tree.
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?
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.
