XRP Ninja

Update: It is said that this problem has already been fixed . I will test it later. Actually I intended to send this to LKML, but just before I was about to send I found there was already some discussions about this . So instead I decided to just post it here. To make long story short, please take a look at these two files first: The first file , which will become part of /usr/include/endian.h. This file defines both __LITTLE_ENDIAN and __BIG_ENDIAN. And this file will be included by the second file. The second file , which will be /usr/include/linux/byteorder.h Obviously, this test in the second file will fail: #if defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN) # error Fix asm/byteorder.h to define one endianness #endif It seems that there is an inconsistency between Linux and glibc on handling __LITTLE_ENDIAN and __BIG_ENDIAN. Linux treats them like a flag, while glibc treats them like a value. glibc uses __BYTE_ORDER to determine the endianness. This problem must be

I got a donation of a Lemote Loongson 2F box somewhere around July this year and have been working on it in my spare time since I got it. The other day I made a summary about what I have done so far and posted it on Lemote's bbs. The links is http://www.lemote.com/bbs/viewthread.php?tid=20134 My work involves toolchain, kernel, xorg-server MIPS or Loongson support and userland library/application gcc 4.4 patch. The most prominent achievement so far is an N32 ABI stage3 (well, actually just a tarball, not made using catalyst) optimized for Loongson 2F with MIPS PLT support. It is actually not that easy as you would've imagined, N32 has many problems as you can see from the above posted link. I posted it on Lemote's bbs along with some instructions of how to use it: http://www.lemote.com/bbs/viewthread.php?tid=20125 According to some testers, performance of some applications in this system has an up to 30% increase comparing with the performance of the same apps in system Usi