LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul Menage" <menage@google.com>
To: "Paul Jackson" <pj@sgi.com>
Cc: containers@lists.osdl.org, linux-kernel@vger.kernel.org,
balbir@linux.vnet.ibm.com, a.p.zijlstra@chello.nl,
xemul@openvz.org, akpm@linux-foundation.org
Subject: Re: [RFC] Prefixing cgroup generic control filenames with "cgroup."
Date: Thu, 28 Feb 2008 17:03:33 -0800 [thread overview]
Message-ID: <6599ad830802281703hb3cff06r8ba4755f705a0879@mail.gmail.com> (raw)
In-Reply-To: <20080228173618.139f5bb4.pj@sgi.com>
On Thu, Feb 28, 2008 at 3:36 PM, Paul Jackson <pj@sgi.com> wrote:
>
> We could accomplish that much by decreeing that future new kernel
> generated names that we might add follow some stronger convention,
> such as the cgroup_ or appropriate subsystem prefix.
Subsystem-created files already have an appropriate prefix.
> No need to
> change the existing well known names for this reason.
But that's part of my point - is it reasonable to describe a system
that was only introduced in 2.6.24 as "well-known"?
>
> Actually, in terms of 'common names used
> by humans' some of these names, "tasks" and "notify_on_release", date
> back much earlier than that. Please don't rename these two files in
> cgroups; and of course absolutely don't rename them in cpusets.
No, I wasn't planning to make any changes to cpusets.
>
> Please don't end up with different names of these files, depending on
> whether you're in cgroups or cpusets, either.
That already happens - when mounted as the "cpuset" filesystem, we
have names like "mems_allowed". When mounted as cgroups, we have names
like cpuset.mems_allowed.
>
> > Could we do something like auto-prefixing user-created directories with a
> > fixed string so that there is no way in which the user can cause a
> > collision with kernel-created files?
>
> Lordy lordy -- a bunch of intrusive, complicating crap to solve a
> non-existent problem (sorry for the indelicate choice of words ;).
No, I don't like that idea either.
Paul
next prev parent reply other threads:[~2008-02-29 1:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-28 21:14 Paul Menage
2008-02-28 21:21 ` Andrew Morton
2008-02-28 21:28 ` Paul Menage
2008-02-28 21:33 ` serge
2008-02-28 22:06 ` Paul Menage
2008-03-03 8:38 ` Paul Menage
2008-03-03 9:59 ` Balbir Singh
2008-02-28 21:40 ` Andrew Morton
2008-02-28 22:06 ` Paul Menage
2008-02-28 22:21 ` Andrew Morton
2008-02-28 22:26 ` Paul Menage
2008-02-29 5:59 ` [RFC] [PATCH] " Paul Menage
2008-02-29 6:20 ` Paul Jackson
2008-02-29 9:34 ` Paul Menage
2008-02-29 15:30 ` Paul Jackson
2008-02-29 17:59 ` Paul Menage
2008-02-29 19:20 ` Paul Jackson
2008-02-28 21:28 ` [RFC] " serge
2008-02-28 23:36 ` Paul Jackson
2008-02-29 1:03 ` Paul Menage [this message]
2008-02-29 1:22 ` Paul Jackson
2008-02-29 11:38 ` Xpl++
2008-03-03 7:23 ` Li Zefan
2008-03-03 9:11 ` Paul Menage
2008-03-05 1:24 ` Paul Jackson
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=6599ad830802281703hb3cff06r8ba4755f705a0879@mail.gmail.com \
--to=menage@google.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=containers@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=xemul@openvz.org \
--subject='Re: [RFC] Prefixing cgroup generic control filenames with "cgroup."' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).