Allow custom disk size
Opened this issue · 7 comments
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.
I'm not quite sure what you mean. Could you clarify the advantage of zero padded binaries?
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
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.
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.
@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?
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
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.