On Mon, Feb 02, 2009 at 04:54:58PM -0600, Chris Friesen wrote: > Thadeu Lima de Souza Cascardo wrote: > >> Linux Documentation is not consistent and have some funny options. In >> Documentation/cgroups/*, we have: > >> So, we have some more options now: /cgroups, /containers, /dev/cpuset, >> /dev/cpuctl, /opt/cgroup, /opt/cpuset. >> >> I am copying the container and the kernel guys. Perhaps, we can find an >> agreement (if we want to find one at all) and change all that >> Documentation to get consistent. > > I'd vote for "cgroups" or "containers", mounted at / or /sys/. > > /opt feels more like where software should live, and /dev should be for > devices rather than capabilities/management. "cpuctl" and "cpuset" are > subsets of the full capabilities of cgroups, so they're suboptimal as > far as naming. > > Chris
Since the original post didn't go to lkml or lxc, here it is. Sorry d-d, but I want to keep it in the loop. And I agree with Chris in regards that cpuctl and cpuset are not only what is provided under a cgroup mountpoint, so they are not very good options. I prefer cgroup over container, and I prefer the singular. However, I'd rather not see this in /sys/ for the reason stated below. But since we may end up agreeing on this with the kernel people, we would be safe not to clash with a /sys/cgroup. But I see no problems with /dev/cgroup/ but would also be glad to see /cgroup/ as the choice. -- Hello, Some software I intend to package work with the new cgroup feature in Linux. I would like to open a discussion about what would be the better place to mount it and how/when to mount it. Some of the options are: /sys/cgroup /proc/cgroup These two would not be very wise, since some kernel change may create those two, and, then, we would hide them, at least. /proc/cgroups, for example, is already there. /cgroup The FHS says why we should not create a new subdirectory in the root filesystem: 1) "It demands space on a root partition which the system administrator may want kept small and simple for either performance or security reasons." This does not apply here, since we do not require any storage for /cgroup, but for the directory entry itself. 2) "It evades whatever discipline the system administrator may have set up for distributing standard file hierarchies across mountable volumes." Since /cgroup is totally local, I can't see why this will evade anything. procfs and sysfs are in the root filesystem too. So why not put /cgroup there? /dev/cgroup Many people have been using this. FHS says this "is the location for special and device files." What is not special about cgroup anyway? After deciding where to mount it, we may write some code for some of the init scripts to mount it. I think mountkernfs.sh may be a good place, since it also mounts /proc and /sys. Any opinions and comments appreciated. Regards, Cascardo. --
signature.asc
Description: Digital signature
