On Thu, 2008-02-07 at 12:49 -0800, Paul Menage wrote:
> On Feb 7, 2008 12:28 PM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> >
> > While on the subject, could someone document struct cgroup_subsys.
>
> There's documentation for all the methods in Documentation/cgroup.txt
Hehe, and here I was loo
Quoting Peter Zijlstra ([EMAIL PROTECTED]):
>
> On Thu, 2008-02-07 at 18:37 +0300, Pavel Emelyanov wrote:
> > The Documentation/cgroups.txt file contains the info on how
> > to write some controller for cgroups subsystem, but even with
> > this, one need to write quite a lot of code before develop
On Feb 7, 2008 12:28 PM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> While on the subject, could someone document struct cgroup_subsys.
There's documentation for all the methods in Documentation/cgroup.txt
> particular, I've wondered why we have: cgroup_subsys::can_attach() and
> not use a retu
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
> The Documentation/cgroups.txt file contains the info on how
> to write some controller for cgroups subsystem, but even with
> this, one need to write quite a lot of code before developing
> the core (or copy-n-paste it from some other place).
>
> I pr
On Feb 7, 2008 7:37 AM, Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> The Documentation/cgroups.txt file contains the info on how
> to write some controller for cgroups subsystem, but even with
> this, one need to write quite a lot of code before developing
> the core (or copy-n-paste it from some o
On Thu, 2008-02-07 at 18:37 +0300, Pavel Emelyanov wrote:
> The Documentation/cgroups.txt file contains the info on how
> to write some controller for cgroups subsystem, but even with
> this, one need to write quite a lot of code before developing
> the core (or copy-n-paste it from some other pla
> useful to have a filesystem visibility control group.
idle minds would like to know ... what is one of these?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214
_
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> yet another try to extend the clone flags and probably not the last !
> but I hope to raise some discussion on this topic with this simple API.
>
> I plan to send to Andrew if no one has objections.
Looks like a winner to me.
-serge
> Thanks !
>
On Thu, 2008-02-07 at 18:04 +0300, Pavel Emelyanov wrote:
> Having this proxy is the easiest way to keep the global list and
> file_system_type structure (almost) untouched and simplify the code.
>
> The filesystems.list file syntax is simple: [+-] without
> a '\n' at the end. Made for 2.6.24-rc8-
The Documentation/cgroups.txt file contains the info on how
to write some controller for cgroups subsystem, but even with
this, one need to write quite a lot of code before developing
the core (or copy-n-paste it from some other place).
I propose to put this minimal controller into Documentation
d
After making the devices visibility cg, I thought, that it might
be useful to have a filesystem visibility control group.
The patch is rather simple - all the code is in fs/filesystems.c
The main idea is in file_system_proxy object. This coincides in
its three first fields with file_system_type (
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
> > Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
> >> [snip]
> >>
> Mmm. I wanted to send one small objection to Cedric's patches with mqns,
> but the thread was abandoned by the time I decided to do-it-right-now.
> >>>
Each new group will have its own maps for char and block
layers. The devices access list is tuned via the
devices.permissions file. One may read from the file to get
the configured state.
The top container isn't initialized, so that the char
and block layers will use the global maps to lookup
They are the same as for the character layer, but
the good news is that there are no caching in this
case.
So this patch is smaller and easier to understand
as compared to the previous one.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/block/genhd.c b/block/genhd.c
index 5
These changes include the API for the control group
to map/remap/unmap the devices with their permissions
and one important thing.
The fact is that the struct cdev is cached in the inode
for faster access, so once we looked one up we go through
the fast path and omit the kobj_lookup() call. This i
The main thing that I want from the kobj mapper is to add
the mode_t on the struct kobj_map that reflects with
permissions are associated with this particular map. This
mode is to be returned via the kobj_lookup.
I use the FMODE_XXX flags to handle the permissions bits,
as I will compare these
Changes from v2:
* Fixed problems pointed out by Sukadev with permissions
revoke. Now we have to perform kobject re-lookup on
each char device open, just like for block ones, so I
think this is OK.
The /proc/devices tune is still in TODO list, as I have
problems with getting majors _in_a_sim
Cedric Le Goater wrote:
>>> Off-topic: does any of you know whether Andrew is willing to accept
>>> new features in the nearest future? The problem is that I have a
>>> device visibility controller fixed and pending to send, but I can't
>>> guess a good time for it :)
>
> I have the clone64/unsha
From: Cedric Le Goater <[EMAIL PROTECTED]>
This patch adds a do_unshare() routine which will be common
to the unshare() and unshare64() syscall.
Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
---
kernel/fork.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: 2.6.24-mm1
From: Cedric Le Goater <[EMAIL PROTECTED]>
This is a preliminary patch changing the clone_flags type to 64bits
for all the routines called by do_fork().
It prepares ground for the next patch which introduces an enhanced
version of clone() supporting 64bits flags.
This is work in progress. All
From: Cedric Le Goater <[EMAIL PROTECTED]>
This patch adds 2 new syscalls :
long sys_clone64(unsigned long flags_high, unsigned long flags_low,
unsigned long newsp);
long sys_unshare64(unsigned long flags_high, unsigned long flags_low);
clone64() does not support CLONE
yet another try to extend the clone flags and probably not the last !
but I hope to raise some discussion on this topic with this simple API.
I plan to send to Andrew if no one has objections.
Thanks !
C.
___
Containers mailing list
[EMAIL PROTECTED]
>> Off-topic: does any of you know whether Andrew is willing to accept
>> new features in the nearest future? The problem is that I have a
>> device visibility controller fixed and pending to send, but I can't
>> guess a good time for it :)
I have the clone64/unshare64 syscalls ready for most com
>>> Breaking this circle was not that easy with pid namespaces, so
>>> I put the strut in proc_flush_task - when the last task from the
>>> namespace exits the kern-mount-ed vfsmnt is dropped, but we can't
>>> do the same stuff with devpts.
>> But I still don't see what the problem is with my prop
Serge E. Hallyn wrote:
> Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
>> [snip]
>>
Mmm. I wanted to send one small objection to Cedric's patches with mqns,
but the thread was abandoned by the time I decided to do-it-right-now.
So I can put it here: forcing the CLONE_NEWNS is not
25 matches
Mail list logo
