On Tue, 22 May 2007, Michael Schmitz wrote:
> > > I'd like to avoid following in the footsteps of the i386 style support
> > > particularly because it does require more extensive kernel support than
> > > most of the other architectures. I'm still looking over the documentation
> > > and the implementation details of the other architectures, but I'll put
> > > something together as a proposal before I write any code.
> >
> > I think there are two possible approaches. As you know we need per thread
> > data. This can either be in a register, which would be the fastest option,
> > but our current ABI doesn't define one, so it basically means an ABI
> > change to reserve a register for it so it doesn't get clobbered.
>
> Plus we already reserve a register for the current task - we're not all
> that squeezed, but can't we store the per thread data at a constant offset
> from the task address which we already store in a register? Are all
> threads separate tasks at kernel level?
We already reserve a register for the current task in kernel space.
> > The other possibility is to use a memory location, this requires kernel
> > support to update the memory pointer at every task switch (we don't have
> > SMP, so it's a lot easier), but it has the advantage that it's otherwise
> > backwards compatible.
> > IMO the simpler option in the short term is via a memory pointer, an ABI
> > change needs a lot more preparation (although it's desirable in the long
> > term to also fix other things).
>
> Let's focus on the simpler option first :-)
While TLS needs some kind of pointer in user space.
(Of course the kernel has to update the memory pointer at every task
switch).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
