This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: system and popen fail in case of big application
On 13/09/2018 03:31, Andreas Schwab wrote:
> On Sep 12 2018, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
>
>> - vfork would be supported on Linux not because its a good interface,
>> but rather than Linux policy is to not broke userspace in any case.
>> And it would be supported only on architectures that already provide
>> it, new ports do not automatically export vfork and they are not
>> encouraged to do so. Currently ARC, alpha, s390, microblame, x86, sH,
>> powerpc, hexagen, parisc, m68k, arm, and aarch64 do so (and aarch64
>> only if compat mode is enabled, a 64-bit kernel only won't have vfork
>> syscall). For remaining arches, glibc will just use a clone plus
>> required flags (CLONE_VM | CLONE_VFORK | SIGCHLD).
>
> That doesn't make sense. CLONE_VFORK *is* vfork in all matters, and
> every architecture supports it. It's nothing different from the fact
> that there is no open syscall any more, because openat does the same
> (and more).
>
What I meant is the *wire up* syscall which is not automatically provided
anymore. Sure you can implement vfork with CLONE_VFORK and it is what glibc
does and will continue to do so unless we decide to remove it.