Re: [Minios-devel] [UNIKRAFT PATCH v2 8/8] lib/uksched: Minor refinements

[Costin Lupu <costin.lup@xxxxxxxxx>]

Hi Florian,

On 1/23/19 4:15 PM, Florian Schmidt wrote:
> Hi Costin,
> 
> my suggestion for this patch would be to actually split it. All those
> things are more or less independent, and while each patch would then be
> very small, I think it's better to have conceptually different code
> changes in separate commits. That way you could also add some short
> description about the why's of the patches. For example, why the
> schedulers should set the scheduler reference on the thread instead of
> thread adding logic, or why uk_sched_start should be public.
> 

v3 will have these split in separate patches.

> Also, I'm not sure I understand the reent part. The REENT_PTR gets
> initialized, but then never used? Is this strictly for the _r functions
> of newlib? And what happens if you don't add this? I have to say I'm not
> a huge fan of having code that deals with external libraries in the main
> unikraft code base, but I'm open to arguments.

In deed, I forgot to copy the __getreent function from minios [1] which
returns the reference to the REENT_PTR of the current thread.

And yes, it's for the reentrant functions of newlib.

To continue answering to your questions, reent structure isolates the
current thread context (e.g. it also contains the errno for the current
thread). It's a way of communicating the thread context between the
library and application [2].

It's true I didn't find it elsewhere, not in musl or glibc. So what do
you advise on this one?

[1]
http://xenbits.xenproject.org/gitweb/?p=mini-os.git;a=blob;f=sched.c;hb=HEAD#l151
[2]
https://www.embedded.com/electronics-blogs/industry-comment/4023922/Embedding-GNU-Newlib-Part-2

Costin

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