2,257
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − − + − An utility to execute code in foreign process address space. It is based on the same technology we use in CRIU to obtain some process-private data on dump.+ + + − + − A Python module to convert google protocol buffers to json and back.+ + + Line 16:
Line 19: − + + + + + + + + + + +
→Managing protocol buffers objects
This page contains a list of tools that were developed for criu and which others might want to use in their projects.
This page contains a list of technologies and tools have been developed while we were implementing CRIU, which might be useful on their own. These tools are still maintained within the CRIU itself, but eventually they can be split out into a standalone project and CRIU will be fixed to use those as libraries/sub-tools.
These tools are being still maintained, unlike their alternatives. Some of them are not formatted as a separate project(still could be just used,i.e. python modules), but feel free to ask us to distinguish them.
== [https://github.com/xemul/compel Compel] ==
== Parasite code injection ==
This thing was split into a sub-project called [[compel]].
Compel is an utility to execute code in foreign process address space. It is based on the same technology we use in CRIU to obtain some process-private data on dump.
We don't currently maintain compel and it's quite out-dated, but still functional.
== [https://github.com/xemul/criu/blob/master/pycriu/images/pb2dict.py pb2dict.py] ==
''See also: [[Code blobs]]''
== Managing protocol buffers objects ==
We have [https://github.com/xemul/criu/blob/master/pycriu/images/pb2dict.py a Python module] to convert google protocol buffers to python objects and back.
Unlike other projects to convert pb to python dict or json, our pb2dict does treat optional fields with empty repeated inside properly. It includes special support for custom field options to mark those needed to be treated in a special way.
Unlike other projects to convert pb to python dict or json, our pb2dict does treat optional fields with empty repeated inside properly. It includes special support for custom field options to mark those needed to be treated in a special way.
See more examples in our protobuf/*.proto files.
See more examples in our protobuf/*.proto files.
It is also worth noting, that we have a unique number for all kinds of custom protobuf options(see [[Images#Notes_about_protobuf]]), so you don't have to worry that it might collide with others.
It is also worth noting, that we have a unique number for all kinds of custom protobuf options, so you don't have to worry that it might collide with others.
''See also: [[Images]]''
== Sharing of kernel objects ==
It's well known that some kernel objects can be shared between tasks. For example, if a task calls <code>open()</code> to obtain a file descriptor and then <code>fork()</code>-s the file object referenced by the file descriptor becomes shared between the parent and its child. The similar thing happens when a task <code>dup()</code>-s a file -- he gets two file descriptors that reference the same file. Unlike this two subsequent <code>open()</code>-s result in two different file objects.
In kernel there's no API that can just reveal the tasks-to-objects map. Instead, there's an API called <code>kcmp()</code> that compares two e.g. file descriptors and reports back whether the file referenced by them is the same or not. In CRIU we have a [https://github.com/xemul/criu/blob/master/kcmp-ids.c KCMPIDS] engine that uses this API, build [[kcmp trees]] and turns the equals-notequals answers into a list of IDs of objects.
''See also: [[Kcmp trees]]''
[[Category:Development]]
[[Category:Development]]
[[Category:Under the hood]]
[[Category:Under the hood]]