Re: [Minios-devel] [Unikraft] Static Libraries not being linked properly

[Wei Chen <Wei.Chen@xxxxxxx>]

Hi Simon,

> -----Original Message-----
> From: Simon Kuenzer <simon.kuenzer@xxxxxxxxx>
> Sent: 2018年5月7日 17:06
> To: Wei Chen <Wei.Chen@xxxxxxx>; Ajay Garg <ajaygargnsit@xxxxxxxxx>
> Cc: minios-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Minios-devel] [Unikraft] Static Libraries not being linked
> properly
> 
> Hey Ajay, hey Wei,
> 
> On 04.05.2018 07:25, Wei Chen wrote:
> > Hi Ajay,
> >
> >> -----Original Message-----
> >> From: Ajay Garg <ajaygargnsit@xxxxxxxxx>
> >> Sent: 2018年5月4日 11:55
> >> To: Wei Chen <Wei.Chen@xxxxxxx>
> >> Cc: Simon Kuenzer <simon.kuenzer@xxxxxxxxx>; minios-
> devel@xxxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [Minios-devel] [Unikraft] Static Libraries not being linked
> >> properly
> >>
> >> Hi Wei.
> >>
> >> Thanks for the reply.
> >>
> >> On Fri, May 4, 2018 at 8:21 AM, Wei Chen <Wei.Chen@xxxxxxx> wrote:
> >>> Hi Ajay,
> >>>
> >>> As what I understand, most of the libraries will use the posix
> >>> APIs that provided by libc to use system functions. For Linux,
> >>> the libc is a wrap of Linux system calls. For Unikraft, the Libc
> >>> is a wrap of platform APIs.
> >>
> >> Hmm, currently in lib/nolibc, I only see files such as string.c,
> >> stdlib.c etc, all of which look bare-metal code to me.
> >> I am sure I am overlooking something, but I will be grateful if you
> >> could give one example of an API wrapping platform APIs.
> >>
> >
> > You can see the code in lib/nolibc/stdio.c:
> > int vfprintf(FILE *fp, const char *fmt, va_list ap)
> >
> > This API is a wrap of ukplat_coutk. ukplat_coutk is a platform API
> > which is provided by platform console library (plat/xen/console.c or
> > plat/kvm/x86/console.c)
> >
> >>> Linux has more than 300 system calls,
> >>> as Unikraft is new, we don’t have so many platform APIs in this
> >>> stage. This means we haven't implemented all posix APIs in nolibc,
> >>> if the libraries of filesystem/lwip/other are using some APIs that
> >>> we are missing, you have to implement them in current stage.
> >>
> >> Hmm.. just curious, src-netbsd in rumprun manages to provide all APIs
> >> for xen (too bad there is no support for xen-on-arm there).
> >
> >
> > I regret that too : (
> > But I am not familiar with src-netbsd, I am not very clear about
> > "provide all APIs" here.
> >
> 
> The reason why Rumprun supports a much more complete API is that 1st the
> project is older than Unikraft ;-) and 2nd it is based on an existing
> kernel implementation. With Unikraft we try to achieve something
> different which also explains why we come from the other side (building
> bottom up). Our aim is to provide an - let's call it SDK - to build
> highly specialized Unikernels. Such a Unikernel should be specialized
> for (1) your execution target and (2) your application. This means also
> that calling the kernel should be as direct as possible - e.g., just a
> function call. Also the calling path down to the driver should be as
> short and specialized to your application as possible - we want to have
> less abstractions in the middle (although abstractions are not
> completely unavoidable). Third, specialization means also to support
> alternative OS-implementations which you may want to get most benefit
> according to your KPIs (which might be performance or size). This is why
> we build OS functionality as library system where it should be possible
> to replace any component with an alternative.

Thanks for your explanation : )

> 
> >> So, is this trait (wrapping of APIs in libc in unikraft) an
> >> architectural difference from rumprun?
> >>
> >
> > Ahh, I think we have made some mis-understanding. nolibc is just an example,
> > I think we can implement the network APIs in a library name libnet or etc : 
> > )
> >
> > Those above are all my personal understanding, I think Simon can give you
> > an official answer ;)
> >
> >
> 
> We provide nolibc in order to have a lean libC replacement for building
> Unikraft's in-tree libraries. This is useful for developing applications
> and libraries for Unikraft directly. You probably do not need and you
> also do not want to include everything that a complete libC provides.
> However, when you port an existing application this is not what you
> want. For this purpose nolibc is too incomplete. But because every
> library is replaceable, you replace nolibc with something that is more
> complete, like newlibc.
> 

Is the any overlap between newlibc and nolibc? Or rather, do these two
libraries have explicit division? For example, we have implemented string
functions in nolibc, should we have to implement them in newlibc again?

> >>
> >>>
> >>> Regards,
> >>> Wei Chen
> >>>
> >>
> >> Thanks again for all the information and help.
> >>
> >
> > You're welcome, I also benefit much from our open discussion : )
> >
> >>
> >> Thanks and Regards,
> >> Ajay
> >
> 
> Thanks,
> 
> Simon


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