On Thursday 15 November 2012 06:05 PM, Arnd Bergmann wrote: > On Thursday 15 November 2012, Vineet Gupta wrote: >> So the primary concern here is not breaking the userspace ABI - right ? >> >> For syscalls I agree that we will indeed need to fix the ABI - by fixing >> uClibc. And if uClibc doesn't merge the fixes we can stay out of tree >> for uClibc - as we currently already are. > > I'm sure we can find a solution for uClibc. We already have seven > architectures using the generic syscalls, including at least one > (arm64) that is going to run on a large number of installations > in the future. > >> For gdbserver, the kernel provides the complete regset ABI. However it >> also provides a very limited version of old ABI - i.e. ptrace with >> PEEKUSR/POKEUSR. Note that latter is just a shim layer and it reuses the >> regset callbacks. This allows us to support the legacy gdbserver. If and >> when gdbserver upgrades it can switch over to new interface. So all >> along there will be NO ABI breakage at all. The cost is couple extra >> functions in kernel which we might have to maintain for some foreseeable >> future. Agree ? > > It's more a question of principle. The rule is that we don't break user > space, and ptrace is just another user space interface is this. If > we merge it now, we will keep it around forever, taking it out later > is not an option IMHO. My preference would be not to merge the backwards > compatibility layer for ptrace at all, but I'm willing to listen to > other people that support your view if you want to keep it. In one > way, ptrace is less critical than the other system calls, and that is > because it's already architecture specific. > > Arnd > OK as of now the legacy syscall ABI and ptrace PEEKUSR/POKEUSR are taken out of submissions tree - we'll carry these out-of-tree for sometime before eventually moving to newer uClibc/gdbserver which don't need these O-O-T patches. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
