system and popen fail in case of big application

Adhemerval Zanella adhemerval.zanella@linaro.org
Thu Sep 13 12:30:00 GMT 2018



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.



More information about the Libc-alpha mailing list