On Mon, Sep 03, 2018 at 01:49:47PM +0200, Michael Walle wrote:
> It's an implementation detail (in hardware, so I can't do anything about it)
> of the scheduler, that it has to be restarted if there was a clock jump. And
> additionally, if there is no grandmaster anymore, we should stop the
> sched
Am 2018-08-18 16:04, schrieb Richard Cochran:
On Mon, Aug 06, 2018 at 05:29:09PM +0200, Michael Walle wrote:
Would an implemention (like execute some shell scripts on specific
events)
inside linuxptp be accepted at all?
No. Even though it seems like the easy way, in the end it will prove
bri
On Mon, Aug 06, 2018 at 05:29:09PM +0200, Michael Walle wrote:
> Would an implemention (like execute some shell scripts on specific events)
> inside linuxptp be accepted at all?
No. Even though it seems like the easy way, in the end it will prove
brittle. Every one will want their own special ho
[please keep my mail address on CC]
Am 2018-08-06 16:53, schrieb Richard Cochran:
On Mon, Aug 06, 2018 at 09:27:18AM +0200, Stephan Gatzka wrote:
Hi!
> I came up with the following solutions to this problem:
> (1) Poll the state using the unix domain socket and PTP messages
> (2) Extend th
On Mon, Aug 06, 2018 at 09:27:18AM +0200, Stephan Gatzka wrote:
> Hi!
>
> > I came up with the following solutions to this problem:
> > (1) Poll the state using the unix domain socket and PTP messages
> > (2) Extend the event system of linuxptp (SUBSCRIBE_EVENTS_NP)
> > (3) Provide hooks at
Hi!
I came up with the following solutions to this problem:
(1) Poll the state using the unix domain socket and PTP messages
(2) Extend the event system of linuxptp (SUBSCRIBE_EVENTS_NP)
(3) Provide hooks at some places inside linuxptp
(1) is not desirable because of polling. I would op
