Skip to content

compressed initramfs #71

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

compressed initramfs #71

wants to merge 2 commits into from

Conversation

Villemoes
Copy link

I'm playing around with the initramfs decompression code, so it's nice to be able to provide a compressed initramfs in virtme.

Rasmus Villemoes added 2 commits March 12, 2021 17:13
In preparation for supporting using a compressed initramfs, refactor
the code to send the initramfs data through a subprocess.
In order to test/debug/benchmark various initramfs decompression
methods, it is useful to be able to let virtme provide a compressed
initramfs.
@amluto
Copy link
Owner

amluto commented Apr 10, 2021

I'm okay with the concept and the interface, but I don't like piping through cat. Also, Python has modules for most of these. Maybe it could be something like:

def open_with_compression(filename, compressor):
    if compressor == 'gzip':
        return gzip.open(filename, ...)
    elif compressor == 'zstandard':
        import zstandard
        return zstandard.whatever(...)

I'm also not convinced that -9 is the right default.

@Villemoes
Copy link
Author

I'm okay with the concept and the interface, but I don't like piping through cat.

Why not? It's not performance critical, and even so, I don't think it will ever be noticed.

Also, Python has modules for most of these. Maybe it could be something like:

Perhaps, but see below.

I'm also not convinced that -9 is the right default.

The command lines are taken from what the kernel itself would do with CONFIG_INITRAMFS_SOURCE (and other producers of initramfs images, e.g. yocto, also use those parameters), so it seemed most sensible to use the same when the idea was to test tweaks of the decompression/unpacking code. I'm not sure the python wrappers could easily be convinced to apply those same parameters, and e.g. for lz4, it's not obvious they'd even have support for the equivalent of the required -l flag.

I can change to do open_with_compression and avoid cat for the none case, but I do think this needs to invoke the actual compressors with the same parameters that would be used IRL.

@amluto
Copy link
Owner

amluto commented Apr 11, 2021

I'm okay with the concept and the interface, but I don't like piping through cat.

Why not? It's not performance critical, and even so, I don't think it will ever be noticed.

Also, Python has modules for most of these. Maybe it could be something like:

Perhaps, but see below.

The idea would be to have fewer dependencies. Python includes most of the compressors you're using, and avoiding digging them out of the path will avoid admittedly rare failure cases.

I'm also not convinced that -9 is the right default.

The command lines are taken from what the kernel itself would do with CONFIG_INITRAMFS_SOURCE (and other producers of initramfs images, e.g. yocto, also use those parameters), so it seemed most sensible to use the same when the idea was to test tweaks of the decompression/unpacking code. I'm not sure the python wrappers could easily be convinced to apply those same parameters, and e.g. for lz4, it's not obvious they'd even have support for the equivalent of the required -l flag.

I can change to do open_with_compression and avoid cat for the none case, but I do think this needs to invoke the actual compressors with the same parameters that would be used IRL.

I'm okay with that, although, if the goal is performance, then there ought to be a default that's fast, and -9 is probably not optimal for a blob that will be decompressed exactly once.

But the goal right now seems to be testing, so I'm okay with your defaults.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants