Re: [Minios-devel] [UNIKRAFT PATCH 0/3] Introduce posix-crypt internal library

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

Hi Costin,

as discussed offline, I think that if a program requires a libc with 
crypt functionality, it is bound to a libc that provides it. This is 
similar as the status quo in Linux, today. In this case, newlib is 
incompatible. In order to make it compatible, newlib would need to be 
extended - so I think it feels more correct to add it there.
As I understand the reason of putting libc/posix functionality into 
Unikraft base was only related to common glue code. This code was coming 
from us and would affect most or all libc implementations we have. I 
think using the base repo to complete incomplete libc implementations is 
something else. If we want to do this, the correct way would then be to 
put in much more stuff: We have nolibc which is also "incomplete". But I 
think we shouldn't do this because this would imply that we would need 
to maintain much more code which is not ours.
If the concern is about having this functionality soon for porting 
applications: We are about to release a first working musl port soon. 
I'm currently preparing a related patch series that enables glueing 
musl's system calls directly to Unikraft. I can imagine that we will 
start using musl instead of newlib soon as it is out.
With this in mind: I prefer putting posix-crypt to newlib or as a 
separate library.
Thanks,

Simon

On 27.11.19 10:16, Costin Lupu wrote:
> On 11/27/19 10:43 AM, Simon Kuenzer wrote:
> > Hey Costin,
> >
> > thanks a lot for your work. Could you also add a message why providing
> > `crypt` and `crypt_r` with the Unikraft base repo is needed? E.g., are
> > there any common and shared modifications needed for supporting libc
> > implementations or is there an internal direct dependency? If not, I
> > prefer to avoid introducing us maintainance effort for copies of code
> > that is usually provided with a libc. In the latter case I suggest to
> > introduce posix-crypt as external library.
> Hi Simon,
>
> We need crypt/crypt_r with newlib which doesn't implement them. The
> alternative would have been to put the code into newlib's glue code. But
> then, what happens with other libc implementation which doesn't provide
> crypt? We would have to copy it there as well, right?
>
> With this approach I think the maintenance effort is reduced when adding
> it into Unikraft. And I think it's even less effort compared with making
> it external, which would have to be cloned separately. Btw, would crypt
> have original code?
>
> Cheers,
> Costin
>
> _______________________________________________
> Minios-devel mailing list
> Minios-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/minios-devel
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel