This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]