Support for Block CIMs #2261
Support for Block CIMs #2261
Conversation
ambarve
force-pushed
the
blocked_cim_import
branch
3 times, most recently
from
ad3aed4
to
2afb976
Compare
| //sys CimMountImage(imagePath string, fsName string, flags uint32, volumeID *g) (hr error) = cimfs.CimMountImage? | ||
| //sys CimDismountImage(volumeID *g) (hr error) = cimfs.CimDismountImage? | ||
|
|
||
| //sys CimCreateImage(imagePath string, oldFSName *uint16, newFSName *uint16, cimFSHandle *FsHandle) (hr error) = cimfs.CimCreateImage? | ||
| //sys CimCloseImage(cimFSHandle FsHandle) = cimfs.CimCloseImage? | ||
| //sys CimCreateImage2(imagePath string, flags uint32, oldFSName *uint16, newFSName *uint16, cimFSHandle *FsHandle) (hr error) = cimfs.CimCreateImage2? | ||
| //sys CimCloseImage(cimFSHandle FsHandle) = cimfs.CimCloseImage |
There was a problem hiding this comment.
Yes. The CimCloseImage API doesn't return anything. However, if you keep the ? for an API that returns void, the mkwinsyscall still generates the function definition with a return value. Ideally, we should fix this bug in mkwinsyscall but I unblocked the CimFS work by removing that ?.
There was a problem hiding this comment.
But the point of ? is that it returns an error instead of panicking if the DLL/function cannot be loaded. So isn't it returning an error what we want?
There was a problem hiding this comment.
I see what you mean. But then if we keep the ?, it generates the function definition with a return value and any caller inspecting that return value will see garbage data most of the time (except for cases when it actually isn't able to load that function from the DLL).
We could maybe write a wrapper for CimCloseImage that has a void return but panics in case the underlying function returns an error due to DLL load failure. I prefer removing the ? over the panic approach since the possibility of it not being able to load CimCloseImage after successfully loading other CimFS APIs is pretty low. Let me know what you think.
| return winapi.CimDeletePath(c.handle, path) | ||
| } | ||
|
|
||
| // Adds a tombstone at given path. This ensures that when the the CIMs are merged, the |
There was a problem hiding this comment.
There should be a description of what merging CIMs means somewhere. I may have missed it if it's already present though :)
There was a problem hiding this comment.
I have added a package documentation here , let me know if you want me to add any more details in there.
ambarve
force-pushed
the
blocked_cim_import
branch
from
2afb976
to
cda4bee
Compare
ambarve
force-pushed
the
blocked_cim_import
branch
from
cda4bee
to
c95a313
Compare
Currently we have a map which maintains a mapping of CIM & containerd ID to the volume at which a CIM is mounted for the given container. This was required before the layer refactoring work when we needed to get the volume path from the layer cim path. However, this isn't needed anymore. As of now, this map doesn't provide much value and makes the code a bit complicated. Moreover, we will need to rewrite some of this code anyway when we do the work required for handling `shim delete` cleanups properly (containerd/containerd#9727). Signed-off-by: Amit Barve <[email protected]>
CimFS now supports a new format for storing CIMs, named BlockCIM. A block CIM format can store the entire CIM on a block device (like a VHD) or a file formatted like a block device. This commit adds Go wrappers for the new CimFS APIs that allow creation, merging and mounting of such Block CIMs. Some new flags required when creating and mounting these CIMs are added and some deprecated flags have been removed. New type has been introduced to represent a block CIM. Unit tests have been added to test the newly added CimFS functionality. Lastly, CimFS flags aren't a part of the hcs schema (only the CimMount request is), those flags are moved from the hcs/schema2 package to the cimfs package. Signed-off-by: Amit Barve <[email protected]>
This commit adds a layer writer that can be used for extracting an image layer tar into a Block CIM format. Existing forked CIM layer writer was renamed to a common base type `cimLayerWriter`. Forked CIM layer writer & Block CIM layer writer both now extend this common base type to write layers in that specific format. This commit also removes some code that used `time.Now()` as the default timestamps for some files that it creates within the layer CIM. These timestamps cause differences in the layer CIMs generated from the same layer tar. This change fixes that. Signed-off-by: Amit Barve <[email protected]>
This commit adds the ability to parse block CIM layer mounts and to mount the merged block CIMs to be used as a rootfs for a container. Signed-off-by: Amit Barve <[email protected]>
ambarve
force-pushed
the
blocked_cim_import
branch
from
c95a313
to
559065d
Compare
This PR adds support for creating, mounting and using block CIMs for running windows process isolated containers.
Individual commits provide additional details on what changes they bring in.