Re: Hacking gnumach to track parental relationship of tasks

[Justus Winter]

Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-06 11:58:43)
> Justus Winter <4winter@informatik.uni-hamburg.de> skribis:
> 
> > Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-05 18:11:43)
> >> Justus Winter <4winter@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