On Wednesday 30 August 2006 14:33, Chuck Ebbert wrote:
> In-Reply-To: <[email protected]>
>
> On Wed, 30 Aug 2006 02:17:28 -0700, Jeremy Fitzhardinge wrote:
>
> > > This changes the ABI for signals and ptrace() and that seems like
> > > a bad idea to me.
> > >
> >
> > I don't believe it does; it certainly shouldn't change the usermode
> > ABI. How do you see it changing?
>
> Nevermind. I thought because you changed struct pt_regs in ptrace_abi.h
> it meant a user ABI change.
I think he broke the ptrace ABI actually in the first patch, but only by mistake
and he promised to fix it :)
>
> > > And the way things are done now is so ingrained into the i386
> > > kernel that I'm not sure it can be done. E.g. I found two
> > > open-coded implementations of current, one in kernel_fpu_begin()
> > > and one in math_state_restore().
Perhaps those should be fixed? Is there a reason they are open coded?
> > >
> >
> > That's OK. The current task will still be available in thread_info;
>
> But they can get out of sync, e.g. when switch_to() restores the new
> task's esp, the PDA still contains the old pcurrent and they don't get
> synchronized until the write_pda() in __switch_to().
But there is neither kernel_fpu_begin nor math_state_restore inbetween.
And I think interrupts are off too.
>
> > To be honest, I haven't looked at percpu.h in great detail. I was
> > making assumptions about how it works, but it looks like they were wrong.
>
> Would it make any sense to replace the 'cpu' field in thread_info with
> a pointer to a PDA-like structure? We could even embed the static per_cpu
> data directly into that struct instead of chasing pointers...
I don't see what advantage it would have. %gs is clearly faster and shorter.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
