Use TempFile as owned File to avoid manual File reopening - waiting on support from rust-vmm/vmm-sys-util

[iulianbarbu]

There are two ways of approaching a better implementation for achieving with ease temporary file/directory creation/management:

1. We consume rust-vmm/vmm-sys-util crate TempFile and TempDir structs inside Firecracker. These structs miss file operations implementations, like read, write and seek. We need this support from within rust-vmm/vmm-sys-util crate, and consume it like that in Firecracker, because otherwise it would mean to add wrappers inside Firecracker. It is worth mentioning that while we would implement these file operations, we should take into account that when we read and write to files, we have to open files with specific file permissions. So we might want to add support for file permissions too.

2. There is another suggestion that says that when creating a temporary file/directory, we should unlink it immediately, then return a File that represent the handle for that unliked file/directory, that we're gonna operate with, and leave altogether the TempFile/TempDir structs as builders for these temporary files. This would simplify a lot the implementation, and wouldn't need any support for file operation, as the current implementation needs.

[andreeaflorescu]

Should we add this issue in rust-vmm/vmm-sys-util instead so more people can chime in?

[alxiord]

Option 2 is not an alternative to option 1 - option 1 assumes that we change nothing in rust-vmm and implement the missing functionality in Firecracker. I don't like that; tempfile I/O is unrelated to the consumer of the tempfiles, and I find the I/O functionality basic enough to make sense in the standalone vmm-sys-util crate.

If we all agree that this makes sense, we should move the implementation discussion to rust-vmm.

[iulianbarbu]

Option 2 is not an alternative to option 1 - option 1 assumes that we change nothing in rust-vmm and implement the missing functionality in Firecracker. I don't like that; tempfile I/O is unrelated to the consumer of the tempfiles, and I find the I/O functionality basic enough to make sense in the standalone vmm-sys-util crate.

If we all agree that this makes sense, we should move the implementation discussion to rust-vmm.

We are on the same page here, tempfile I/O should be included in standalone vmm-sys-util crate and I will open an issue there.

To be clear, in Option 1 I was referring to the addition of file operations functionality inside rust-vmm/vmm-sys-util crate. Can you tell me what led you to the opposite conclusion?

[alxiord]

To be clear, in Option 1 I was referring to the addition of file operations functionality inside rust-vmm/vmm-sys-util crate. Can you tell me what led you to the opposite conclusion?

I guess I got stuck on otherwise it would mean to add wrappers inside Firecracker and got the wrong idea, thanks for clarifying 👍

[iulianbarbu]

To be clear, in Option 1 I was referring to the addition of file operations functionality inside rust-vmm/vmm-sys-util crate. Can you tell me what led you to the opposite conclusion?

I guess I got stuck on otherwise it would mean to add wrappers inside Firecracker and got the wrong idea, thanks for clarifying 👍

Yep, sure. 👍
Opened rust-vmm/vmm-sys-util#60.

[acatangiu]

Let's keep this open to track the Firecracker related work needed once we find the right solution in vmm-sys-util.

[acatangiu]

Currently blocked on rust-vmm/vmm-sys-util#64