Ingo Molnar <mingo@xxxxxxx> writes: > I agree with Linus's notion in this thread though, a core kernel change should > generally not worry about hooking up rare-arch system calls (concentrate on the > architectures that get tested most) - those are better enabled gradually > anyway. The way I read it he was complaining about my having parisc bits and asking for my branch to be merged before the parisc bits had been merged. Which I credit as a fair complaint. If I am going to depend on other peoples trees I should wait. At the same time when I am busy looking for every possible source of trouble and putting code into net-next to detect pending conflicts, and when maintainers complain when I ask for review that my patches conflict with their patches. Being a contentious developer I am inclined to do something. Now that the reality has sunk in that it means waiting for other peoples code to be merged before I request for my changes to be merged I don't think I will structure a tree that way again while I remember. > Also, system call table conflicts are trivial to resolve. Merging in net-next > to avoid such a conflict is like cracking a nut with a sledgehammer. Well I still have trauma from how nasty it was to test with syscall numbers continuing to change when I was working on the kexec_load system call. As far as I can tell any one system call conflict on any one architecture is easy to resolve. Resolving a conflict on all architectures would amount to at least 50 files that need to be resolved that feels a bit more than trivial. My gut feel says we should really implement an include/asm-generic/unistd-common.h to include all new system calls. That way there would be only one file to touch instead of 50. Certainly it works for include/asm-generic/unistd.h for the architectures that use it. And all we really need is just a little abstraction on that concept. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
