On Fri, Apr 11, 2014 at 01:50:37PM +0800, Arnold kang wrote:
> Dear Richard,
>thanks for your reply. as i asked ,my linux kernel is 3.0, and
> my phy is DP83640, and my mac is stmmac, and my cpu is arm A9,
Where did you get your kernel?
I guess you have out of tree patches, right?
>
Dear Richard,
i get my kernel from my chip vendor， yes, the mac driver is modified by
them. maybe this is why the kernel crashed. but i really don't understand
what* skb_tx_timestamp() *mean. i search in google, there is no answer，
and there is no prototype in kernel or other use in kernel cod
On Fri, Apr 11, 2014 at 04:07:02PM +0800, Arnold kang wrote:
> Dear Richard,
>i get my kernel from my chip vendor， yes, the mac driver is modified by
> them. maybe this is why the kernel crashed. but i really don't understand
> what* skb_tx_timestamp() *mean. i search in google, there is no a
Dear Richard,
thanks your help
2014-04-11 17:26 GMT+08:00 Richard Cochran :
> On Fri, Apr 11, 2014 at 04:07:02PM +0800, Arnold kang wrote:
> > Dear Richard,
> >i get my kernel from my chip vendor， yes, the mac driver is modified
> by
> > them. maybe this is why the kernel crashed. but i
As sugested by Richard, introduce a common address struct and let the
transports use it. I chose struct sockaddr to hold the actual address
contents, as it allows to store also an UDP port.
No functional changes by this patchset, just code refactoring. Tested with
UDPv4 E2E and P2P, UDPv6 E2E and
Signed-off-by: Jiri Benc
---
raw.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/raw.c b/raw.c
index 795292fab358..2afe8a25f85a 100644
--- a/raw.c
+++ b/raw.c
@@ -102,14 +102,14 @@ static int raw_configure(int fd, int event, int index,
mreq.mr_ifindex = i
This modifies all transports to use a new common address type, struct
address. This address is stored in a ptp_message for all received messages.
For sending, the "default" address is used with the default sending
functions, transport_send and transport_peer. The default address depends on
the tra
The callers of those functions are all using ptp_message. As we're going to
return more information (the address), let those functions just fill in the
ptp_message fields directly.
Some minor reshuffling needed to prevent circular header dependencies.
Signed-off-by: Jiri Benc
---
msg.h|
Also, document transport_send, transport_peer and transport_sendto usage.
Signed-off-by: Jiri Benc
---
transport.c |8
transport.h | 33 +
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/transport.c b/transport.c
index 25d569607f71..
In order to be able to convert to a generic address struct, separate source
and destination address into separate fields.
Signed-off-by: Jiri Benc
---
ether.h | 13 ++---
raw.c | 22 +++---
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/ether.h b/e
On Sat, 5 Apr 2014 12:40:20 +0200, Richard Cochran wrote:
> Let us introduce a struct to hold addresses, something like:
>
> struct address {
> uint8_t buf[MAXADDR];
> socklen_t len;
> }
>
> In that way we won't need to add 'addr' and 'len' all over the pla
On Fri, Apr 11, 2014 at 12:25:53PM +0200, Jiri Benc wrote:
> The callers of those functions are all using ptp_message. As we're going to
> return more information (the address), let those functions just fill in the
> ptp_message fields directly.
No, no, no, this violates the transport abstraction.
On Fri, Apr 11, 2014 at 12:25:54PM +0200, Jiri Benc wrote:
> This modifies all transports to use a new common address type, struct
> address. This address is stored in a ptp_message for all received messages.
>
> For sending, the "default" address is used with the default sending
> functions, tran
On Fri, Apr 11, 2014 at 12:25:52PM +0200, Jiri Benc wrote:
> In order to be able to convert to a generic address struct, separate source
> and destination address into separate fields.
>
> Signed-off-by: Jiri Benc
> ---
> ether.h | 13 ++---
> raw.c | 22 +++---
> 2
On Fri, Apr 11, 2014 at 12:25:55PM +0200, Jiri Benc wrote:
> Also, document transport_send, transport_peer and transport_sendto usage.
>
> Signed-off-by: Jiri Benc
> ---
> transport.c |8
> transport.h | 33 +
> 2 files changed, 41 insertions(+), 0
On Fri, 11 Apr 2014 14:08:16 +0200, Richard Cochran wrote:
> > +struct address {
> > + socklen_t len;
> > + union {
> > + struct sockaddr_storage ss;
> > + struct sockaddr_in sin;
> > + struct sockaddr_in6 sin6;
> > + struct sockaddr_un sun;
> > +
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
On Fri, 11 Apr 2014 14:05:58 +0200, Richard Cochran wrote:
> No, no, no, this violates the transport abstraction. The transport
> code knows nothing about the PTP payload, on purpose.
And this is not changed by this patch.
The actual transport code (udp.c, etc.) knows nothing about
ptp_message. T
On Fri, Apr 11, 2014 at 06:10:03PM +0200, Jiri Benc wrote:
>
> We could surely make yet another wrapper around transport_send etc. (as
> you also suggest in your reply to patch 5) but I don't really see a
> point of a wrapper of wrapper, especially when the inner wrapper won't
> be used by anythin
On Fri, Apr 11, 2014 at 06:13:22PM +0200, Jiri Benc wrote:
>
> It's the first member of the union. I originally had only struct
> sockaddr_storage here but it led to horrible typecasting in the code
> (which is quite error prone when you accidentally put an extra & before
> the variable). In the e
20 matches
Mail list logo
