From: Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org>
To: Chris Friesen <cfriesen@nortel.com>
Cc: debian-devel@lists.debian.org, linux-kernel@vger.kernel.org,
containers@lists.linux-foundation.org
Subject: Re: cgroup mount point
Date: Mon, 2 Feb 2009 21:43:28 -0200 [thread overview]
Message-ID: <20090202234327.GW3643@vespa.holoscopio.com> (raw)
In-Reply-To: <498779C2.2060908@nortel.com>
[-- Attachment #1: Type: text/plain, Size: 2996 bytes --]
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.
--
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-02-02 23:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090202200013.GU3643@vespa.holoscopio.com>
[not found] ` <1233606371.15779.32.camel@radis.liafa.jussieu.fr>
[not found] ` <20090202205246.GA28593@glandium.org>
2009-02-02 21:41 ` Thadeu Lima de Souza Cascardo
2009-02-02 22:54 ` Chris Friesen
2009-02-02 23:43 ` Thadeu Lima de Souza Cascardo [this message]
2009-02-03 3:15 ` KAMEZAWA Hiroyuki
2009-02-03 5:06 ` Serge E. Hallyn
2009-02-06 6:17 ` Balbir Singh
2009-02-03 10:24 ` Daniel P. Berrange
2009-02-03 12:30 ` Thadeu Lima de Souza Cascardo
2009-02-03 13:26 ` Daniel P. Berrange
[not found] ` <87ljsnzo4v.fsf@benfinney.id.au>
2009-02-03 12:57 ` Thadeu Lima de Souza Cascardo
2009-02-04 3:59 ` Ben Finney
2009-02-03 14:38 ` Gustavo Noronha
2009-02-03 16:55 ` Paul Menage
2009-02-03 18:49 ` Mike Hommey
2009-02-03 18:51 ` sean finney
2009-02-03 19:14 ` Paul Menage
2009-02-03 23:38 ` Harald Braumann
2009-02-03 23:40 ` Paul Menage
2009-02-04 0:18 ` Harald Braumann
2009-02-04 9:16 ` Josselin Mouette
2009-02-05 21:19 ` José Luis Tallón
2009-02-06 22:00 ` Harald Braumann
2009-02-03 15:03 ` Gabor Gombas
2009-02-03 16:19 ` Bill Nottingham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090202234327.GW3643@vespa.holoscopio.com \
--to=cascardo@minaslivre.org \
--cc=cfriesen@nortel.com \
--cc=containers@lists.linux-foundation.org \
--cc=debian-devel@lists.debian.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®