Am Dienstag, den 11.03.2014, 10:09 -0700 schrieb Linus Torvalds: > On Tue, Mar 11, 2014 at 9:50 AM, Andy Lutomirski <l...@amacapital.net> wrote: > > Looking forward, would it be reasonable to have an extensible set of > > flags that live in the ELF interpreter's headers somewhere > > No. Not reasonable. The whole "32-bit x86" and "looking forward" > combination makes absolutely zero sense. > > I can pretty much guarantee that even *phones* will be 64-bit if/when > x86 ever gets there. They'll need it just for ARM emulation, I bet. > > So 32-bit x86 is dead, dead, dead. There's absolutely no future to it. > We're not adding new stuff to "future-proof" it. >
Quite frankly this sounds like the mad scientist in an old marvell comic: "dead, dead, dead". Is it possible to calm down and get a more technical discussion rather than blaming and treats not to accepting patches? Can we also stop this hard words like "WTF". I don't like this style and other developers too, especially women. 32-bit is not dead. I think 98 percent of all computers running linux are embedded devices and a lot of them are not capable for 64 bit support. So its your opinion, but there a also developers not sharing this. For me i still work with old Celeron Pentium III devices. And the life time of this device will end in 7 years. A lot of peoples (also main kernel hackers) ask me to do this patch because the time functions in 32 bit kernel mode are so slow compared to a 64 bit linux. And as i can see most of the involved kernel developers are not opposite against this patch. The other side is that many embedded developers use hand crafted time functions using TSC or similar to get a fast time functions, but did not know the pitfalls (C- and P-States) to handle this in a right way. So a reliable way is to use the kernel functions, because the kernel knows the state of the CPU and always returns the correct time. But this will result in a slow down of the application, which generates latency. We use this kind of patch for a long time and it decreased the latency of our applications notable. The current solution is quite clean, but there was a issue with the size of the vDSO which not fits into one page by some kernel configurations. There is a solution for this to #undef CONFIG_OPTIMIZE_INLINING and CONFIG_X86_PPRO_FENCE in arch/x86/vdso/vdso32/vclock_gettime.c. To prevent issues which future kernel releases, we have now two ideas to solve this: One ist Andy's kick ouf of the compat VDSO. For this there is already a patch there. And the other one is (thanks to Andys archeology investigations) to increase the size of the vDSO fixmap space which has according to Andy no side effect. This can be done in a very clean and easy way. The code is still there, since the fixmap area is not fix: Lguest, XEN, OPLC and the reservetop will move the fixmap during boot, so we can easily get additional space by fixing __FIXADDR_TOP. I will write a patch for the later one. - Stefani -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
