Justus Winter <4win...@informatik.uni-hamburg.de> skribis: > 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.
Sorry, I’ve never head of cgroupfs; any pointers? Thanks, Ludo’.
