On Thu, 1 Jul 2010, Jamie Lokier wrote:
> Tony Lindgren wrote:
> > +static void __init kuser_get_tls_init(unsigned long vectors)
> > +{
> > + /*
> > + * vectors + 0xfe0 = __kuser_get_tls
> > + * vectors + 0xfe8 = hardware TLS instruction at 0xffff0fe8
> > + */
> > + if (tls_emu || has_tls)
> > + memcpy((void *)vectors + 0xfe0, (void *)vectors + 0xfe8, 4);
> > +}
>
> Just a little opinion: Perhaps has_tls_reg would be a clearer name.
> All variants "have TLS" after all.
Good point.
> Also - and this isn't directly related to your change so feel free to
> ignore it - wouldn't it make more sense for the tls_emu case to use
> the memory version (and update the memory location), so that even on
> tls_emu systems, user programs which call the kuser code will run faster?
> With that change, there would be no real penalty to enabling tls_emu
> for any system that finds it useful.
No, that's not possible.
The tls_emu case was created to allow SMP system without the actual
TLS register to still work. With SMP you cannot rely on a global memory
location to hold the TLS value. And because such systems are so
"unusual" it was simpler to just do as if the TLS register was there and
then emulate it within the instruction exception handler.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
