- 26 Mar, 2012 2 commits
-
-
Stanislav Kinsbursky authored
Pid number is redundant - this file is one for the whole tree. Signed-off-by:
Stanislav Kinsbursky <skinsbursky@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Stanislav Kinsbursky authored
Signed-off-by:
Stanislav Kinsbursky <skinsbursky@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 25 Mar, 2012 10 commits
-
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
This makes the code look cleaner and prepares the ground for better fmaps dumping Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Since now on the fdinfo image only contains plain fdinfo_entry-es. The tpye == FDINFO_REG files are described by regfiles.img entries and are matched by te ID in both. At dump stage each new ID generated results in a new entry in the regfiles.img. At restore stage open_fe_fd should open a regfile by the fdinfo's ID. Now this is done in suboptimal way, need to improve. Show shows both images separately. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
No colon at the end and handle empty ... set properly. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
This will be required to determine whether we should dump the respective file, or it was already dumped and we just re-use its id in fdinfo_entry. For special fd-s the ID is always new. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Make fdinfo_entry carry only the minimal info describing a file descriptor -- the fd value itself, the fd type (regular file, exe link, cwd, filemap and it will be pipes, sockets, inotifies, etc.) and the describing file ID. The mentioned ID will identify the type-d object, e.g. for regfiles this ID is already generated with file-ids.c code. The other part of this structure describes a regfile (i.e. a file opened with open syscall). I put this new entry at the end of the fdinfo_entry just to make the patching simpler. Soon this entry will be dumped into its own file. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
The namelen is u16, to cover the PATH_MAX u8 is not enough. The pos is u64, since file offset is that long indeed. The id is u32 as per previous patch. Fix printf-s respectively. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Don't print namelen (it's useless) and type (the code being patched works with FDINFO_REG only). Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
The unique id is 32 bit and consists only of the subid value. This is _really_ enough. The genid part is just a hint for the tree-search algirythm to avoid unneeded sys_kcmp calls. Plus, generate IDs for special files. This will make it easier to move the regfiles into into separate files (see the respective patch for details). Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 24 Mar, 2012 11 commits
-
-
Pavel Emelyanov authored
Use the open_fe_fd everywhere to obtain an fd from image. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
It is u32 and that is it :\ Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Just for debugging. Useful to know how the tree was built Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
The subtree node should be linked with common rbtree procedure. Otherwise the very first subtree insertion results in an infinite loop in the rb linking and balancing code. Plus, mark the root as static and add the subroot node initialization check. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Check for files with equal paths are handled" Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
It's actually useless for user, this field is for crtools only to find out when one fdinfo entry ends and the new one starts. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Open the exec link at fd restore stage as yet another service fd, then pass it to restover via args and just call prctl on it. This is good for several reasons -- the amount of code required for this is less and opening files should better happen before we switch to restorer (opening will be complex and it's MUCH easier to open all we need in one place). Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 23 Mar, 2012 4 commits
-
-
Stanislav Kinsbursky authored
Hide the structure - it's not required. [ xemul: Ranem long id into u32 id and adopt to current tree ] Signed-off-by:
Stanislav Kinsbursky <skinsbursky@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Stanislav Kinsbursky authored
This is a precursor patch. Macro for max possible fd type will be required. And it's easier to use enum in this case. Signed-off-by:
Stanislav Kinsbursky <skinsbursky@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 22 Mar, 2012 11 commits
-
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Stanislav Kinsbursky authored
This is a cleanup patch. This tree is merged only once. So it's image file can be opened by opne_image() call and dumped right after collect stage. Signed-off-by:
Stanislav Kinsbursky <skinsbursky@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Since the collect_shmems updates start address for vmas, for two shared mappings in one task we'll try to dup() the 1st restoration attempt, since the si's start will be set to the 2nd one, which is not yet restored. Thus we should map-and-open the first one being restored, not the one with matched address and dup() all the rest. [avagin@: There's no such thing, since the collect stage checks for pid being less _or_ _equal_ and this only the first vma's start will be saved. But anyway, this makes it more obvious.] Acked-by:
Andrey Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Acked-by:
Andrey Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Just make the fixup_vma_fds read and write vma images and those called by it provide and fd for this. Acked-by:
Andrey Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Acked-by:
Andrey Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Pavel Emelyanov authored
Acked-by:
Andrey Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
- 21 Mar, 2012 2 commits
-
-
Pavel Emelyanov authored
The core image now contains only core per-task stuff. The new file resurrects Tula magic number removed earlier. Acked-by:
Andrey Vagin <avagin@parallels.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
This routine will be used more widely and we will be generating sockets with name based on some predefined unique value rather than 'pid', so name argument this way. No change on functional level. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-