Hi All, >>> How about this strategy then: >>> * Change all the data types and syscall numbers in the -for-2.6.27 >>> branch to only include the minimal set, and a modern ABI >>> * Add the old interfaces as an out-of-tree patch that adds source >>> level compatibility with the old libc, but does not modify any >>> of the new interfaces, so that a patched kernel can run all binaries >>> built for the upstream version. >>> * phase out the old source interface gradually, as all users update >>> their libc source code. >> >> >> Any news on this from the microblaze people? Have you made up your mind >> on what route you want to go? > > I think we're still digesting it. I need to sync up with Michal and the > Xilinx people. The libc and kernel API changes have to happen in > tandem, otherwise Michal can't properly test the kernel he's pushing. > > I am the defacto MicroBlaze uClibc and toolchain "builder" but somewhat > reluctantly - am trying to convince Xilnx to hand that over to someone > who is expert at it. > > Michal, John L, any thoughts? > > John I am convinced we need to change syscall table. I don't want to maintain old syscalls. It will be easier to test smaller amount of syscalls. I would like to talk about with you (John W) via Skype. (Can you send me private email where you have time?) I talked with Steve about this week. After that I will publish our proposed way. Michal -- 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
