|> From: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
|> Date: 07 Oct 1998 11:09:08 +0200
|>
|> The NIPQUAD makro is broken on big endian machines. The argument is a
|> number in network byte order.
|>
|> Now it is slow as shit on little endian, what is your point with this
|> patch?
My point is to make it work, nothing more and nothing less. Of course, it
doesn't *have* to be slow on little endian if the ntohl macro is properly
written so that gcc can combine the shifts inside and outside of it.
|> Linus isn't going to accept this, and I know why. Why not define it
|> conditionally based upon endianness, changing the shifts and masks to
|> match, instead of unnecessarily bloating things with ntohl()
|> etc. calls in one case for the sake of correctness on another?
The use of ntohl makes things clear that NIPQUAD expects its argument in
network byteorder. The correct fix is of course to switch to a cpu with
the One True Byteorder. :-)) Ok, for those who cannot do that, here's an
improved patch:
--- linux/include/linux/kernel.h.~1~ Wed Oct 7 11:06:36 1998
+++ linux/include/linux/kernel.h Wed Oct 7 12:44:56 1998
@@ -10,6 +10,8 @@
#include <stdarg.h>
#include <linux/linkage.h>
+#include <asm/byteorder.h>
+
/* Optimization barrier */
#define barrier() __asm__("": : :"memory")
@@ -68,11 +70,19 @@
* Display an IP address in readable format.
*/
+#ifdef __LITTLE_ENDIAN
#define NIPQUAD(addr) \
(int)(((addr) >> 0) & 0xff), \
(int)(((addr) >> 8) & 0xff), \
(int)(((addr) >> 16) & 0xff), \
(int)(((addr) >> 24) & 0xff)
+#else
+#define NIPQUAD(addr) \
+ (int)(((addr) >> 24) & 0xff), \
+ (int)(((addr) >> 16) & 0xff), \
+ (int)(((addr) >> 8) & 0xff), \
+ (int)(((addr) >> 0) & 0xff)
+#endif
#endif /* __KERNEL__ */
-- Andreas Schwab "And now for something schwab@issan.cs.uni-dortmund.de completely different" schwab@gnu.org- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/