On 03.04.2018 16:57, Mouse wrote:
>> =46rom the GDB protocol point of view,
> ...what does gdb have to do with it? Did I miss something?
>
We need to track forks and its variations. Just a note that from the
existing protocol point of view, we can handle this new syscall.
signature.asc
Descri
> =46rom the GDB protocol point of view,
...what does gdb have to do with it? Did I miss something?
> I think there is needed prior verification of its stability and
> benchmarking before the final decision.
I would expect such work to be done before it goes into the main NetBSD
tree. What I h
>> [...] - "just use fork" is a very common response, but no matter how
>> fork gets implemented, vfork() when used correctly always performs
>> better by huge margins.
> But most of those cases are handled just as well by posix_spawn.
Possibly - but most of a system's operation is handled perfect
>> Basically, what I want is a syscall that a vfork()ed child can call
>> to have the unsharing effects of execve(2) or _exit(2) [...]
> I have considered (and think I mentioned on some list some time ago)
> the same capability to improve sh performance.
> [...]
> Having the mechanism available for
>> Basically, what I want is a syscall that a vfork()ed child can call
>> to have the unsharing effects of execve(2) or _exit(2) (return the
>> vmspace to the parent and let the it continue), while the child
>> carries on with a clone of the vmspace [...]
> That sounds suspiciously like Linux's uns
On Tue, Apr 03, 2018 at 09:08:15AM +0700, Robert Elz wrote:
> Kamil - "just use fork" is a very common response, but no matter how
> fork gets implemented, vfork() when used correctly always performs
> better by huge margins.
But most of those cases are handled just as well by posix_spawn. Which
d
On 03.04.2018 04:08, Robert Elz wrote:
> Kamil - "just use fork" is a very common response, but no matter how
> fork gets implemented, vfork() when used correctly always performs
> better by huge margins. You are of course correct that there is a very
> limited set of functions possible in a vfor
> 4GB of KVA; and in addition pmap_kernel will consume some KVA too. i386 for
> example has only 4GB of ram and 4GB of KVA, so we'll just never add a direct
> map there.
note that it changes your direct map point, but, i386 GENERIC_PAE
works fine for at least 16GB ram. it should work upto 64GB.
