On Tuesday 13 November 2012, Gilad Ben-Yossef wrote: > 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. 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. 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
