Re: [Minios-devel] [UNIKRAFT PATCH v2 0/6] Move VFS initialization to ukboot

[Costin Lupu <costin.lup@xxxxxxxxx>]

Hi Simon,

On 9/9/19 1:41 PM, Simon Kuenzer wrote:
> On 08.09.19 17:05, Costin Lupu wrote:
>> Hi Simon,
>>
>> We clearly need to come up with a solution for initializing filesystems.
>> However, these series have to be reworked:
>> 1. You should add your changes once > 2. We should add this init thing
>> in vfscore instead of bloating the
>> boot.c code.
> 
> I originally chose libukboot because of our current boot logic. The
> reason is that we should not use any pre-init or init table entries for
> our system initialization. We should treat the tables as reserved to the
> Unikernel(-ized) program and its libraries. So far we used them for the
> case when we need memory and/or scheduling support. However, whenever we
> port existing standard user space programs (e.g., Linux program) to our
> environment, we actually should be aware that its constructor and init
> functions interact already with or system components. Effectively, they
> should be fully initialized at that point. I expect that most
> interactions are done with the VFS.
> Overall our current boot stages should look like this:
> 
>  0) Entry and early platform init (platform library)
>  1) Unikraft constructors
>     Cannot use ukalloc or uksched because it is not initialized yet.
>  2) Unikraft init
>     2.1) ukalloc
>     2.2) uksched
>     2.3) VFS
>     2.4) Networking
>     2.5) etc.
>  3) Program constructors
>     These are the entries that we find in the pre-init and init
>     sections.
>  4) Enter main() of the program
> 
> Everything of point 2 is currently hard-coded to libukboot. So it makes
> currently sense to put our VFS initialization there instead of
> registering it to the pre-init or init section. In fact, I agree that we
> need to introduce a "Unikraft init table" (similar to Unikraft
> constructors) where our system libraries can register themselves to. As
> intermediate solution I could introduce a vfscore_init() function that
> is called from libukboot, similar to what we did with lwip. This way, we
> keep the VFS init code in vfscore.

That's exactly what I suggested, a vfscore_init() function doing all
that stuff.

> 
> However, I also had a second reason for putting the VFS init code to
> libukboot: I had in mind that we could add initrd support with another
> patch series relatively easy:
>  1) Mount ramfs for /
>  2) Search for an archive in initrd section
>  3) Decompress archive to /
>  4) Add initrd memory region to initialized ukalloc
>     because we do not need it anymore.
> 
> A decompressing algorithm that creates directories and files from the
> archive (e.g., based on zlib) is the only missing piece. No. 4 requires
> knowledge about which allocator to add memory regions to. This would be
> currently much easier with libukboot that could dictate this. However,
> we can also find another solution for doing this when implementing
> initrd support as part of vfscore...
> 
> What do you think?

This can be done also by calling different init functions in vfscore.
However, it's out of scope for now.

Cheers,
Costin

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel