Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-06 11:58:43) > 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?
If any program can evade the cgroup mechanism by using task_create there is no point to implement cgroupfs. > >> 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. Yes, but it cannot be done in a robust/secure way. And I do consider the current use of proc_child rather questionable, though it could be modified to reparent processes for debugging purposes. Justus
