And now cgrouproot can live in /proc?

Posted Aug 4, 2014 14:55 UTC (Mon) by kloczek (guest, #6391)
In reply to: And now cgrouproot can live in /proc? by alison
Parent article: The unified control group hierarchy in 3.16

Originally procfs was about managing processes.
But you know .. Linux is now mature OS so it cannot change suddenly UAPI (despite that in Documentation directory still you can find document listing why Linux does not need stable KAPI/UAPI).
Linux has some kind of schizophrenia. In procfs you can find even some old attempts to try maintain not only processes and threads but groups of processes as well like /proc/<PID>/task/* but who cares that current attempt to catch up something which is working more than decade in other OSes is breaking something existing.
Cgroups development started at 2007. Who cares that after 7 years still is useless on providing very basic functionalities?
Let's give the chance new kernel developers generation to contribute to growing Linux kernel entropy .. isn't it?

And now cgrouproot can live in /proc?

Posted Aug 5, 2014 23:39 UTC (Tue) by nix (subscriber, #2304) [Link]

Um, /proc/$pid/task *is* how procfs provides information on threads. It's not 'groups of processes', it's groups of *kernel tasks*, i.e. schedulable entities: what POSIX calls threads. There is nothing in procfs to track groups of processes in any other sense (you can't even follow the pid -> ppid hierarchy via the directory hierarchy or via symlinks, you have to parse /proc/$pid/status).

You really don't know very much about Linux at this level, do you?