On Tuesday 13 November 2012 04:07 PM, Arnd Bergmann wrote:

On Tuesday 13 November 2012, Gilad Ben-Yossef wrote:

quoted

So, I completely agree about not adding more deprecated system call or
ABIs (thinking about the ptrace regset issues in another patch in the
same patchset), but on the other hand I have to wonder if having a
port in the tree that doesn't have a working C library or a debugger
makes sense.

I mean, it is not quite the same thing as saying: "well, users of the
old versions of the user tools will need to maintain out of tree
patches". That makes sense - it puts the burden of maintenance on
people clinging to new versions when newer one exists, but this is not
what is happening with Arc. Right now, there are no working version of
the tools for Arc, so everyone will need to use the out of tree
patches.

I wonder what is worse - having an in tree port that no one (can) use
or adding some deprecated crap (sorry...), clearly marked for deletion
the minute a version of the relevant user tools exists that can be
used with the new mechanisms?

The point is that all existing users already need to rebuild all their
user space since the upstream version is using the generic system call
numbers. What I want to avoid is breaking everything twice, and the most
logical point to do that is when moving from an out-of-tree kernel fork
to the mainline version.

I completely agree.

If mainline doesn't work for you yet, the most logical choice is to
stay on whatever kernel you have working right now, and only change
over to the upstream version once it works with an ABI that we want
to maintain in the long term. Obviously I can't stop from using a
mix of the two while you are waiting for (or working on) getting
gdb and uclibc supported with the new interface, but my recommendation
is not to ship that in products to end-users that would suffer
from another ABI change later on. 

What I'm trying to enforce here is that the upstream version follows
the exact same rules that we apply to all other ports, which is
that we don't break existing user space that was running with an
older upstream kernel.

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.

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 ?

-Vineet