[cgmanager-devel] A few questions on the public API.

[Serge Hallyn]

Quoting James Hunt (james.hunt at ubuntu.com):
> Hi Serge,
> 
> - why does MovePid() need the ok param? Surely, the clients can just check the
> return value from the call?

Can it?  Will that return value still be sent as a new dbus message that
I can pick up later as an int message type?  If so then yeah we can drop
that.

> - cgmanager_create(): I saw the comment about EEXIST and I think we're really
> like to guarantee that if the client requests a cgroup to be created that
> already exists, that should be treated as success. Maybe we could have a @flags
> arg if clients really care about this behaviour but clearly we can't have a
> cgmanager_group_exists() call as that would be racy if it returned FALSE and
> the client then called cgmanager_create().

Yeah, that's what the code does right now, fwiw.  My concern is that
if /a/b has already been chown to alice's uid, and bob now asks for
/a/b to be created, and it returns success, then bob will be misled
since he can't now use it.

Note that really shouldn't be a problem in practice since if alice was
able to create /a/b, then alice was able to create under /a, which
should mean bob could not.  But not in all cases.

> - I wonder if we should add a D-Bus API to create 'n' groups simultaneously to
> minimise D-Bus traffic?

Sure.  ("patches welcome"  :)

> - cgmanager_get_my_cgroup(): FYI, this is currently returning a nul string
> whereas cgmanager_get_pid_cgroup (getpid()) is returning "/" so their behaviour
> is different.

That's odd...  but perhaps not worth worrying about.  get_my_cgroup will
probably be dropped.  Your cgroup path relative to your own cgroup is
always "" and your full cgroup path is always in /proc/self/cgroup.  Do
you think there's a good use case for keeping this call?

-serge