Chuck Ebbert wrote:
This patch implements per-processor data areas by using %gs as the
base segment of the per-processor memory.
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?
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().
That's OK. The current task will still be available in thread_info;
this is needed for very early CPU bringup anyway, before the PDA has
been set up. The vast majority of "get current task" operations can be
swept up by changing "current" however.
Can you describe what it is about the way things work now that
prevents dynamic allocation?
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.
J
-
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]
