Skip to content
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

Allow custom disk size #46

Open
vinaychandra opened this issue Aug 7, 2019 · 7 comments
Open

Allow custom disk size #46

vinaychandra opened this issue Aug 7, 2019 · 7 comments

Comments

@vinaychandra
Copy link

Thank you for the great tool. Currently, it allows us to create the main bootable image of the kernel but doesn't have too much of empty space left for other actions from within Qemu. Please allow zero padded binaries to play with disk drivers from kernel.

@phil-opp
Copy link
Member

phil-opp commented Aug 8, 2019

I'm not quite sure what you mean. Could you clarify the advantage of zero padded binaries?

@64
Copy link
Contributor

64 commented Aug 8, 2019

I needed to play around with binary sizes a bit for bochs to load my kernel (https://github.com/64/solstice/blob/master/scripts/bochs.sh) so it might be better to support this inside bootimage if possible

@vinaychandra
Copy link
Author

Currently bootimage generates a "just enough" disk size. Qemu treats it as a bootable disk and works as expected.
When we develop a file system, we need a place to read and write from. Currently, bootimage neither supports adding custom files to the bootimage other than the kernel, nor supports empty space.
Adding custom file support enables us to load them dynamically from our kernels.
Adding empty space (by padding zeros) enables us to have some space to write from kernel for files and other stuff as a persistent storage.

@phil-opp
Copy link
Member

phil-opp commented Aug 8, 2019

@64

I needed to play around with binary sizes a bit for bochs to load my kernel (https://github.com/64/solstice/blob/master/scripts/bochs.sh) so it might be better to support this inside bootimage if possible

I never really used bochs, but sounds reasonable.

@phil-opp
Copy link
Member

phil-opp commented Aug 8, 2019

@vinaychandra Thanks for clarifying!

Adding custom file support enables us to load them dynamically from our kernels.

We had something like this before the rewrite, but it was never finished so we removed it again. I think this would need to be implemented in the bootloader crate, since bootimage does no image generation.

Adding empty space (by padding zeros) enables us to have some space to write from kernel for files and other stuff as a persistent storage.

So QEMU treats the loaded image as a hard disk, which allows a file system driver to write to the image file?

@vinaychandra
Copy link
Author

vinaychandra commented Aug 8, 2019

@phil-opp,

I think this would need to be implemented in the bootloader crate

I don't know which crate should be implemented where but my point would be to not autoload these extra files (like we do for kernel) but leave them on the bin file so that we can load them dynamically as required.

So QEMU treats the loaded image as a hard disk, which allows a file system driver to write to the image file?

Yes, that is my understanding. See Image types

@phil-opp
Copy link
Member

I don't know which crate should be implemented where but my point would be to not autoload these extra files (like we do for kernel) but leave them on the bin file so that we can load them dynamically as required.

Sounds reasonable. I think it could be implemented by putting it into a separate ELF section that is not loaded. We could pass the file offset in the boot info to tell the kernel the disk location of the file.

Yes, that is my understanding. See Image types

Interesting!


Note that I'm very busy for the next four weeks, so I won't have time to implement it.

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

No branches or pull requests

3 participants