[Genode] why do I need to rebuild ports for different platforms? was: buid directory outside ...
I said: --- While trying the different 'platforms' (kernels), the build system seems a bit unoptimized. To me, rebuilding libports, ports, gems in each different kernels don't make much sense. I don't expect them to apply patch platform-specifics, only Genode-specifics. So it would make sense to specify two directory on create_builddir: one common for all platforms, and one for the platform. --- Norman replied: That would be cool but it is not possible.
Even though those libraries look like being the same for each base platform, they are different. At compile time, those libraries ultimately depend on platform-specific header files (e.g., the kernel's syscall bindings). So a library built for one kernel will typically not work on another kernel because it would try to call kernel functions in wrong ways. In theory, all those kernel-specific things could be encapsulated in a single kernel-specific library with an interface that hides all kernel details. But in practice, this would be extremely difficult and the extra indirection needed for that would certainly imply runtime overheads. In my opinion, the little added value of such a feature does not justify opening a big can of problems. --- Strange. You made me think if I expect libc to be differently compiled for different platforms. I concluded that I don't expect so.
In fact I expect everything running above Core, to not be platform-specific, including device drivers. Sure, we don't need to build some drivers if the architecture does not have the coresponing hardware, but that does not means it would be compiled differently.
And I definitively *do not* expect libraries to be compiled with specific kernel headers file. I expect libc, device drivers, to call Core the same way, and Core to be compiled in a specific manner for each platform.
Hi Paul,
In fact I expect everything running above Core, to not be platform-specific, including device drivers. Sure, we don't need to build some drivers if the architecture does not have the coresponing hardware, but that does not means it would be compiled differently.
there is a difference between source-level compatibility and binary compatibility. The code of non-core Genode components is independent from the used kernel at source level only.
And I definitively *do not* expect libraries to be compiled with specific kernel headers file. I expect libc, device drivers, to call Core the same way, and Core to be compiled in a specific manner for each platform.
I wonder where your expectation comes from. Do you expect a library compiled on FreeBSD to be usable when copied onto a Linux system? I wouldn't expect this to work (although I never tried .-)
From 10000 feet above the ground, I can perfectly follow your reasoning.
But when looking more closely, it is not that simple. Just consider the following problem. How do you expect a non-core process to "call" core? On Linux, this process uses Unix domain sockets (by issuing the respective Linux system calls). On Pistachio, the process would use the L4-IPC mechanism (by using Pistachio-specific system calls). On NOVA, the process would use NOVA's portal mechanism (by using NOVA-specific system calls). Similar stories can be told about thread creation, process creation, locking, etc. All these things need platform-specific bits that are not solely encapsulated in core but need platform-specific support code in each non-core process.
That said, I don't think that it's entirely impossible to achieve binary compatibility. Maybe you'd like to give this experiment a try? We try to keep the platform-specific bits as small as possible. They are (almost) all contained in the respective 'base-<platform>' directories. If you like to explore this topic, a good start would be to compare the differences of the various 'base-<platform>' repositories, in particular the header files at 'base-<platform>/include'. The ultimate goal would be to completely unify those, and to move all base libraries (the libraries provided by the 'base-<platform>' repositories) into one single shared library per platform.
Personally, I think it is very challenging. But maybe you like such damn hard challenges? ;-)
Cheers Norman
Ok, thanks, this clarify some misconceptions about the IPC I had.
I was finding a bit odd that there was no kind of Interruption, or exact address to communicate for passing messages around.
I was thinking a bit like if all programs were sharing the same address space (I must have been too much exposed to DOS) and that the IPC was merely C++ calls.
-
Norman Feske -
Paul Dufresne