On Mon, May 05, 2014 at 02:39:58PM +0200, Jiri Benc wrote:
>
> I'll wrap them but the result will look uglier than this.
You version looks like this:
msg->management.targetPortIdentity.clockIdentity =
s->targetPortIdentity.clockIdentity;
msg->management.targetPortIdentity.portNumber =
htons(s->targetPortIdentity.portNumber);
Those are 103 and 104 columns. In contrast
msg->management.targetPortIdentity.clockIdentity =
s->targetPortIdentity.clockIdentity;
msg->management.targetPortIdentity.portNumber =
htons(s->targetPortIdentity.portNumber);
doesn't look so ugly to me. (Try an 80x25 xterm.)
> The border between COMMAND and SET is fuzzy here. I don't have too
> strong preference, except that I'd need to rewrite the set for the
> 4th time and retest it again :-/
Sorry for being a pain, but I really don't want to have any COMMANDs.
> > None of the existing COMMAND actions send any data (except for that
> > useless initialization key) or configure anything. Instead, they are
> > some sort of imperative like "restart!" or "reset!"
>
> Except that the INITIALIZE command does have data.
It has a key with *one* allowed value. That is virtually the same as
not having any data. The information content is zero.
> In fact, neither of those fits. The closest thing in the standard is
> unicast negotiation which uses a different TLV than management which is
> not applicable here. I won't argue about this but I'm not thrilled
> about rewriting and retesting this again for something that's just a
> matter of taste.
You are right that the signal TLV is closest. I wouldn't object to
having this TLV be a signal message instead. (I am planning on
implementing unicast negotiation.) But if it is a management message,
it really doesn't match the other commands.
- SAVE_IN_NON_VOLATILE_STORAGE
- RESET_NON_VOLATILE_STORAGE
- INITIALIZE
- FAULT_LOG_RESET
- ENABLE_PORT
- DISABLE_PORT
If you can't find the time to reform this patch, then I'll do it, if
you want. That won't spare you any testing, however.
Thanks,
Richard
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
