linuxptp-users

[Linuxptp-users] Feature enhancement for more comfortable usually interaction with a script language or other applications

[Mario M. <mar...@we...>]

Hallo PTP4l Members,

Our measurement data unit  need for some situation the current information about the grandmasterIdentity and currentUtcOffset.

This information need  our measurent data unit only in case of changing. 

I know that I can get this by the pmc application, but I not a realy  friend of polling. 

I would prefer a file with information in /var/run e.g. ptp.info.

In the combination with Inotify would by the application of our measurement unit  inform by every change.

The write of this file could be depend from new argument or now cfg  file entry.
 
What do you think about this or do you have a better idea to get this information without poll pmc.

Best regards,
Mario

Re: [Linuxptp-users] Feature enhancement for more comfortable usually interaction with a script language or other applications

[Richard C. <ric...@gm...>]

On Wed, Nov 13, 2013 at 02:36:40PM +0100, Mario Molitor wrote:
>  
> What do you think about this or do you have a better idea to get this information without poll pmc.

I don't like the file idea, but I can suggest two alternatives:

1. Management message "push" option. This would let the ptp4l program
   send changed status messages on the UDS interface.

2. Run a script. This would let the ptp4l program run a shell script
   after status changes, just like dhclient does.

Thoughts?

Thanks,
Richard

Re: [Linuxptp-users] Feature enhancement for more comfortable usually interaction with a script language or other applications

[Stephan G. <st...@ga...>]

Hi!

> 1. Management message "push" option. This would let the ptp4l program
>    send changed status messages on the UDS interface.

This depends on if we consider the UDS interface stable.

> 2. Run a script. This would let the ptp4l program run a shell script
>    after status changes, just like dhclient does.

Looks promising to me.

Regards,

Stephan

Re: [Linuxptp-users] Feature enhancement for more comfortable usually interaction with a script language or other applications

[Richard C. <ric...@gm...>]

On Thu, Nov 14, 2013 at 09:39:46AM +0100, Stephan Gatzka wrote:
> Hi!
> 
> > 1. Management message "push" option. This would let the ptp4l program
> >    send changed status messages on the UDS interface.
> 
> This depends on if we consider the UDS interface stable.

I mean to keep this interface as the one and only way of controlling
ptp4l at run time. Other ways have been defined to control a PTP
service, like SNMP. If we ever support these, then it will be as a
separate program to handle SNMP requests and translate them into
management packets on the local UDS interface.

So, I do view the UDS interface as "stable".

Thanks,
Richard

Re: [Linuxptp-users] Feature enhancement for more comfortable usually interaction with a script language or other applications

[Stephan G. <ste...@gm...>]

> I mean to keep this interface as the one and only way of controlling
> ptp4l at run time. Other ways have been defined to control a PTP
> service, like SNMP. If we ever support these, then it will be as a
> separate program to handle SNMP requests and translate them into
> management packets on the local UDS interface.
> 
> So, I do view the UDS interface as "stable".

Than it probably makes sense to go for the UDS interface. Some 
information like master_offset are updated very often. So it doesn't 
always make sense to run a script if "something" changes.

Regards,

Stephan

Re: [Linuxptp-users] Feature enhancement for more comfortable usually interaction with a script language or other applications

[Keller, J. E <jac...@in...>]

On Thu, 2013-11-14 at 09:33 +0100, Richard Cochran wrote:
> On Wed, Nov 13, 2013 at 02:36:40PM +0100, Mario Molitor wrote:
> >  
> > What do you think about this or do you have a better idea to get this information without poll pmc.
> 
> I don't like the file idea, but I can suggest two alternatives:
> 
> 1. Management message "push" option. This would let the ptp4l program
>    send changed status messages on the UDS interface.
> 

I think this is the best option.. Then the client can poll the UDS
interface and do whatever it wants.

> 2. Run a script. This would let the ptp4l program run a shell script
>    after status changes, just like dhclient does.
> 

This could work, but I think its cleaner if we push to the UDS
interface, and the client can then read and do whatever it wants
(possibly run a script, even)

I think that is a clean use of the management interface.

Regards,
Jake

> Thoughts?
> 
> Thanks,
> Richard
> 
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] Feature enhancement for more comfortable usually interaction with a script language or other applications

[Delio B. <dbr...@au...>]

On Nov 14, 2013, at 8:49 PM, Keller, Jacob E wrote:
> On Thu, 2013-11-14 at 09:33 +0100, Richard Cochran wrote:
>> On Wed, Nov 13, 2013 at 02:36:40PM +0100, Mario Molitor wrote:
>>> 
>>> What do you think about this or do you have a better idea to get this information without poll pmc.
>> 
>> I don't like the file idea, but I can suggest two alternatives:
>> 
>> 1. Management message "push" option. This would let the ptp4l program
>>   send changed status messages on the UDS interface.
>> 
> 
> I think this is the best option.. Then the client can poll the UDS
> interface and do whatever it wants.

+1 for UDS "push"

--
Delio

Re: [Linuxptp-users] Feature enhancement for more comfortable usually interaction with a script language or other applications

[Mario M. <mar...@we...>]

After read of all hints and suggestions I would also prefer the use of UDS “push”.

Regards,

Mario