And now cgrouproot can live in /proc?

Posted Jun 15, 2014 17:40 UTC (Sun) by alison (subscriber, #63752)
Parent article: The unified control group hierarchy in 3.16

What is the rationale for cgroups having their own mount in the first place? Assuredly cgroups are part of UAPI to the kernel, and as such they'd make more sense in /proc than /sys. With just one hierarchy, having cgroups in /proc would be more consistent with what's already there.

to post comments

And now cgrouproot can live in /proc?

Posted Aug 4, 2014 14:55 UTC (Mon) by kloczek (guest, #6391) [Link] (2 responses)

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 4, 2014 16:49 UTC (Mon) by dlang (guest, #313) [Link]

> despite that in Documentation directory still you can find document listing why Linux does not need stable KAPI/UAPI

that document says that the internal API of the kernel is not stable.

the User API to the kernel is very stable.

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?