From: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
To: Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Linux Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>
Subject: Re: [PATCH 4/4] The control group itself
Date: Fri, 22 Feb 2008 11:12:45 +0300 [thread overview]
Message-ID: <47BE83FD.7060908@openvz.org> (raw)
In-Reply-To: <6599ad830802211247t21fdc4e4hfe637fcffd98ded7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Paul Menage wrote:
> On Thu, Feb 7, 2008 at 5:01 AM, Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> wrote:
>> +
>> +[cb] <major>:(<minor>|*) [r-][w-]
>> + ^ ^ ^
>> + | | |
>> + | | +--- access rights (1)
>> + | |
>> + | +-- device major and minor numbers (2)
>> + |
>> + +-- device type (character / block)
>> ...
>> +When reading from it, one may see something like
>> +
>> + c 1:5 rw
>> + b 8:* r-
>> +
>
> In the interest of avoiding proliferating cgroup control file formats,
> I'm wondering if we can abstract out the general form of the data
> being presented here and maybe simplify it in such a way that we can
> hopefully reuse the format for other control files in the future?
>
> For example, one way to represent this would be a map from device
> strings such c:1:5 to permission strings such as rw. Or maybe
> numerical device ids to numerical permission values.
You mean smth like <some_device_id><space><some_permissions_string>?
Well, I don't mind, but AFAIK the <major>:<minor> form is very common
for specifying the device. So I agree with the 'c:1:5 rw' form.
> The alternative might be to accept that there are two kinds of control
> files - those which are likely to be programmatically read (e.g.
> resource usage values), and those that are likely to be
> programmatically written but only actually read by humans for
> debugging purposes (like this one) and make it clear up-front when a
> control file is added which type they're considered to be. We could
> then ignore the API consistency requirements for the
> debugging-readable files.
Hmm, you mean make them a binary files? I thought that filesystem-based
API should be human readable and writable as much as possible...
> On a separate note, can you document the recommended way to completely
> overwrite the set of device permissions for a cgroup? Does this
There's not way to flush all the permissions in this implementation, but
I though about one. Maybe 'echo 0 > devices.permissions' would be good?
> involves writing a "--" permission for every device that you don't
> want in the cgroup?
Currently - yes.
> Paul
>
next prev parent reply other threads:[~2008-02-22 8:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-07 12:56 [PATCH 0/4] Devices accessibility control group (v3, release candidate) Pavel Emelyanov
[not found] ` <47AAFFF2.9030804-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-02-07 12:57 ` [PATCH 1/4] Some changes in the kobject mapper Pavel Emelyanov
2008-02-07 12:59 ` [PATCH 2/4] The character devices layer changes Pavel Emelyanov
2008-02-07 12:59 ` [PATCH 3/4] The block " Pavel Emelyanov
2008-02-07 13:01 ` [PATCH 4/4] The control group itself Pavel Emelyanov
[not found] ` <47AB013B.8060502-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-02-11 17:38 ` Serge E. Hallyn
[not found] ` <20080211173830.GA22160-6s5zFf/epYL1ENwx4SLHqw@public.gmane.org>
2008-02-12 10:28 ` Pavel Emelyanov
[not found] ` <47B174B2.5010500-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-02-12 17:21 ` Serge E. Hallyn
[not found] ` <20080212172134.GA12177-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2008-02-13 2:17 ` Paul Menage
[not found] ` <6599ad830802121817n7713fa85h51aedf4df74aa764-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-13 2:42 ` Paul Jackson
[not found] ` <20080212204215.2eca689f.pj-sJ/iWh9BUns@public.gmane.org>
2008-02-14 17:17 ` Serge E. Hallyn
2008-02-13 2:32 ` Paul Jackson
[not found] ` <20080212203215.fb636900.pj-sJ/iWh9BUns@public.gmane.org>
2008-02-14 17:18 ` Serge E. Hallyn
2008-02-12 7:42 ` sukadev-r/Jw6+rmf7HQT0dZR+AlfA
[not found] ` <20080212074217.GA15992-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-02-12 7:51 ` Pavel Emelyanov
2008-02-21 20:47 ` Paul Menage
[not found] ` <6599ad830802211247t21fdc4e4hfe637fcffd98ded7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-22 8:12 ` Pavel Emelyanov [this message]
[not found] ` <47BE83FD.7060908-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-02-23 23:12 ` Paul Menage
[not found] ` <6599ad830802231512t20343cabq738df3039c8a1d1f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-26 7:54 ` Pavel Emelyanov
2008-02-08 16:12 ` [PATCH 0/4] Devices accessibility control group (v3, release candidate) Serge E. Hallyn
-- strict thread matches above, loose matches on Subject: below --
2008-01-08 9:02 [PATCH 0/4] Devices accessibility control group (v2) Pavel Emelyanov
[not found] ` <47833C3A.8090106-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-01-08 9:18 ` [PATCH 4/4] The control group itself Pavel Emelyanov
[not found] ` <47833FF6.6060901-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-01-14 17:40 ` Serge E. Hallyn
[not found] ` <20080114174056.GB15077-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2008-01-15 7:53 ` Pavel Emelyanov
[not found] ` <478C6669.7070705-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-01-15 14:44 ` Serge E. Hallyn
[not found] ` <20080115144440.GE4453-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2008-01-15 16:13 ` Paul Menage
[not found] ` <6599ad830801150813s6a5a7374qd25b6d6206d5896a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-01-15 17:49 ` Serge E. Hallyn
[not found] ` <20080115174941.GA11638-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2008-01-15 17:54 ` Paul Menage
[not found] ` <6599ad830801150954w7e1b6db0p4dd737730f407348-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-01-15 18:17 ` Serge E. Hallyn
2008-01-14 21:54 ` Paul Menage
[not found] ` <6599ad830801141354p5b165cdao8d6184adb9ab61b6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-01-15 7:58 ` Pavel Emelyanov
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=47BE83FD.7060908@openvz.org \
--to=xemul-gefaqzzx7r8dnm+yrofe0a@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.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