Re: [Minios-devel] [UNIKRAFT PATCH 2/4] lib/uksched: create and delete thread-local storage area

[Costin Lupu <costin.lup@xxxxxxxxx>]

Hi Florian,

On 5/22/19 5:18 PM, Florian Schmidt wrote:
> Hi Costin, Simon,
> 
> regarding the location of include/uk/arch/thread.h:
> 
> First of all, I don't care whether it's called thread.h or tls.h, I'm
> happy to name it tls.h for now, and then, if we add further thread
> switching stuff to it later, we can always rename it at that point.
> 
> However, regarding the location, I've been thinking about this a bit
> again, and I see three suggestions on the table right now (tell me if
> I'm missing one):
> 
> 1) Putting thread.h into plat/common/include/x86
> 
> 2) Putting thread.h into include/uk/plat
> 
> 3) Putting thread.h into include/uk/arch
> 
> My original understand was that Costin's suggestion was to go for 1),
> and I said I don't care too much either way. However, now that I thought
> about it: that won't work, because libraries can't access headers from
> the plat/ hierarchy. So if we wanted to put the code there, we'd have to
> "punch a hole" into the separation between lib/ and plat/ by adding
> plat/common/include explicitly to the include path of uksched. That
> sounds like just calling for trouble and establishing a precedent that
> might come to haunt us.
> 

This is not an unprecedented situation, it was done before. It is true
that 'plat/common/include/' has headers which should be used only by the
platform code. However, 'plat/common/' has code that also implements
interfaces from 'include/uk/plat/'. So, if there is functionality that
needs to be implemented in plat/ but also accessed by libs then you have
to add an interface for that in 'include/uk/plat'. That was also the
case for context switch abstractions we are using now in Unikraft. So
there is no need for punching a hole, you should just use interfaces.

> That leaves 2) and 3). I don't think 2) makes any sense, because
> thread.h contains three functions, all three of which are
> architecture-specific and none of which are platform-specific. So, after
> all, I think 3) makes the most sense, which is where they are now in v1.

So if you have functions the should be exposed and used by libs then 2)
isn't such a bad idea.

I am repeating myself, but I had these same arguments that favor putting
arch code in arch/ when I worked on the scheduling changes (which I
remind you that needed refactorization of both KVM and Xen code). So
instead of using arch/, Simon was strongly for using plat/. It's the
same situation with your changes. Now, if we are already on this path,
and another refactorization is planned, the consistency is what should
matter here. Keeping the same schema will help in finding the next best
one when refactoring.

Cheers,
Costin

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