Debian Guts Support For Old MIPS CPUs

[tuxd3v]

You're arguing stuff you admitted you don't understand, and instead of responding to my points, you're continuing to argue the points that you want.

I already responded to all of your points about network byte-swapping functions, multiple times. If you cannot follow the plot, that's your problem.

Well,
I think that you have a very good skills on subverting the things we were talking at..

I will cote for you again..

There are byte swapping libraries which are included with most C/C++ libraries. The most commonly used routines are htons() and ntohs() used for network byte order conversions. The host to Big/Little Endian routines (htobe16()/be16toh(), etc) are more complete as they handle swaps of 2, 4 and 8 bytes. These routines are platform independent and know that a swap is only required on Little Endian systems. No swapping is applied to the data when run on a Big Endian host computer as the data is already in "network byte order".

[coder]

You can pass the network problem to an adaptor, to an accelerator, or something else, but it will not cease to exist, because you are offloading it.. it his still there, and consuming power..

If you have to execute additional instructions for it, then swapping means consuming power. However, in actual ASICs, swapping is free. At that level, it's just wires.

Furthermore, not all operations require swapping for every packet. For instance, comparison for equality doesn't need swapping, if you compare it against a pre-swapped value. Similarly, certain lookups can operate on different endian, because it's just an opaque value. Populating certain fields can also be done using pre-swapped values.

You act like every byte in or out of a network adapter needs to be swapped, which is far from the truth.

[coder]

What's my point?
RTFM, go to the RFC and read it again to find my point..

No, I think you don't even understand what that RFC is actually saying. You just took the first RFC you found that said anything about network order.

Some people prefer BE, some prefer LE, both have pros and cons..
I brought the network problem,
Because its the one that really differentiate both.. apart from it, "its like religion.."

I like more the BE way, to be honest, it feels more natural for me..
Others will look into it, and prefer LE..
There are always trade offs,

The network problem is the one I think, can be discussed,
Because the rest again, "its like religion.."

We've been through the same points about networking again and again. There's no real meat on those bones, or else the industry wouldn't be turning away from BE.

Call it a matter of religion and a matter of preference means you don't have a logical argument. At least we can agree on that.

[coder]

...
Doesn't you know about checksum'ing?
How it works?, you should, on that article may speak about it..

Have you ever read about the functions needed in LE to convert data( yes, they are used, only for code portability, but in BE they do nothing )..?
You should, and its not non-sense..
You are the one not recognising that BE in inherently more efficient to network stuff..

You're arguing stuff you admitted you don't understand, and instead of responding to my points, you're continuing to argue the points that you want.

I already responded to all of your points about network byte-swapping functions, multiple times. If you cannot follow the plot, that's your problem.

[tuxd3v]

yes, it'll never end
Each architecture has its pros and cons, and so do big and little endian. However there are more advantages to use little endian than to use big endian. In fact what you're arguing about network serialization is pretty much nonsense nowadays, since the network adapters can already put the bytes in the correct order without help from the CPU
If you're saying big endian allows faster sign checking then it's the same as saying little endian allows faster parity checking, since by reading just the first byte we'll know the number is odd or even right away. And little endian is far more suitable for mathematics which is generally done from the least significant part (except some operations like division)

In fact the designers of RISC-V architecture also said that:

I understand it,
But the network problem is really the one separating both formats..

You can pass the network problem to an adaptor, to an accelerator, or something else, but it will not cease to exist, because you are offloading it.. it his still there, and consuming power..

This are the biggest difference for me, the rest "is religion.."

[tuxd3v]

No, it's the Assigned Numbers RFC. And what's your point?
You called it a never-ending religious war.

What's my point?
RTFM, go to the RFC and read it again to find my point..

Some people prefer BE, some prefer LE, both have pros and cons..
I brought the network problem,
Because its the one that really differentiate both.. apart from it, "its like religion.."

I like more the BE way, to be honest, it feels more natural for me..
Others will look into it, and prefer LE..
There are always trade offs,

The network problem is the one I think, can be discussed,
Because the rest again, "its like religion.."

[tuxd3v]

This is complete BS. The lower layer doesn't know or care what the application layer is sending. It doesn't byte-swap any of that.

...
Doesn't you know about checksum'ing?
How it works?, you should, on that article may speak about it..

Have you ever read about the functions needed in LE to convert data( yes, they are used, only for code portability, but in BE they do nothing )..?
You should, and its not non-sense..
You are the one not recognising that BE in inherently more efficient to network stuff..

[coder]

NO,
TCP/IP uses it, it goes till L7 in OSI..

What I was replying is that,
Maybe you can try a different protocol above TCP/IP Layer, but I don't know how it would play, at network level..
It needed to be carefully studied..

If you don't know, then stop arguing!

[coder]

If you rely on the network, the mount of work will be in triple for you..
Since you are packing in LE, then you need to do exactly that for BE, including checksum'ing and so on..
So you need to unpack( LE to host format data ), and repack again( host format data to BE )..

1. Pack Host data, in LE format
2. Unpack LE to Host Format Data( Again , like before 1. )
3. Pack Data to BE to send..

It would be three times the work..

This is complete BS. The lower layer doesn't know or care what the application layer is sending. It doesn't byte-swap any of that.

[tuxd3v]

The higher layers constitute the packet payloads, which is the vast majority of the data. That stuff is opaque to the lower layers and not subject to its endian-ness. The stuff you're talking about is just lower-layer packet headers. So, a very small minority of the actual bytes.

NO,
TCP/IP uses it, it goes till L7 in OSI..

What I was replying is that,
Maybe you can try a different protocol above TCP/IP Layer, but I don't know how it would play, at network level..
It needed to be carefully studied..