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

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

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.
> > 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.
> > > 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
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended recipient, 
> please notify the sender immediately and do not disclose the contents to any 
> other person, use it for any purpose, or store or copy the information in any 
> medium. Thank you.
Thanks,

Simon

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