Re: [RFC PATCH v1 14/31] ARC: syscall support

[Vineet Gupta]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/