Farid Hajji wrote: > > [Sorry to mail to both lists, but the topic _is_ relevant in both cases. > BTW, could we _please_ reunify both lists?]
Actually, I think this is more appropriate to bug-hurd anyway (which is the actual development list). > Abstract: The following mail contains a proposal, discussion and technical > description on implementing binary compatibility of the Hurd to > binaries compiled for Linux-, *BSD- or other OS, without the need > to recompile those binaries from scratch. With binary compat., > the Hurd servers can be installed in an existing OS distribution > as a simple package and would be ready-to-run. Wow! You have given this a lot of thought, and this is really a good proposal. However, a smaller problem can be solved a lot easier, and this might be a good first step towards your more complete solution. The Hurd GLibC has a special property: It has almost the same interface as the Linux GLibC, because it comes from the same source tree. I say almost, because there are mainly two things standing in the way of full compatibility: 1. The Hurd uses stdio, while Linux uses libio. 2. The Hurd does not have pthreads. Those are the two main items I know. The idea was to implement pthreads for the Hurd, and then make both changes in a bunch. This will give us ABI compatibility with the Linux glibc. So, Linux binaries which don't use syscalls direclty, but only exported interfaces in glibc and other user libraries will work on the Hurd without any emulation, because we use the same object format, the same ABIs etc. Only for direct use of syscalls we would need the syscall trap and emulation you explain in your proposal. Of course, this only is for recent linux binaries, and not for BSD or older stuff. But I think it is already tremendous useful, and comparatively easy to achieve, because you don't need to emulate any syscalls. Thanks, Marcus
