On Mon, Aug 31, 2020 at 02:45:17AM +0300, Vladimir Oltean wrote:
> The code through which phc2sys sends various PTP management messages to
> ptp4l via pmc can be reused.
>
> This patch is a trivial movement of that code to a separate translation
> module, outside of phc2sys. This makes it availabl
On Mon, Aug 31, 2020 at 02:45:16AM +0300, Vladimir Oltean wrote:
> In preparation of a trivial movement of code to pmc_common.c, remove the
> "static" keyword from the functions that will end up there, since they
> will be still called from phc2sys.c for now.
>
> Signed-off-by: Vladimir Oltean
A
On Mon, Aug 31, 2020 at 02:45:15AM +0300, Vladimir Oltean wrote:
> This creates a smaller structure within phc2sys_private, which embeds
> all properties related to the PMC. This structure is called "pmc_node",
> which is somewhat reminiscent of the old name of phc2sys_private (struct
> node). But
On Mon, Aug 31, 2020 at 02:45:14AM +0300, Vladimir Oltean wrote:
> In preparation of moving these functions to pmc_common.c, break the
> lines to a maximum of 80 characters, otherwise checkpatch will complain.
>
> Signed-off-by: Vladimir Oltean
Applied.
Thanks,
Richard
___
ee
running before setting the frequency.
Signed-off-by: Richard Cochran
---
clock.c| 5 +++--
ts2phc_slave.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/clock.c b/clock.c
index a66d189..0156bc3 100644
--- a/clock.c
+++ b/clock.c
@@ -1114,8 +1114,9 @@ st
On Wed, Nov 04, 2020 at 09:43:52AM +0100, Luigi 'Comio' Mantellini wrote:
> The announce message should br managed by protocol as a normal PTP Announce
> message to handle the BMC and select the grandmaster (I suppose).
Don't conflate those two.
> From my protocol picture I think that ts2phc is
On Thu, Oct 29, 2020 at 02:40:55PM +1100, Matthew P. Grosvenor wrote:
> I think you’re missing the point here. You made two assertions:
> The NIC MAC should either strip the CRC, or should drop a packet with a bad
> CRC.
No, that is not what I meant. The job of the MAC is to check the CRC
and d
On Thu, Oct 29, 2020 at 11:58:41AM +0100, Miroslav Lichvar wrote:
> That wouldn't work well, but as phc2sys doesn't use PTP to synchronize
> the clocks, I think it can use a different terminology than ptp4l. It
> might actually be less confusing. In the current code the same clock
> is master and
On Wed, Oct 28, 2020 at 06:47:29PM +0100, Luigi 'Comio' Mantellini wrote:
> The idea under the Annex A is to propagate some information from the serial
> link to master port.
What "information" are we talking about?
For setting GM attributes in ptp4l, you should use the management interface.
>
On Thu, Aug 06, 2020 at 04:16:10PM +0200, Miroslav Lichvar wrote:
> Instead of unconditionally creating a servo for each clock in their
> initialization, add the servo later on the first update of the clock,
> when it is known the clock needs to be synchronized.
>
> This fixes an issue with phc2sy
On Thu, Aug 06, 2020 at 04:16:09PM +0200, Miroslav Lichvar wrote:
> Remove duplicated code specific to the ntpshm servo configuration.
>
> Signed-off-by: Miroslav Lichvar
Applied.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.
On Wed, Oct 28, 2020 at 09:35:36AM +0100, Luigi 'Comio' Mantellini wrote:
> thanks for your reply. I'm referring to G.8271/Y.1366 document:
> https://www.itu.int/rec/T-REC-G.8271-202003-I/en
> The new standard added a protocol on top of TOD/1PPS link as defined in the
> cited Annex A.
Thanks for t
On Wed, Oct 28, 2020 at 06:27:42AM +1100, mgrosve...@gmail.com wrote:
> Furthermore, some switches (Eg Arista and and Cisco) use the CRC to convey
> timestamps in packets.
If that is true, then their device drivers should strip off the time
stamp and provide it via the SO_TIMESTAMPING mechanism.
On Mon, Aug 24, 2020 at 09:41:06AM +0200, Miroslav Lichvar wrote:
> It seems you are set on this terminology. I think it would work for
> me, although in my head I mostly see the packets on the network
> instead of a time signal. Have you considered adopting a server/client
> terminology like NTP i
On Tue, Sep 29, 2020 at 08:58:26AM +0200, Heiko Thiery wrote:
> Due to uclic-ng supports clock_nanosleep without enabled threads we do
> not need to provide clock_nanosleep in that case.
>
> Cc: Richard Cochran
> Signed-off-by: Heiko Thiery
Applied.
On Wed, Jul 22, 2020 at 06:16:01AM -0700, Richard Cochran wrote:
> On Wed, Jul 22, 2020 at 02:14:48PM +1000, Luke Howard wrote:
> > [resending from correct email]
> >
> > > The output of the pmc tool is still unstructured text. So to feed it into
> > > a scri
On Tue, Oct 27, 2020 at 08:03:34PM +0100, Luigi 'Comio' Mantellini wrote:
> Dear All,
>
> I'm trying to understand if I can support the G.8271 Annex A.1.3 directly
> via LinuxPTP.
My copy doesn't have any "Annex" at all, but only Appendixes.
ITU-T G.8271.1/Y.1366.1 (08/2013)
No idea what you
On Wed, Oct 28, 2020 at 06:27:42AM +1100, mgrosve...@gmail.com wrote:
> Furthermore, some switches (Eg Arista and and Cisco) use the CRC to
> convey timestamps in packets. It would be absolutely necessary to be
> able to see the “CRC” for this this use case, on the same interface
> that PTP traffi
On Tue, Oct 27, 2020 at 11:12:54AM +, Matt Sanders (matt8) wrote:
> and uses the mechanisms that the standard implies to resolve the
> problem.
I disagree with your intrepretation of the what the standard "implies".
> What’s
> your objection to going down this path?
Check the list archives.
On Thu, Oct 22, 2020 at 11:17:51AM +, Matt Sanders (matt8) via
Linuxptp-devel wrote:
> It is possible for 802.3 Ethernet adapters to be configured include the
> Ethernet
> CRC value in the raw frame which will be returned by the PF_PACKET / SOCK_RAW
> interface used by Linux PTP. This is con
On Tue, Sep 29, 2020 at 01:46:37PM +0300, Vladimir Oltean wrote:
> Should I resend these patches on top of your NMEA fixes, or can you
> continue to review them as-is?
I think the conflicts are small, but I'm on vacation right now, and so
I'll complete the review in about two weeks. (The re-facto
On Mon, Sep 28, 2020 at 12:37:03PM +0200, Heiko Thiery wrote:
> I just want to understand when the defines/functions coming from
> missing.h should come into account. What uclib(-ng) version should be
> support here?
I think the audience for uClibc is small, and so we needn't support
every last uC
The NMEA mode of the ts2phc program is broken and cannot work
correctly. This series fixes the damage and also completes a couple
of outstanding todos.
Richard Cochran (8):
ts2phc: nmea: Correct UTC to TAI conversion.
ts2phc: nmea: Add error messages for leap second lookup failures.
ts2phc
If a leap second lookup fails, the likely reason is that the table is out
of date. After all, the leap second table has an expiration date. The
user will surely appreciate if the software complains loudly in this case.
Signed-off-by: Richard Cochran
---
ts2phc_nmea_master.c | 4
1 file
If a leap seconds file is configured, the software will read the file once
on start up. However, that file is nominally valid for a maximum of six
months. This patch adds a check on the modification time of the file and
reloads the file if needed.
Signed-off-by: Richard Cochran
The error path does not clean up properly when allocations fail. This
patch fixes the memory leaks on the error path.
Signed-off-by: Richard Cochran
---
ts2phc_nmea_master.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ts2phc_nmea_master.c b/ts2phc_nmea_master.c
index 76fc7ae..5c17e5a
GPS
network, and that is far too long for a PTP GM to wait after startup.
This patch allows the built in leap seconds table to be overridden by an
up to date file provided in the environment.
Signed-off-by: Richard Cochran
---
config.c | 1 +
ts2phc.8 | 8
If there is no valid fix reported by the RMC message, then calculation
of the PPS time stamp is pointless. This patch simplifies the logic by
returning early in this case.
Signed-off-by: Richard Cochran
---
ts2phc_nmea_master.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff
Bring the built in leap second table up to date through IERS Bulletin C59.
No new leap seconds have been scheduled for this year.
Signed-off-by: Richard Cochran
---
lstab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lstab.c b/lstab.c
index 5fede16..391a6b9 100644
--- a
The time value passed into the leap second lookup table should be in
seconds, but the calling code in the nmea module passes nanoseconds
instead. This patch fixes the issue by converting the time value
accordingly.
Signed-off-by: Richard Cochran
---
lstab.h | 2
t RMC record is available, probably some kind of error has occurred.
This patch limits the age of the RMC record used for ToD to five seconds.
Signed-off-by: Richard Cochran
---
ts2phc_nmea_master.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/ts2phc_nmea_maste
On Sun, Aug 30, 2020 at 12:21:49AM +0300, Vladimir Oltean wrote:
> A potentially relevant question to be asked is if we're ok with the lack
> of backwards compatibility here.
The program ought to still work with the older interface.
> The program used to be a passive observer of "ts2phc.pulsewidt
On Tue, Aug 18, 2020 at 02:19:40AM +0300, Vladimir Oltean wrote:
> This API was introduced for 2 reasons:
>
> 1. Some hardware can emit PPS signals but not starting from arbitrary
>absolute times, but rather phase-aligned to the beginning of a
>second. We _could_ patch ts2phc to always spe
On Tue, Aug 18, 2020 at 02:19:35AM +0300, Vladimir Oltean wrote:
> @@ -153,7 +352,7 @@ int main(int argc, char *argv[])
> /* Process the command line arguments. */
> progname = strrchr(argv[0], '/');
> progname = progname ? 1 + progname : argv[0];
> - while (EOF != (c = getopt
On Tue, Aug 18, 2020 at 02:19:33AM +0300, Vladimir Oltean wrote:
> Slaves in ts2phc are PHC devices that implement the extts kernel API.
> They are slaves just in the sense that they timestamp a pulse emitted by
> somebody else.
>
> Currently in ts2phc, PPS slaves are also the only candidates for
On Tue, Aug 18, 2020 at 02:19:32AM +0300, Vladimir Oltean wrote:
> Eliminate the ad-hoc use of global variables in the ts2phc program by
> introducing one data structure that incorporates them. This might make
> the code more understandable to people coming from a kernel background,
> since it rese
On Tue, Aug 18, 2020 at 02:19:31AM +0300, Vladimir Oltean wrote:
> diff --git a/phc2sys.c b/phc2sys.c
> index a36cbe071d7d..c4d72bd7d17a 100644
> --- a/phc2sys.c
> +++ b/phc2sys.c
> @@ -56,18 +56,13 @@
> #include "uds.h"
> #include "util.h"
> #include "version.h"
> +#include "contain.h"
Preserv
On Tue, Aug 18, 2020 at 02:19:26AM +0300, Vladimir Oltean wrote:
> Changes in v2:
> - Added Jacob's review tags, addressed some feedback.
> - Dropped patch "pmc_common: fix potential memory leak in
> run_pmc_events()"
> - Reordered patches (put the tmv helpers first)
> - Fixed memory leaks
I app
On Thu, Aug 20, 2020 at 07:50:29PM +0100, Richard Hill wrote:
> I'm all a bit lost here. Perfectly understandable that the word 'Slave'
> needs to be
> dropped ASAP.
> Waiting for the official committee might be like watching paint dry.
Agreed. My plan is NOT to wait for the committee but rathe
On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:
> What I don't get is where is the need for linuxptp to "take the lead" on
> this topic?
see next answer...
> What if the terms on which IEEE 1588 settles are not the terms in your
> mind ("source"/"sink")?
Because linuxptp is wi
On Thu, Aug 20, 2020 at 04:02:30PM +0300, Vladimir Oltean wrote:
> On Wed, Aug 19, 2020 at 09:42:40AM -0700, Richard Cochran wrote:
> >
> > In any case, this is just the kind of bikeshedding discussion that I
> > want to avoid.
>
> But you are the one who asked for
On Wed, Aug 19, 2020 at 11:37:15PM +0530, Jagmeet Singh Hanspal wrote:
> Yes, each client is correcting itself to match to the the master and as a
> continuous process of matching to the chosen one by following it like a
> closed-loop dogfight.
"closed-loop dogfight" -- love it!
> Anyways, source
On Wed, Aug 19, 2020 at 04:13:38PM +, Geva, Erez wrote:
> I short. It means that they are follows the leader.
Anyone who has ever been on a hiking trip or watched ducks in a pond
knows that the leader goes in front and the followers behind, with
each follower at different distance from the lea
On Wed, Aug 19, 2020 at 03:06:22PM +, Geva, Erez wrote:
> Personally I prefer leader/followers over source/sink.
Let's think about those terms...
If clock A is leading clock B, then clock A is running ahead.
If clock A is following clock B, then clock A is running behind.
Sounds rather sill
On Tue, Aug 18, 2020 at 02:51:26PM -0700, Jacob Keller wrote:
> Yep, makes sense. Long term, after changing the stuff which doesn't
> impact config, we can work towards finding a way to deprecate and rename
> config options in a way that won't break existing deployment. I'm
> personally Ok with sim
er that the man pages, and later on the identifiers
in the program. With very few exceptions, none of the re-naming would
impact any existing user configuration scripts. We will take care not
to cause issues for the myriad deployments of this software world wide.
Thanks,
Richard
Richard Cochran
Signed-off-by: Richard Cochran
---
phc2sys.c | 10 +-
ptp4l.c | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/phc2sys.c b/phc2sys.c
index 64bdf26..18d9a9c 100644
--- a/phc2sys.c
+++ b/phc2sys.c
@@ -1319,10 +1319,10 @@ static void usage(char *progname
On Mon, Aug 17, 2020 at 11:28:34PM +0300, Vladimir Oltean wrote:
> Do I need to fix up the patches now, or are you still going to review
> them?
I'll go forward, reviewing the patches as is...
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-d
Vladimir,
On Tue, Aug 04, 2020 at 02:40:11PM +0300, Vladimir Oltean wrote:
> The diff is large, yes, even though I tried to avoid making unnecessary
> changes. I hope it isn't too difficult to review, it isn't as polished
> as I typically like, because the idea itself was uncertain, so I
> preferr
On Wed, Aug 05, 2020 at 04:12:02PM -0700, Jacob Keller wrote:
> Here, we are making the implicit assumption that all ptp clock devices
> will always have /dev/ptpX format. I don't think anyone is crazy enough
> to rename these devices...
(Not yet, anyways ;^)
> An alternative (requiring kernel i
On Wed, Aug 05, 2020 at 04:02:08PM -0700, Jacob Keller wrote:
> The capability command for phc_ctl does not display the number of pins
> or the cross timestamping support. Add this as output so that the user
> can see the complete device capabilities.
>
> Signed-off-by: Jacob Keller
Applied.
Th
On Sat, Aug 01, 2020 at 08:46:05PM +0300, Vladimir Oltean wrote:
> At a high level, what I have done is:
> - I moved the PMC related code from phc2sys into pmc_common.c, for
> ts2phc reuse
> - I created an extra abstraction in ts2phc as "struct clock" that would
> represent what's synchronizabl
On Sun, Jul 26, 2020 at 12:34:00PM +1000, Matthew P. Grosvenor wrote:
> This is exactly what I’m trying to avoid: committing the cardinal
> sin of open source. If the project doesn’t do exactly what you need,
> just write yet-another similar but different implementation written
> in yet-another lan
ceived and transmitted messages
pmc: Add a new TLV to obtain per-port statistics
udp6: Make mc6_addr transport-local
pmc.8: Mention PORT_STATS_NP
util: Add a function to render timestamp type
pmc: Support querying TLV_PORT_PROPERTIES_NP
Richard Cochran (89):
Allow ignor
On Thu, Jul 23, 2020 at 09:57:35AM +1000, Luke Howard wrote:
> Possibly an extension to pmc(8) for emitting JSON would better suit your use
> case, depends on how your application is structured I guess?
You can pipe the pmc output through a script (python, etc) that emits json.
That might cover s
On Wed, Jul 22, 2020 at 02:14:48PM +1000, Luke Howard wrote:
> [resending from correct email]
>
> > The output of the pmc tool is still unstructured text. So to feed it into a
> > script I would still need to write an output parser of some sort and I
> > would have to guess that my parser covers
On Wed, Jul 22, 2020 at 12:42:52PM +1000, mgrosve...@gmail.com wrote:
> Hi all,
> I’ve been thinking about how include Linux PTP in a larger project that I’m
> working on.
>
> To do so I could write a bunch of regex parsing magic to parse up the Linux
> PTP output (and hope that I get it right
Dear linuxptp developers and users,
We have accumulated a batch of new features, and so, after completing
my smoke tests, I am planning to release version 3.0 in two weeks'
time. It will include the current git head plus any needed bug fixes.
If there are any bug reports or bug fixes out there,
On Sat, Jun 27, 2020 at 11:27:47AM +0300, Vladimir Oltean wrote:
> Hi Richard,
>
> I have a board with multiple DSA switches which I'm trying to make act as a
> single boundary clock.
Okay, so I think I got it...
> But looking at the current object model in ts2phc, I figured my changes would
> b
On Sat, Jun 27, 2020 at 11:27:47AM +0300, Vladimir Oltean wrote:
> Now, the pmc portion is not at all what's difficult. In fact, nothing is
> _really_ difficult, I just want to set the overall design straight with you so
> that there would be less rework when I present some initial patches.
>
> Wh
On Fri, Jun 26, 2020 at 01:15:11PM +0300, Vladimir Oltean wrote:
> So, to your point: I didn't see any driver that _rejects_ time in the
> past. If it works, I don't know. If it doesn't work, I would do the
> time fixup at driver level, so in my opinion there's no need for an
> application-level f
On Fri, Jun 26, 2020 at 12:21:01AM +0300, Vladimir Oltean wrote:
> Actually there's no good reason why ts2phc would specify an absolute
> start time of (current time + 2 seconds, 0) for its most basic
> operation. The (0, 0) start time should be accepted by all drivers,
Hm. I'm not so sure that a
On Thu, Jun 25, 2020 at 01:21:34AM +0300, Vladimir Oltean wrote:
> Currently it is very finicky to deploy linuxptp in an automated build
> system and make KBUILD_OUTPUT pick up the output of "make
> headers_install" in order for the application to make full use of the
> features exposed by the runt
On Wed, Jun 24, 2020 at 09:16:42PM +0300, Vladimir Oltean wrote:
> Treating it as an event on a data queue is a bug.
Yeah, I guess we have just been lucky all this time.
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists
On Wed, Jun 24, 2020 at 09:01:33PM +0300, Vladimir Oltean wrote:
> I think it boils down to something very simple.
> The kernel is waking up a user process with revents = POLLIN |
> POLLERR. That has a certain meaning.
> Then the process says "Oh, yay, I have revents = POLLIN. Let me
> process that
On Wed, Jun 24, 2020 at 05:52:39PM +, Keller, Jacob E wrote:
> Sure, but the POLLERR could (in theory, not in current practice) return other
> events/messages besides timestamps.
>
> It was invented/created prior to the Tx timestamps, wasn't it?
Yes, and this is the point!
Thanks,
Richard
On Wed, Jun 24, 2020 at 08:21:22PM +0300, Vladimir Oltean wrote:
> What contract, who said that this control channel is _only_ for TX
> timestamps, and for how many TX timestamps it is?
Um, there can't be more time stamps than transmitted frames.
> If a future kernel decided to send more data to
On Mon, Jun 15, 2020 at 06:23:21PM +0300, Vladimir Oltean wrote:
> ptp4l is too silent when receiving, for whatever reason, out of order
> messages. If the reordering is persistent (which is either a broken
> network, or a broken kernel), the behavior looks like a complete
> synchronization stall,
On Mon, Jun 15, 2020 at 06:23:19PM +0300, Vladimir Oltean wrote:
> The application's main event loop (clock_poll) is woken up by poll() and
> dispatches the socket receive queue events to the corresponding ports as
> needed.
>
> So it is a bug if poll() wakes up the process for data availability o
On Sun, Jun 21, 2020 at 11:14:45AM +0200, Georg Sauthoff wrote:
> This saves a few bytes of static storage and less instructions are
> executed when looking for the best offset.
>
> Signed-off-by: Georg Sauthoff
Applied.
Thanks,
Richard
___
Linuxptp
On Wed, Jun 24, 2020 at 07:36:47PM +0300, Vladimir Oltean wrote:
> I am reading this as: "let's be defensive even in the case where the
> kernel decides to go nuts and push us a packet on the error queue even
> if we didn't enable SO_SELECT_ERR_QUEUE". But that isn't at all what's
> going on. As st
On Tue, Jun 23, 2020 at 12:27:27PM +0300, Vladimir Oltean wrote:
> Currently it is very finicky to deploy linuxptp in an automated build
> system and make KBUILD_OUTPUT pick up the output of "make
> headers_install" in order for the application to make full use of the
> features exposed by the runt
ror condition.
Suggested-by: Vladimir Oltean
Signed-off-by: Richard Cochran
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
On Mon, Jun 15, 2020 at 06:23:19PM +0300, Vladimir Oltean wrote:
>
> The above condition shouldn't typically happen, but exceptional kernel
> events will trigger it. It helps to be strict in ptp4l in order for
> those events to not blow up in even stranger symptoms unrelated to the
> root cause of
On Fri, Jun 19, 2020 at 07:33:03PM +0300, Vladimir Oltean wrote:
> Then it is not correct to "continue" the loop, since it will keep
> iterating through the pollfd array for sockets that were closed in the
> meantime.
> And don't we want to set up a fault timer, to clear it eventually?
Ah! Right
On Fri, Jun 19, 2020 at 05:58:17PM +0300, Vladimir Oltean wrote:
> You need to recv() the data. Otherwise, it will remain forever there,
> ptp4l will be toast, since this will keep dispatching the fault ad
> infinitum.
The fault handling path closes all sockets and opens new ones.
Thanks,
Richard
On Fri, Jun 19, 2020 at 04:01:57PM +0300, Vladimir Oltean wrote:
> Again, I would have accepted any technical argument you could bring.
Thinking more about this, there is in fact a technical reason to leave
the code as is. For DGRAM sockets, the behavior of recvmsg() in
sk_receive() is the same w
On Fri, Jun 19, 2020 at 05:13:44AM -0700, Richard Cochran wrote:
> But the patch does not handle the situation correctly. This code
> would dump the frame and carry on as if nothing had happened. The
> correct way would be to treat this as a fault on the port in question.
Something
On Fri, Jun 19, 2020 at 03:41:09PM +0300, Vladimir Oltean wrote:
> Ok, and this patch does not have a place in linuxptp because?
It is a matter of style, as I already said.
Thanks,
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
h
On Fri, Jun 19, 2020 at 03:26:48PM +0300, Vladimir Oltean wrote:
> if (flags == MSG_ERRQUEUE) {
> struct pollfd pfd = { fd, sk_events, 0 };
> res = poll(&pfd, 1, sk_tx_timeout);
> if (res < 1) {
> pr_err(res ? "poll for tx timestamp failed: %m" :
>
On Fri, Jun 19, 2020 at 03:12:57PM +0300, Vladimir Oltean wrote:
> Perhaps the most frustrating thing to me, after debugging that system
> issue, is that ptp4l had all means necessary to detect a system issue,
> but it preferred to remain oblivious to it.
This is a production PTP stack and not an
On Fri, Jun 19, 2020 at 02:55:17PM +0300, Vladimir Oltean wrote:
> Sure. In fact, printing the data on the error queue is totally
> optional and I could just as well remove it, no problem with that. But
> reading it isn't. I don't think you've addressed that point.
Yes, here, for correctness sake,
On Fri, Jun 19, 2020 at 02:51:56PM +0300, Vladimir Oltean wrote:
> Could you please give a concrete example of why it isn't desirable for
> MSG_DONTWAIT to be specified on a socket where data availability has
> been previously confirmed through poll()? I'm not sure what the patch
> has to do with t
On Mon, Jun 15, 2020 at 06:23:20PM +0300, Vladimir Oltean wrote:
> Printing them to the user is optional (and helpful), but reading them is
> not. With this patch, even with extraneous data delivered by a buggy
> kernel (which the application now loudly complains about), the
> synchronization keeps
On Thu, Jun 18, 2020 at 12:42:55PM -0700, Jacob Keller wrote:
> > So it is a bug if poll() wakes up the process for data availability on a
> > socket's receive queue, and then recvmsg(), called immediately
> > afterwards, goes to sleep trying to retrieve it.
Yes.
> Makes sense. Using MSG_DONTWAIT
On Mon, Jun 15, 2020 at 02:14:54PM +0100, Werner Macho wrote:
> Signed-off-by: Werner Macho
> ---
> phc_ctl.8 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourc
On Mon, Jun 15, 2020 at 02:16:45PM +0100, Werner Macho wrote:
> Much effort for a small typom but maybe it will be more next time ;)
Yes, that is why I asked you to try again. Of course I could have
simply fixed it myself, but now you are ready for the next patch!
Thanks,
Richard
_
On Mon, Jun 15, 2020 at 05:46:16AM -0700, Richard Cochran wrote:
>
> Your mailer has wrapped the lines. Can you please fix that up and
> send again?
I see you use Gmail. Maybe use the "plain text option."
When I send patches over Gmail, I use the command line like this..
Werner,
Glad to see your patch, but it has a format issue...
On Mon, Jun 15, 2020 at 10:12:33AM +0100, Werner Macho wrote:
> diff --git a/phc_ctl.8 b/phc_ctl.8
> index 609dbab..650e661 100644
> --- a/phc_ctl.8
> +++ b/phc_ctl.8
> @@ -66,7 +66,7 @@ it.
> Compare the PHC clock device to CLOCK_REAL
On Fri, Jun 05, 2020 at 08:35:02AM -0700, Richard Cochran wrote:
> On Fri, Jun 05, 2020 at 12:54:10PM +, gabriel.moy...@dlr.de wrote:
> > What are the things, e.g. systems call, that this other OS should have?
> > What are the needed changes?
>
> Four points are:
>
On Fri, Jun 05, 2020 at 12:54:10PM +, gabriel.moy...@dlr.de wrote:
> What are the things, e.g. systems call, that this other OS should have? What
> are the needed changes?
Four points are:
1. dynamic posix clock support (clock_t argument to clock_gettime and friends)
2. PTP Hardware Clock c
On Thu, Jun 04, 2020 at 12:09:48AM +1000, Luke Howard via Linuxptp-devel wrote:
> > I don't know much about the audio profiles. Are they using a different
> > transport or domain? A better way to do this might be to run two
> > ptp4l instances on the interface.
>
>
> Oddly that actually didn’t oc
On Tue, Jun 02, 2020 at 03:01:20PM +0200, Christian Eggers wrote:
> On some platforms, time_t has recently switched from "long" to "long
> long" [1]. For these platforms it is necessary to use "%lld" as printf
> format specifier because the ABI differs between "long" and "long long".
>
> I found n
On Thu, May 28, 2020 at 05:07:05PM +, Keller, Jacob E wrote:
> Presumably, other implementations won't support this non-portable
> TLV. Is there any part of our implementation that ought to support
> the official standard?
Yes, and this series already implements the official
SLAVE_RX_SYNC_TIM
On Tue, May 26, 2020 at 05:04:14PM +, Patel, Vedang wrote:
> Yes, I think it is remnant from the earlier version of the patch set
> which was implementing message interval request mechanism inside the
> FSM for the ’noop' BMCA. I think it should be safe to remove this. I
> will submit a patch
Signed-off-by: Richard Cochran
---
tlv.c | 57 +
tlv.h | 20
2 files changed, 77 insertions(+)
diff --git a/tlv.c b/tlv.c
index e12e5ae..738e404 100644
--- a/tlv.c
+++ b/tlv.c
@@ -594,6 +594,55 @@ static void
Signed-off-by: Richard Cochran
---
pmc.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/pmc.c b/pmc.c
index 490c140..8e30b1c 100644
--- a/pmc.c
+++ b/pmc.c
@@ -55,6 +55,59 @@ static char *bin2str(Octet *data, int len)
return
The monitoring module accepts Sync timing events. This patch hooks up the
port receive path to call into the monitor.
Signed-off-by: Richard Cochran
---
port.c | 22 +++---
port_private.h | 3 +++
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/port.c b
Signed-off-by: Richard Cochran
---
pmc.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/pmc.c b/pmc.c
index 8e30b1c..65d1d61 100644
--- a/pmc.c
+++ b/pmc.c
@@ -58,6 +58,20 @@ static char *bin2str(Octet *data, int len)
#define SHOW_TIMESTAMP(ts
The 2019 version of 1588 known as v2.1 introduces new TLV type and
management IDs. This patch adds the new definitions.
Signed-off-by: Richard Cochran
---
tlv.c | 28 ++--
tlv.h | 19 ++-
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a
801 - 900 of 2642 matches
Mail list logo
