|Subject:||Re: RE: [lwip-devel] Curious struct packing issue - is it GCC?|
|Date:||Tue, 28 Apr 2009 18:26:40 +1200|
Simon Goldschmidt <address@hidden> wrote:
Bill Auerbach <address@hidden> wrote:Things in headers will be u16_t aligned.Are they? I didn't recognize that. But if so, I guess you're lucky about the protocols that they don't use bytes...The once place we SMEMCPY to a header is the netif mac address which wasn't aligned.As I wanted to say at the end of my last mail: For now, it is like that, but it could well be that this changes in the future - If we ever need to copy a small amount of bytes that are unaligned, we would use SMEMCPY, too!Shouldn't we do what we can so we're not using memcpy to copy 4, 6, or 14 bytes?Of course, and that's why SMEMCPY was introduced and we are right now discussing about optimization :-)It would be nice if the hwaddr could be aligned (u16_t) if one wanted the inlined SMEMCPY moving u16_t's.I thought about that, too. For ethernet this is OK, but I don't know about other networks that use netif->hwaddr. What's left as protocols there anyway aside from ethernet? PPP? SLIP? They don't use DHCP, do they?
Neither PPP nor SLIP uses hardware addresses. They are both used for point to point connections via a serial connection (or something pretending to be one), so no addressing is required below the IP layer.
PPP has its own mechanism for assigning IP addresses between the peers, which doesn't involve DHCP.
SLIP traditionally runs with fixed IP addresses for both stations. It only defines a method of adding framing boundaries to IP and can't work with anything like DHCP.
I expect both PPP and SLIP would end up with 4-byte aligned IP headers for receive data, as far as LWIP is concerned, because the serial data stream has to be decoded and processed a byte at a time to remove byte padding, and that procedure would also strip off the PPP or SLIP framing, leaving just a bare IP packet to be copied into pbufs.
|[Prev in Thread]||Current Thread||[Next in Thread]|