Re: rumpbake support for baked-in rootfs
- From: Antti Kantee <pooka@xxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Mon, 15 Jun 2015 18:05:06 +0000
On 15/06/15 14:33, Martin Lucina wrote:
I've rebased the wip-rootfs branch against the latest master and re-pushed
it in case you need that. I'll write up plans for merging the baked-in
rootfs code to master shortly.
Let's think about if what you're proposing is acceptable in the first
place before making plans on how to merge it.
As far as I could extract from your original proposal (and please
correct me if I'm wrong), the proposal includes the following subpoints:
1) adds a default set of files which libc internally expects
2) adds support for a tarball-based "file system"
3) support for linking an arbitrary file system image into the binary
4) syntax for all of the above squashed into one flag
"1" is a great usability improvement.
"2" might be nice, though it might be nicer if it actually worked like
every other file system driver instead of just being randomly hacked
somewhere.
"3" is, AFAICT, useful only when you can't have a block device. What
are such cases? I know Andrew used it for platform bootstrap, but
adding an entire mechanism to support a small phase in platform bringup
is out of the question.
"4" leaves much to be desired. Why can you only add files but not
remove them? Why is the backing file system type hardcoded to "tarball"?
How do you justify "2" and "3", and how do you plan to fix "4"?
Other related posts:
