Re: [RFC] How to handle the rules engine for cgroups

[Rik van Riel <riel@redhat.com>]

On Thu, 10 Jul 2008 08:56:25 -0700
Ulrich Drepper <drepper@redhat.com> wrote:

> Once the information is available, how is it used?  We'd have to pass
> additional information to the exec syscalls.  And it has to happen so
> that if the exec call fails the original process is not affected (i.e.,
> premature changing isn't an option).  The method also must be
> thread-safe in a limited way: executing failing exec syscalls in
> multiple threads mustn't disturb the process.

One easy way is to have a "migrate on exec" option added to the
process group code.  Instead of moving yourself to a new process
group before exec, you do the same invocation but with a "migrate
me lazily at exec time" flag.

At exec time, your current resources will be subtracted from the
old process group (most of it automatically in exit_mmap) and your 
new resources will be added to the new process group on the other 
side of exec.

The exec syscall itself does not need to change.

> There is one set of problems which I don't care about but others likely
> will: what happens if some program uses the syscalls directly?  And what
> happens with old libcs and old statically linked programs?  It's exactly
> the kind of problem why I tell people to never linked statically but
> some people don't listen.

Those people will have to move their processes around between
process groups manually (or with shell scripts).  Having per
program process groups is essentially bonus functionality
over the "start daemon in own process group" and "start user
in own process group" functionalities.

Whether and how we want to implement this is open for discussion.

Personally I suspect that a kernel side rule-based engine with
user loadable rules may not be the best idea :)

-- 
All Rights Reversed