loader: Re-organize module layout

[TimePrinciple]

Summary of the PR

loader: Re-organize module layout

Re-organize modules of loader to follow image format, enable reuse of
code across different architectures.

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR have Signed-Off-By trailers (with
  git commit -s), and the commit message has max 60 characters for the
  summary and max 75 characters for each description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[TimePrinciple]

Should we consider modify our CI to ignore changes not committed, or change our bench test code to skip download, use local binary?

This setup is confusing while having a binary in our repo and download it from internet when testing 😵‍💫

[roypat]

Should we consider modify our CI to ignore changes not committed, or change our bench test code to skip download, use local binary?

This setup is confusing while having a binary in our repo and download it from internet when testing 😵‍💫

I agree its a confusing/annoying, but I'm not sure about the license implications of including the kernel binary in the repository, so let's keep it the way it is for now :/

[TimePrinciple]

Should we consider modify our CI to ignore changes not committed, or change our bench test code to skip download, use local binary?
This setup is confusing while having a binary in our repo and download it from internet when testing 😵‍💫

I agree its a confusing/annoying, but I'm not sure about the license implications of including the kernel binary in the repository, so let's keep it the way it is for now :/

I don't know why after re-organizing the layout makes the bzimage binary different, see https://buildkite.com/rust-vmm/linux-loader-ci/builds/764#01929877-c73e-4d57-9a9c-1bb5ef78e105

In that run, I haven't remove the binary :( but it's changed somehow after the test downloaded it

[TimePrinciple]

Should we consider modify our CI to ignore changes not committed, or change our bench test code to skip download, use local binary?
This setup is confusing while having a binary in our repo and download it from internet when testing 😵‍💫

I agree its a confusing/annoying, but I'm not sure about the license implications of including the kernel binary in the repository, so let's keep it the way it is for now :/

I don't know why after re-organizing the layout makes the bzimage binary different, see https://buildkite.com/rust-vmm/linux-loader-ci/builds/764#01929877-c73e-4d57-9a9c-1bb5ef78e105

In that run, I haven't remove the binary :( but it's changed somehow after the test downloaded it

Update: fixed by @roypat in rust-vmm/rust-vmm-ci#169

[roypat]

In light of #190, I'm very much in favor of this change, but we need to definitely mention it in the changelog, pointing out how the modules were moved. It might even make sense to create some re-exports according to the old module structure, to avoid downstream users of this crate having to update, e.g.

pub mod x86_64 {
    pub mod elf { 
        pub use crate::loader::elf::*;
    }
}

and so on (which I just realize is what Rob also suggested in #190 :D)

[TimePrinciple]

In light of #190, I'm very much in favor of this change, but we need to definitely mention it in the changelog, pointing out how the modules were moved. It might even make sense to create some re-exports according to the old module structure, to avoid downstream users of this crate having to update, e.g.

pub mod x86_64 {
    pub mod elf { 
        pub use crate::loader::elf::*;
    }
}

and so on (which I just realize is what Rob also suggested in #190 :D)

Noted, I failed to understand that intent initially, I will work it out :)

[TimePrinciple]

In light of #190, I'm very much in favor of this change, but we need to definitely mention it in the changelog, pointing out how the modules were moved. It might even make sense to create some re-exports according to the old module structure, to avoid downstream users of this crate having to update, e.g.

pub mod x86_64 {
    pub mod elf { 
        pub use crate::loader::elf::*;
    }
}

and so on (which I just realize is what Rob also suggested in #190 :D)

I tried to add this re-export, and I just find out the aarch64 and x86_64 are both declared as private module and thus transparent to users, i.e. they won't be able to write something like use linux_loader::x86_64::... that kind of thing :O

[roypat]

Ahh, very neat, thanks for checking!

(verified by compiling Firecracker against this, and everything indeed still works without changes)