Fw: cgroups and dbus

[KAMEZAWA Hiroyuki]

On Mon, 21 Dec 2009 10:03:58 +0000
Ian Molton <ian.molton at collabora.co.uk> wrote:

> Balbir Singh wrote:
> > On Mon, Dec 21, 2009 at 10:54 AM, KAMEZAWA Hiroyuki <
> > kamezawa.hiroyu at jp.fujitsu.com> wrote:
> > 
> >> Forwarding to container mailing list. Sorry, I myself don't have quick
> >> answer. But, hmm, what you want cannot be achieved with libcgroup ?
> 
> Cheers guys,
> 
> my subscription to containers@ hasnt come through yet so please CC me :)
> 
> I'm working on implementing a kernel-based dbus solution, where the
> 'daemon' is more of a routing manager that updates some in kernel
> tables, allowing a lightweight kernel daemon to route messages
> appropriately, and thus reducing the number of context switches needed
> to send messages by half.
> 
> DBus has the concepts of 'system' and 'session' busses, and it seems
> like cgroups could be a good fit for determining which busses an
> application is on.
> 
> AIUI, an application can be connected to:
> 
I'm not sure wheter this kind of moving function from user to kernel
is welcomed or not..


> 1) The system bus
> 2) A session bus (singular)
> 3) Both of the above
> 4) A private (point to point) bus
> 
> so ideally we would need a process to inherit the system bus cgroup from
> its parent, and also be able to be in a session bus cgroup (which would
> be mutually exclusive with being in another session bus cgroup).
> 
> Point to point dbus connections could happily continue using unix
> sockets (or whatever). These have neever been under the control of
> dbus-daemon anyway.
> 

It seems what you asked was an example of cgroup.
Maybe the simplest cgroup in the kernel is CONFIG_CGROUP_CPUACCT. 
(kernel/sched.c) The next one is CGROUP_DEVICE (security/device_cgroup.c)

Documentation under Documentation/cgroups/ is always taken care to be updated.
If you notice some description is unclear or obsolete, please report it.

Thanks,
-Kame