lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 3 Feb 2009 12:15:24 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	"Chris Friesen" <cfriesen@...tel.com>
Cc:	Thadeu Lima de Souza Cascardo <cascardo@...aslivre.org>,
	containers@...ts.linux-foundation.org,
	debian-devel@...ts.debian.org, linux-kernel@...r.kernel.org
Subject: Re: cgroup mount point

On Mon, 02 Feb 2009 16:54:58 -0600
"Chris Friesen" <cfriesen@...tel.com> 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/.
> 
me, too.

But single mount point just assumes "all necessary subsystems are mounter at once"
So,
    /cgroup/<subsys>/       #this cannot handle multiple subsyses.
    or 
    /cgroup/some_nick_name  #just depends on users.

Hmm. Making documentation to use the same mount point is not so bad. But in real
usage, cgroup's mount point seems case-by-case. 
If libcgroup or libvirt shows some policy, it's good for users.

  /cgroup/<libcgroup's grouping nick name>/ ...

or some.

Thanks,
-Kame

> /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
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists