On Mon, May 05, 2008 at 11:15:11AM -0600, Kurt Mahan wrote:
From reading the discussion it appears that Joseph's proposal of using the VDSO approach was questioned and alternatives such as the ARM Magic page were looked at but that VDSO still seems to be the way to go. Is this agreed or should alternatives be looked at? If this isn't the direction the community finds acceptable let's attempt to resolve it. I've been working on a VDSO implementation (very early stages) to use with CodeSourcery.
It seemed to me that the ARM style magic page is the simpler option, but it has some serious pain points. The only issue with the VDSO seemed to be how to do it in a way that allowed sharing the whole thing but still having clean access to the per-thread pointer that is really kept in the kernel. It's kind of messy to handle both copy-on-write for GDB debugging of code in the VDSO while still updating a pointer on context switch the way ARM does with the magic page. My suggestion is to go with the VDSO. It will be more complicated, but it's got enough positives that I think it will be worth the effort. I'd love to look at some code and would be more than willing to comment and make suggestions. I did think of one way to handle this that may be relatively logical, but it requires a few hooks and needs some comment. The basic idea is to put two extra pointers into the thread in the kernel. One would be the TLS area as set by user-space. The other is a pointer to the page that is currently seen by that thread as the VDSO page that contains the location where the VDSO will look for the TLS pointer. In the mm code, we check on the copy to see if we are copying and replacing the page that is held as the special VDSO page and update the pointer in the thread to the new page. A context switch would always write the value in the TLS save slot in the thread to the page referenced in the thread structure as the VDSO thread. It does mean that the VDSO page(s) must never be swapped out. Any comments on this idea? Could it work? Is there a way we could make the VDSO swappable without breaking the code in the context switch? Brad Boyer flar@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
