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

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

Hey,

On 09.05.2018 08:52, Wei Chen wrote:
> 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?
It depends which string functions you have implemented. You will find a 
complete set of them in newlibc. nolibc is rather incomplete. Both 
libraries overlap in order to have them replaceable but nolibc provides 
only a lean subset.
Which string functions did you actually implement? We could consider 
upstreaming them to nolibc. ;-)
> > > > > 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
Thanks,

Simon

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