On Fri, Aug 13, 2010 at 12:43 PM, Balbir Singh
<[email protected]> wrote:
> On Wed, Aug 11, 2010 at 8:25 AM, Dhaval Giani <[email protected]> wrote:
>>
>> On Tue, Aug 10, 2010 at 9:38 PM, Jason Baron <[email protected]> wrote:
>> > Hi,
>> >
>> > I was playing around with the language bindings mentioned in: Subject:
>> > [Libcg-devel] [hack] Language bindings for libcgroup
>> >
>> > I was just trying to figure out how to call the
>> > "cgroup_read_stats_begin()" function from python. The third argument
>> > takes a 'void **'. How can I call this function in python?
>> >
>> > I've posted my full test script (building on the one you posted) below.
>> > The error I'm currently getting is:
>> >
>> > Traceback (most recent call last):
>> > File "./tester.py", line 20, in <module>
>> > cgroup_read_stats_begin("cpu", "/cgroup/test", byref(handle), cg_stat)
>> > TypeError: in method 'cgroup_read_stats_begin', argument 3 of type 'void
>> > **'
>> >
>>
>> I i read your script corectly, you are passing a void * as opposed to
>> a void **. Not sure hwo to fix it in python though.
>>
>
> No, that's not it, we need to create typemaps. Jason could you please
> add the following typemap in libcgroup.i before the "C" prototypes and
> structures
>
> %typemap (in) void** (void *temp) {
> void *arg;
> if ((arg = PyCObject_AsVoidPtr($input)) != NULL) {
> $1 = &arg;
> } else
> $1 = &temp;
> }
>
> %typemap (argout) void** {
> PyObject *obj = PyCObject_FromVoidPtr(*$1, NULL);
> $result = PyTuple_Pack(2, $result, obj);
> }
>
> Recompile the swig module and the libcgroup_wrap.c file.
>
> Then could you try the following python script
>
> #!/usr/bin/python
>
> from libcgroup import *
> from ctypes import *
>
> cgroup_init()
> #
> # Add the correct controllers based on the mount point
> #
> cg_stat = cgroup_stat()
> p = c_void_p()
> ret, p = cgroup_read_stats_begin("memory", "/", p, cg_stat)
> while ret != ECGEOF:
> print "%s:%s" %(cg_stat.name, cg_stat.value)
> ret, p = cgroup_read_stats_next(p, cg_stat)
>
> cgroup_read_stats_end(p)
>
> NOTE: The return values are twisted, the void **handle needs to be
> reloaded back using ret, p
> NOTE: I've not checked the program for leaks at the moment
>
> Please do report back if this works for you. This should potentially
> solve most of the void** issues we have passing data between libcgroup
> and python wrappers back and forth
I have the python wrapper working to a large degree
1. Please provide input if it works at your end
2. Should we start moving some of the tooling to python
3. Should the wrappers be included in the build? Packaging can be
considered later keeping license, etc in mind
4. More extensive tests using python
More updates, I now have a python tool that mimics read_stats test case
libcgroup.i needs to be updated to be
%module libcgroup
%{
#include "libcgroup.h"
%}
%include typemaps.i
%include cpointer.i
%pointer_functions(int, intp);
%typemap (in) void** (void *temp) {
void *arg;
if ((arg = PyCObject_AsVoidPtr($input)) != NULL) {
$1 = &arg;
} else
$1 = &temp;
}
%typemap (argout) void** {
PyObject *obj = PyCObject_FromVoidPtr(*$1, NULL);
$result = PyTuple_Pack(2, $result, obj);
}
Append the preprocessed output of libcgroup.h to this
Python test case
#!/usr/bin/python
from libcgroup import *
from ctypes import *
cgroup_init()
#
# Add the correct controllers based on the mount point
#
cg_stat = cgroup_stat()
tree_handle = c_void_p()
info = cgroup_file_info()
lvl = new_intp()
ret1, tree_handle = cgroup_walk_tree_begin("memory", "/", 0,
tree_handle, info, lvl)
root_len = len(info.full_path) - 1
while ret1 != ECGEOF:
if (info.type == CGROUP_FILE_TYPE_DIR):
dir = info.full_path[root_len:]
print "\nDirectory %s\n" %(dir)
p = c_void_p()
ret, p = cgroup_read_stats_begin("memory", dir, p, cg_stat)
while ret != ECGEOF:
print "%s:%s" %(cg_stat.name, cg_stat.value.strip('\n'))
ret, p = cgroup_read_stats_next(p, cg_stat)
cgroup_read_stats_end(p)
ret1, tree_handle = cgroup_walk_tree_next(0, tree_handle,
info, intp_value(lvl))
cgroup_walk_tree_end(tree_handle)
delete_intp(lvl)
Output
Directory /
cache:470429696
rss:1723478016
mapped_file:91430912
pgpgin:25015501
pgpgout:24479879
swap:46346240
inactive_anon:373895168
active_anon:1414426624
inactive_file:188903424
active_file:216592384
unevictable:65536
hierarchical_memory_limit:9223372036854775807
hierarchical_memsw_limit:9223372036854775807
total_cache:470429696
total_rss:1723478016
total_mapped_file:91430912
total_pgpgin:25015501
total_pgpgout:24479879
total_swap:46346240
total_inactive_anon:373895168
total_active_anon:1414426624
total_inactive_file:188903424
total_active_file:216592384
total_unevictable:65536
Directory /virt
cache:13246464
rss:1357000704
mapped_file:2121728
pgpgin:4885280
pgpgout:4550747
swap:34066432
inactive_anon:71790592
active_anon:66998272
inactive_file:9814016
active_file:2666496
unevictable:1218977792
hierarchical_memory_limit:1572864000
hierarchical_memsw_limit:9223372036854775807
total_cache:13246464
total_rss:1357000704
total_mapped_file:2121728
total_pgpgin:4885280
total_pgpgout:4550747
total_swap:34066432
total_inactive_anon:71790592
total_active_anon:66998272
total_inactive_file:9814016
total_active_file:2666496
total_unevictable:1218977792
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel
