Re: RE: [lwip-devel] Curious struct packing issue - is it GCC?

[David Empson]

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.