[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hacking gnumach to track parental relationship of tasks
From: |
Justus Winter |
Subject: |
Re: Hacking gnumach to track parental relationship of tasks |
Date: |
Fri, 06 Sep 2013 14:12:24 +0200 |
User-agent: |
alot/0.3.4 |
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
- Hacking gnumach to track parental relationship of tasks, Justus Winter, 2013/09/05
- [PATCH 1/2] kern: track the parent of a task, Justus Winter, 2013/09/05
- [PATCH 2/2] kern: make the parent of a task available via task_info, Justus Winter, 2013/09/05
- Re: Hacking gnumach to track parental relationship of tasks, Ludovic Courtès, 2013/09/05
- Re: Hacking gnumach to track parental relationship of tasks, Justus Winter, 2013/09/06
- Re: Hacking gnumach to track parental relationship of tasks, Ludovic Courtès, 2013/09/06
- Re: Hacking gnumach to track parental relationship of tasks,
Justus Winter <=
- Re: Hacking gnumach to track parental relationship of tasks, Ludovic Courtès, 2013/09/07
- Re: Hacking gnumach to track parental relationship of tasks, Justus Winter, 2013/09/07
- Re: Hacking gnumach to track parental relationship of tasks, Ludovic Courtès, 2013/09/07
- Re: Hacking gnumach to track parental relationship of tasks, Samuel Thibault, 2013/09/09
- Re: Hacking gnumach to track parental relationship of tasks, Ludovic Courtès, 2013/09/09
- Re: Hacking gnumach to track parental relationship of tasks, Samuel Thibault, 2013/09/09
- Re: Hacking gnumach to track parental relationship of tasks, Justus Winter, 2013/09/10
- Re: Hacking gnumach to track parental relationship of tasks, Ludovic Courtès, 2013/09/10
- Re: Hacking gnumach to track parental relationship of tasks, Justus Winter, 2013/09/11
- Re: Hacking gnumach to track parental relationship of tasks, Ludovic Courtès, 2013/09/11