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 -- 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
