On Fri, 11 Apr 2014 14:15:15 +0200, Richard Cochran wrote:
> > +typedef uint8_t eth_addr[MAC_LEN];
>
> Nit: I don't like this typedef for the reasons explained in the kernel
> CodingStyle.
I don't like it either but the other option was
struct eth_addr {
uint8_t addr[MAC_LEN];
};
which I liked even less. I actually had it this way in an earlier
version of the patchset.
The third option would be just open coding uint8_t foo[MAC_LEN]. Works
for me but we'll probably lose some type checking.
> Also, I did not really understand why this change is needed.
I need to have a separate source address in raw_send for patch 4, as
the destination address can come from outside of the raw transport
code. And I need to return the destination address(es) by
raw_default_addr, thus converting all of them to struct address seems
to be the cleanest way. But even without the conversion, the separation
of the addresses is needed.
Jiri
--
Jiri Benc
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
