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

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

On 09.09.19 13:56, Costin Lupu wrote:
> 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
Okay, I am going to send a v3 with this changes. However, I will take 
patch no. 1 and 5 out of this series. They are less relevant. I will 
send them individually.
Cheers,

Simon

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