Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-05 18:11:43) >> Justus Winter <4win...@informatik.uni-hamburg.de> skribis: >> >> > I made two rather small and (as I thought) straight forward changes to >> > gnumach to keep track of a tasks father task and to make this >> > information available. >> >> Isn’t that what ‘proc_getpids’ is for?
[...] > And here lies the problem, this is a mere convention. Until a process > is reparented using proc_child its parent is pid 1. Currently it is > possible to start tasks (and thus 'processes') without marking them as > ones child. This is a problem for a robust cgroups implementation. Thanks for explaining, that’s the part I was missing. However, I’m not sure what problem this is solving (but I miss the bigger picture of your project, apologies for that.) The convention you describe is always honored for POSIX programs, since ‘fork’ always calls ‘proc_child’. And non-POSIX programs are outside of the scope, I suppose, no? >> It feels wrong to retrofit POSIX concepts in Mach. > > I do not consider tracking the creator of a task a POSIX concept, even > if POSIX does something very similar. That tracking is already done in user space. My understanding is that the rationale is to add to the kernel only features that could not possibly be implemented in user space. Thanks, Ludo’.
