On Fri, Apr 06, 2018 at 12:34:34PM +0200, Anders Selhammer wrote:
> +#ifndef HAVE_PM_H
> +#define HAVE_PM_H
> +
> +#include <sys/queue.h>
> +
> +#include "stats.h"
> +#include "tmv.h"
> +
> +#define PM_15M_TIMER 900
> +
> +typedef tmv_t PMTimestamp;
This typedef serves no useful purpose. Just use this...
> +struct pm_head {
> + UInteger16 index;
> + PMTimestamp PMTime;
time_t pm_time;
> +};
The PMTime data type is never actually defined in the draft. Brilliant.
It looks like this is only used for very coarse time stamps, and so
the time_t from clock_gettime() should be good enough.
Also, we don't use mixed case for internal data. Only when there is
direct connection to some member of a 1588 data set do we use
camelCase in order to make the connection clear. As a matter of taste
I shun camelCase, but I do think using the same words as in a standard,
data sheet, or Technical Reference Manual is a good practice.
> +/* E2E and P2P */
> +struct pm_clock_stats {
> + TAILQ_ENTRY(clock_pm_stats) list;
> + struct pm_head head;
> + UInteger8 measurementValid;
> + UInteger8 periodComplete;
> + struct stats *masterSlaveDelay;
Here I prefer 'master_slave_delay'. The word "masterSlaveDelay" does
not actually appear in Annex M. We do see "MasterSlaveDelay", but
that isn't the name of a data set member, nor is it the field of a
message.
The 'struct stats' is purely an invention of the linuxptp stack, and
therefore any instance if it should use a standard name according to
our preferred coding style. I am making sense?
Thanks,
Richard
> + struct stats *slaveMasterDelay;
> + struct stats *meanPathDelay;
> + struct stats *offsetFromMaster;
> +};
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
