bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hacking gnumach to track parental relationship of tasks


From: Ludovic Courtès
Subject: Re: Hacking gnumach to track parental relationship of tasks
Date: Sat, 07 Sep 2013 14:37:03 +0200
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Justus Winter <4winter@informatik.uni-hamburg.de> skribis:

> 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.

Sorry, I’ve never head of cgroupfs; any pointers?

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]