Is there a reason for so many MAC formats?

[interactive-matter]

While browsing through the source and the demo source I have encountere three different formats for MAC addresses in the source code: 6 characters 6 int 2 int

Is it useful? It always puzzles me which format to use and how to reformat the mac address. Or am I missing something completely.

[DavidNorman]

The 2 int version is the internal storage which is done so that we can be sure of the alignment of the address. The 6 char is the external representation which sort of is how you would think of a mac address as a general user, i think.

i'm not sure what the 6 int is about - maybe an error

[ajwlucas]

There's probably a few reasons for the disparities between formats. One format might be suitable for reading from OTP, another might be more suitable for sending down a channel end (it's more efficient to send 2 ints than 6 chars or ints). Another might need to be endian reversed in a char buffer for sending over the network.

I agree it can be confusing and we should probably try to provide some sort of wrapper that uses a common format that maps to the function-specific format.

[interactive-matter]

Yes,

I am with ajwlucas theory. It seems the same to me. for passing the MAC in function references often 6 ints are used. It is often packed into 2 ints. In reality it is 6 chars.

I suggest for future version to simlpy stick to the 2 (unsigned) int and streamline all function calls to this.

It is short, easy to store and simple. Perhaps in a format that it can be easily transformed into a 6 (theoretically 8) byte array.

Just a feature request to make the source more easily accessible

[interactive-matter]

Suggestion: Is it possible to convert all external references to the MAC address to 8 unsigned chars? This format is most commonly used and is easily mappable to 2 integers. In theory only 6 bytes need to be stored, but that would bring some alignemnt problems (At least as far as I understand it - if I am wrong I am happy to be corrected). All functions give and take those 8 unsigned chars. If the send it over a channel or store it internally the functions can internally map it to two integers. This would massivley reduce the complexity of mac handling.

And while we are at it I managed to confuse how the server handles the mac address. It expects a two integer array, build by mapping the 6 chars into it. And it even provides a function to retrieve the mac via it's communication channel. I think those aspects could be better documented since I assumed that I have to read the mac adress from the OTP several times or copy it into different arrays - even though it can be easily obtined from the ethernet server, which seems to be the proper way.

[DavidNorman]

You are correct. The way to get at the MAC address post initialization is to use the tx_server channel and the get function. It only needs to be retreived from the OTP once at initialization time.

I think that having an 8 byte MAC address would be confusing, since it is really only 6 bytes long, and it wouldn't be immediately clear what the endianness or alignment is.

[interactive-matter]

Yes, but having several different formats depending on the function is not helping either ;) perhaps some struct with padding could help, like

typedef struct { unsigned char mac_address[6]; unsigned char padding[2]; } s_mac_address

or something similar. I think one of the biggest issues of the ethernet stack is taht it's API is really hard to understand. Hence I think it should be simplified. (To help, I am trying to extract a more or less generic handler from the demo code which can be the starting point of a very simple API)