Split posix_spawn.c into 3 different files

Split posix_spawn.c into 3 different files

posix_spawnattr.c
posix_spawn_file_actions.c
posix_spawn.c

Also, move the declarations of the posix_spawn types
into spawn.h.

These two changes combined allow alternative
implementations of posix_spawn to be provided without
duplicating the posix_spawnattr* and
posix_spawn_file_actions* functions.

BUG= https://code.google.com/p/nativeclient/issues/detail?id=3976
R=phosek@chromium.org

Committed: https://git.chromium.org/gitweb?p=native_client/nacl-newlib.git;a=commit;h=bf66148d14c7fca26b9198dd5dc81e743893bb66

[Sam Clegg, 2014-10-13 21:16:33]

sbc@chromium.org changed reviewers:
+ phosek@chromium.org

[Petr Hosek, 2014-10-14 00:38:27]

On 2014/10/13 21:16:34, Sam Clegg wrote:

LGTM; do you plan to upstream these changes to newlib?

[Sam Clegg, 2014-10-14 00:42:39]

On 2014/10/14 00:38:27, Petr Hosek wrote:
> On 2014/10/13 21:16:34, Sam Clegg wrote:
> 
> LGTM; do you plan to upstream these changes to newlib?

I would hope to yes.  It would be among the patches that we should consider for
upstreaming but so far little effort has been put into that (AFAICT).


I was interested to see that you were the original author of this code.  Can I
ask what you were working you when you were doing this?  (what was the
objective?, something with NaCl?)

[Sam Clegg, 2014-10-14 00:43:40]

On 2014/10/14 00:42:39, Sam Clegg wrote:
> On 2014/10/14 00:38:27, Petr Hosek wrote:
> > On 2014/10/13 21:16:34, Sam Clegg wrote:
> > 
> > LGTM; do you plan to upstream these changes to newlib?
> 
> I would hope to yes.  It would be among the patches that we should consider
for
> upstreaming but so far little effort has been put into that (AFAICT).
> 
> 
> I was interested to see that you were the original author of this code.  Can I
> ask what you were working you when you were doing this?  (what was the
> objective?, something with NaCl?)

Also, are you OK with be removing the interaction for the struct types and
putting them in the public header?  Was there any particular reason you were
trying to hide them?

Also, looking forward to see you soon in there US!

[Petr Hosek, 2014-10-14 01:16:54]

On 2014/10/14 00:43:40, Sam Clegg wrote:
> On 2014/10/14 00:42:39, Sam Clegg wrote:
> > On 2014/10/14 00:38:27, Petr Hosek wrote:
> > > On 2014/10/13 21:16:34, Sam Clegg wrote:
> > > 
> > > LGTM; do you plan to upstream these changes to newlib?
> > 
> > I would hope to yes.  It would be among the patches that we should consider
> for
> > upstreaming but so far little effort has been put into that (AFAICT).
> > 
> > 
> > I was interested to see that you were the original author of this code.  Can
I
> > ask what you were working you when you were doing this?  (what was the
> > objective?, something with NaCl?)

The goal was to provide "proper" process support in NaCl. KernelService already
allows creating new processes, but this functionality is not yet exposed to the
untrusted code AFAIK (see
https://chromium.googlesource.com/native_client/src/native_client.git/+/maste...).
The vision I (and Bennet) had was to provide the process IRT interface (the
preliminary code for this is at https://codereview.chromium.org/24908002/) which
would include posix_spawn method (that's why I wrote the patch for Newlib). This
interface would be unimplemented by default, but it could be implemented by a
untrusted library as a layer in the stackable IRT (some preliminary code for
that is here https://codereview.chromium.org/25027006/). The last part which
binds everything together is nacl_init (started here
https://codereview.chromium.org/25147002/) which would implement the process IRT
interface as a stackable IRT layer using KernelService and would handle things
such as pid management and signal delivery (we were planning to re-use the app
channel for that purpose). NaCl apps which would require process support would
link/load nacl_init akin to nacl_io.

Unfortunately, the code was lying dormant since last summer. I was hoping to
work on this in spare time, but my studies kept me pretty busy. I'd be happy to
start working on this again when I join the team, but I'm not sure how well it
would fit into the current plans.

> Also, are you OK with be removing the interaction for the struct types and
> putting them in the public header?  Was there any particular reason you were
> trying to hide them?

Both the header and the implementation came from FreeBSD, I just modified them
to adhere to the Newlib style (the related thread in Newlib mailing list is
https://sourceware.org/ml/newlib/2013/msg00706.html). This is fine with me, but
I cannot speak for Newlib maintainers. 

> Also, looking forward to see you soon in there US!

I'm looking forward to join the team (again).

[Sam Clegg, 2014-10-15 00:13:15]

Committed patchset #1 (id:1) manually as
bf66148d14c7fca26b9198dd5dc81e743893bb66 (presubmit successful).