Re: [Linuxptp-devel] [PATCH] util: don't error out in posix_clock_open() if we can't determine PHC index
> Hm, is there a unix/stdlib C API for realpath? My Linux man page says: CONFORMING TO 4.4BSD, POSIX.1-2001. POSIX.1-2001 says that the behavior if resolved_path is NULL is imple- mentation-defined. POSIX.1-2008 specifies the behavior described in this page. -- These are my opinions. I hate spam. ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] util: don't error out in posix_clock_open() if we can't determine PHC index
On Tue, Nov 16, 2021 at 10:09:59PM +, Keller, Jacob E wrote: > Is it possible for us to resolve symlinks ourselves before attempting to > check its index value? That would be an added convenience for users. Hm, is there a unix/stdlib C API for realpath? If so, then yes. (I haven't heard of such an API.) Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 1/2] phc2sys: move read_phc into clock_adj.c
> -Original Message- > From: Richard Cochran > Sent: Monday, November 15, 2021 5:40 AM > To: Keller, Jacob E > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH v2 1/2] phc2sys: move read_phc into > clock_adj.c > > On Fri, Oct 22, 2021 at 03:03:58PM -0700, Jacob Keller wrote: > > Notice that read_phc returned 0 on failure and 1 on success. This is > > fairly non-standard, so lets update clockadj_compare to return 0 on > > success and -1 on failure. Fix the call sites to check correctly and > > report an error. > > +1 > > > +/** > > + * Compare offset between two clocks > > + * @param clkid A clock ID obtained using phc_open() or CLOCK_REALTIME > > + * @param sysclk A clock ID obtained using phc_open() or CLOCK_REALTIME > > + * @readings Number of readings to try > > + * @offset On return, the nanoseconds offset between the clocks > > + * @ts On return, the time of sysclk in nanoseconds that was used > > + * @delayOn return, the interval between two reads of sysclk > > Nit: please add the @return doxygen marker. Sure thing. Will send a v3. Thanks, Jake > > > + * > > + * Compare the offset between two clocks in a similar manner as the > > + * PTP_SYS_OFFSET ioctls. Returns the difference between sysclk and clkid > > by > > + * performing multiple reads of sysclk with a read of clkid between. > > + */ > > +int clockadj_compare(clockid_t clkid, clockid_t sysclk, int readings, > > +int64_t *offset, uint64_t *ts, int64_t *delay); > > Thanks, > Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] util: don't error out in posix_clock_open() if we can't determine PHC index
> -Original Message- > From: Richard Cochran > Sent: Saturday, November 13, 2021 6:53 AM > To: Vladimir Oltean > Cc: Ed Branch ; linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH] util: don't error out in > posix_clock_open() if > we can't determine PHC index > > On Sat, Nov 13, 2021 at 06:22:34AM -0800, Richard Cochran wrote: > > Indeed phc2sys is correct in requiring that the path to the PTP char > > device be in the "/dev/ptpN" format. > > If ever phc2sys accepted /dev/ptp_kvm or similar, that was simply a > bug in phc2sys. > > > The Debian KVM script is just plain wrong. > > Or maybe not a bug, but still the script that invokes phc2sys should > simply use `realpath /dev/ptp_kvm` > Is it possible for us to resolve symlinks ourselves before attempting to check its index value? That would be an added convenience for users. Thanks, Jake ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Include phcIndex in PORT_PROPERTIES_NP PMC command
On Tue, 16 Nov 2021 at 15:22, Vladimir Oltean wrote:
> On Tue, Nov 16, 2021 at 12:47:09PM +, Karthikkumar V via
> Linuxptp-devel wrote:
> > PORT_PROPERTIES_NP PMC Command will now display the phcIndex along with
> > other interface details. A typical use case will be Users can fetch the
> > phcIndex to use the clock APIs of the kernel (clock_gettime and
> clock_settime)
> > to get the PHC time from user applications.
> >
> > Signed-off-by: Karthikkumar V
> > Signed-off-by: Ramana Reddy
> > ---
>
> May I suggest that
> (a) you should not modify the binary format of management TLVs in
> incompatible ways, as that would require everybody else to adapt and
> somehow know which format ptp4l expects, and
>
Totally agree.
You should add new fields at the end of the port_properties_np structure.
Make sure a new pmc tool prints the message from an old ptp4l properly.
And verify an old pmc tool works with a new ptp4l.
> (b) you can deduce the PHC index already from the struct PTPText interface,
> see posix_clock_open() -> sk_get_ts_info().
>
Changing management TLV should be done carefully.
Only when we must.
>
> > pmc.c | 6 --
> > port.c | 1 +
> > tlv.h | 1 +
> > 3 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/pmc.c b/pmc.c
> > index a1ee787..67e33a3 100644
> > --- a/pmc.c
> > +++ b/pmc.c
> > @@ -443,11 +443,13 @@ static void pmc_show(struct ptp_message *msg, FILE
> *fp)
> > IFMT "portIdentity%s"
> > IFMT "portState %s"
> > IFMT "timestamping%s"
> > - IFMT "interface %s",
> > + IFMT "interface %s"
> > + IFMT "phcIndex%d",
> > pid2str(>portIdentity),
> > ps_str[ppn->port_state],
> > ts_str(ppn->timestamping),
> > - text2str(>interface));
> > + text2str(>interface),
> > + ppn->phc_index);
> > break;
> > case MID_PORT_STATS_NP:
> > pcp = (struct port_stats_np *) mgt->data;
> > diff --git a/port.c b/port.c
> > index 7e51e77..743b7c7 100644
> > --- a/port.c
> > +++ b/port.c
> > @@ -956,6 +956,7 @@ static int port_management_fill_response(struct port
> *target,
> > else
> > ppn->port_state = target->state;
> > ppn->timestamping = target->timestamping;
> > + ppn->phc_index = target->phc_index;
> > ts_label = interface_label(target->iface);
> > ptp_text_set(>interface, ts_label);
> > datalen = sizeof(*ppn) + ppn->interface.length;
> > diff --git a/tlv.h b/tlv.h
> > index 97615fd..0f6cf28 100644
> > --- a/tlv.h
> > +++ b/tlv.h
> > @@ -341,6 +341,7 @@ struct port_properties_np {
> > struct PortIdentity portIdentity;
> > uint8_t port_state;
> > uint8_t timestamping;
> > + Integer32 phc_index;
> > struct PTPText interface;
> > } PACKED;
> >
> > --
> > 1.8.3.1
> >
> >
> >
> > ___
> > Linuxptp-devel mailing list
> > Linuxptp-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Include phcIndex in PORT_PROPERTIES_NP PMC command
On Tue, Nov 16, 2021 at 12:47:09PM +, Karthikkumar V via Linuxptp-devel
wrote:
> PORT_PROPERTIES_NP PMC Command will now display the phcIndex along with
> other interface details. A typical use case will be Users can fetch the
> phcIndex to use the clock APIs of the kernel (clock_gettime and clock_settime)
> to get the PHC time from user applications.
>
> Signed-off-by: Karthikkumar V
> Signed-off-by: Ramana Reddy
> ---
May I suggest that
(a) you should not modify the binary format of management TLVs in
incompatible ways, as that would require everybody else to adapt and
somehow know which format ptp4l expects, and
(b) you can deduce the PHC index already from the struct PTPText interface,
see posix_clock_open() -> sk_get_ts_info().
> pmc.c | 6 --
> port.c | 1 +
> tlv.h | 1 +
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/pmc.c b/pmc.c
> index a1ee787..67e33a3 100644
> --- a/pmc.c
> +++ b/pmc.c
> @@ -443,11 +443,13 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
> IFMT "portIdentity%s"
> IFMT "portState %s"
> IFMT "timestamping%s"
> - IFMT "interface %s",
> + IFMT "interface %s"
> + IFMT "phcIndex%d",
> pid2str(>portIdentity),
> ps_str[ppn->port_state],
> ts_str(ppn->timestamping),
> - text2str(>interface));
> + text2str(>interface),
> + ppn->phc_index);
> break;
> case MID_PORT_STATS_NP:
> pcp = (struct port_stats_np *) mgt->data;
> diff --git a/port.c b/port.c
> index 7e51e77..743b7c7 100644
> --- a/port.c
> +++ b/port.c
> @@ -956,6 +956,7 @@ static int port_management_fill_response(struct port
> *target,
> else
> ppn->port_state = target->state;
> ppn->timestamping = target->timestamping;
> + ppn->phc_index = target->phc_index;
> ts_label = interface_label(target->iface);
> ptp_text_set(>interface, ts_label);
> datalen = sizeof(*ppn) + ppn->interface.length;
> diff --git a/tlv.h b/tlv.h
> index 97615fd..0f6cf28 100644
> --- a/tlv.h
> +++ b/tlv.h
> @@ -341,6 +341,7 @@ struct port_properties_np {
> struct PortIdentity portIdentity;
> uint8_t port_state;
> uint8_t timestamping;
> + Integer32 phc_index;
> struct PTPText interface;
> } PACKED;
>
> --
> 1.8.3.1
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH] Include phcIndex in PORT_PROPERTIES_NP PMC command
PORT_PROPERTIES_NP PMC Command will now display the phcIndex along with
other interface details. A typical use case will be Users can fetch the
phcIndex to use the clock APIs of the kernel (clock_gettime and clock_settime)
to get the PHC time from user applications.
Signed-off-by: Karthikkumar V
Signed-off-by: Ramana Reddy
---
pmc.c | 6 --
port.c | 1 +
tlv.h | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/pmc.c b/pmc.c
index a1ee787..67e33a3 100644
--- a/pmc.c
+++ b/pmc.c
@@ -443,11 +443,13 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
IFMT "portIdentity%s"
IFMT "portState %s"
IFMT "timestamping%s"
- IFMT "interface %s",
+ IFMT "interface %s"
+ IFMT "phcIndex%d",
pid2str(>portIdentity),
ps_str[ppn->port_state],
ts_str(ppn->timestamping),
- text2str(>interface));
+ text2str(>interface),
+ ppn->phc_index);
break;
case MID_PORT_STATS_NP:
pcp = (struct port_stats_np *) mgt->data;
diff --git a/port.c b/port.c
index 7e51e77..743b7c7 100644
--- a/port.c
+++ b/port.c
@@ -956,6 +956,7 @@ static int port_management_fill_response(struct port
*target,
else
ppn->port_state = target->state;
ppn->timestamping = target->timestamping;
+ ppn->phc_index = target->phc_index;
ts_label = interface_label(target->iface);
ptp_text_set(>interface, ts_label);
datalen = sizeof(*ppn) + ppn->interface.length;
diff --git a/tlv.h b/tlv.h
index 97615fd..0f6cf28 100644
--- a/tlv.h
+++ b/tlv.h
@@ -341,6 +341,7 @@ struct port_properties_np {
struct PortIdentity portIdentity;
uint8_t port_state;
uint8_t timestamping;
+ Integer32 phc_index;
struct PTPText interface;
} PACKED;
--
1.8.3.1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH 10/10] checksync: new program to wait for a local or remote clock to synchronize
Sorry the script is part of propriety application of Siemens. Users can use the test scripts in the http://libpmc.sf.net/ They can easily adopt it into their application in C, C++, python, Lua, Perl, ruby and TCL. C simply need a "wrapper" to C++. What I do in my script is very simple. I send 3 GETs for PORT_DATA_SET, PARENT_DATA_SET, CURRENT_DATA_SET. When receiving the reply in my main "poll", I process them and get the portState, peerMeanPathDelay from PORT_DATA_SET, gmIdentity from PARENT_DATA_SET and master_offset from CURRENT_DATA_SET. I then decide if port is synchronise or not based on these values. Erez -Original Message- From: Richard Cochran Sent: Monday, 15 November 2021 14:43 To: Geva, Erez (ext) (DI PA DCP R 3) Cc: Vladimir Oltean ; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [RFC PATCH 10/10] checksync: new program to wait for a local or remote clock to synchronize On Fri, Oct 15, 2021 at 10:48:28PM +, Geva, Erez wrote: > Although, I am not oppose your patch. I just find it useless, as I perform > the same result in a Perl script. > And with a much higher flexibility and a better performance. Can you share the equivalent script? It would be interesting to compare the two... Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
