Re: Assignment of GDT entries

[Jeremy Fitzhardinge]

Mikael Pettersson wrote:
>  >  Changing the API 
>  > to use abstract "TLS indicies" would also require a call to return the 
>  > "TLS base", which hardly seems like an improvement.
>
> The TLS base can obviously be zero.
>
> User-space asks to access TLS #n (for allocs #n can be -1).
> The kernel maps that to GDT index #m.
> The kernel stores #m in the user-space buffer.
> User-space maps #m to a selector.
>   

I'm missing why this is a substantial improvement over the current 
interface (or functionally different at all).  What does this proposal 
let you do that the current one doesn't?

> Look, I'm not saying the current API is perfect, far from it. But it does
> have valid usage modes which are broken in x86-64's ia32 emulation, and
> will break on i386 of you reallocate the TLS GDT indices. This is a fact.
>   

Hm, well its a "fact" in that they use different segment descriptors, 
but you'd be hard pressed to say that was a breakage.  set_thread_area 
was added in 2.5.29 (Jul 2002), and x86-64 added support in 2.5.43 (Oct 
2002), so the current behaviour is pretty much as it has always been.  
If you have a program that expects something different, you either wrote 
it in Jul-Oct 2002, or you made an unsustainable assumption about how 
set_thread_area() works.

> Look, I'm not saying the current API is perfect, far from it. But it does
> have valid usage modes which are broken in x86-64's ia32 emulation, and
> will break on i386 of you reallocate the TLS GDT indices. This is a fact.
>   

You seem to have a specific use-case in mind; do you have a program 
which would like to use a new interface?  Would you mind spelling it 
out, and describe why the current interface doesn't work for you?

   J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/