Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
> -Original Message- > From: Miroslav Lichvar > Sent: Thursday, October 29, 2020 10:24 AM > To: Richard Cochran > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology > > On Thu, Oct 29, 2020 at 09:53:42AM -0700, Richard Cochran wrote: > > 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 slave at the same time in different contexts. > > > > So how about using client/server in the context of the PTP and > > source/sink in phc2sys and ts2phc? > > Yes, I think I would prefer that over source/sink everywhere. To me, > server and client are network-related terms, something implementing a > network protocol, which in context of PTP has a single clock. Sink and > source work as more general terms. As an adjective of a clock, "source > clock" works well, but "sink clock" sounds weird to me. I found this > term in some DisplayPort and HDMI documentation. Maybe it's alright, I > don't know. Native speakers should give you a better feedback or > suggestions. If we used "time source" and "time sink", but that wouldn't include clock in the name. What about "target clock"? ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On Thu, Oct 29, 2020 at 09:53:42AM -0700, Richard Cochran wrote: > 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 slave at the same time in different contexts. > > So how about using client/server in the context of the PTP and > source/sink in phc2sys and ts2phc? Yes, I think I would prefer that over source/sink everywhere. To me, server and client are network-related terms, something implementing a network protocol, which in context of PTP has a single clock. Sink and source work as more general terms. As an adjective of a clock, "source clock" works well, but "sink clock" sounds weird to me. I found this term in some DisplayPort and HDMI documentation. Maybe it's alright, I don't know. Native speakers should give you a better feedback or suggestions. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 slave at the same time in different contexts. So how about using client/server in the context of the PTP and source/sink in phc2sys and ts2phc? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On Tue, Oct 27, 2020 at 04:26:53PM -0700, Richard Cochran wrote: > 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 is using? I know some people that use it with PTP > > and maybe it would be easier for a wider adoption. > > I considered that, but ... > > How would you feel about client/server terminology in the context of > phc2sys? 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 slave at the same time in different contexts. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On 10/27/2020 4:26 PM, Richard Cochran wrote: > 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 is using? I know some people that use it with PTP >> and maybe it would be easier for a wider adoption. > > I considered that, but ... > > How would you feel about client/server terminology in the context of > phc2sys? > > For example, you would have to call eth0 the "server" and > CLOCK_REALTIME the "client". > > Thoughts? > > Richard For myself, I would be reasonably ok with this, but I do prefer the source/sink terminology overall because it feels more accurate to this relationship. Thanks, Jake ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 is using? I know some people that use it with PTP > and maybe it would be easier for a wider adoption. I considered that, but ... How would you feel about client/server terminology in the context of phc2sys? For example, you would have to call eth0 the "server" and CLOCK_REALTIME the "client". Thoughts? Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On Tue, Aug 18, 2020 at 01:43:02PM -0700, Richard Cochran wrote: > The information flowing through a PTP network may best be described as > a time signal. As any EE will tell you, a signal flows from its > source to one or more sinks. Thus we can trace the time signal in a > PTP network as it flows from a given time source to a time sink. 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 is using? I know some people that use it with PTP and maybe it would be easier for a wider adoption. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
Hi, in regard of „master at doing something“, what about „Stalwart“ instead of „Slave“? You can keep the abbreviation „s“ (as in „slave“ or „sink“), it refers to „follower“ as in „fan“ and even means „loyal“ (as for synchronisation). The only drawback: It‘s very uncommon in technical context and therefore not really understandable (at least now). Holen Sie sich Outlook für iOS<https://aka.ms/o0ukef> - Unsere Datenschutzerklärung finden Sie hier<https://www.ravenna-network.com/privacy>. | See our Privacy Policy here<https://www.ravenna-network.com/privacy>. Von: Richard Hill Gesendet: Friday, August 21, 2020 7:00:51 AM An: 'Vladimir Oltean' Cc: linuxptp-devel@lists.sourceforge.net Betreff: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology > But what is wrong with 'Master' - ie Master Craftsman, Master > Boatmaker, Master Baker, therefore Master Clock. And doesn't it > correctly describe what it's function is ? > What do you mean what's wrong with it? The same thing that is wrong with > 'slave', of course. Which is one meaning of it. "But words have more > than one meaning", I hear you say? Yes, sure, here is what the Oxford > Learner's Dictionary has to say about the word 'slave': If you want to find an alternate meaning you don't like for just about any word, you'll probably find one. The word Master doesn't require Slave. But one of the meanings of master is "master at doing something " - in our case Master of having a very good time source. Or are we to drop the word Master from society because some people may be offended by it ? Maybe we should drop other words too - the dictionary is probably full of them. I see no good reason to drop the term "PTP-Master" Yes, Richard probably had his mind set already, but to me replacing Master/Slave with all the alternatives I've seen will just give newcomers to PTP a hard time to understand. ___ 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 RFC 0/1] Introduce inclusive terminology
> But what is wrong with 'Master' - ie Master Craftsman, Master > Boatmaker, Master Baker, therefore Master Clock. And doesn't it > correctly describe what it's function is ? > What do you mean what's wrong with it? The same thing that is wrong with > 'slave', of course. Which is one meaning of it. "But words have more > than one meaning", I hear you say? Yes, sure, here is what the Oxford > Learner's Dictionary has to say about the word 'slave': If you want to find an alternate meaning you don't like for just about any word, you'll probably find one. The word Master doesn't require Slave. But one of the meanings of master is "master at doing something " - in our case Master of having a very good time source. Or are we to drop the word Master from society because some people may be offended by it ? Maybe we should drop other words too - the dictionary is probably full of them. I see no good reason to drop the term "PTP-Master" Yes, Richard probably had his mind set already, but to me replacing Master/Slave with all the alternatives I've seen will just give newcomers to PTP a hard time to understand. ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On 8/20/2020 2:16 PM, Vladimir Oltean wrote:
> On Thu, Aug 20, 2020 at 11:07:09AM -0700, Richard Cochran wrote:
>> On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:
>>
>>> What if the terms on which IEEE 1588 settles are not the terms in your
>>> mind ("source"/"sink")?
>>
>> Because linuxptp is widely deployed, what we do could very well
>> influence the committee work.
>>
>
> Aren't there simpler ways to influence the 1588 working groups, like
> sending them a direct email? I don't think a significant number of them
> are subscribed to linuxptp-devel@lists.sourceforge.net.
> Which begs the question, if you already had your mind set on a
> particular list of euphemisms, and you weren't actually looking for a
> second opinion from this group, why send this RFC patch at all? You can
> commit changes to linuxptp without peer review at any time.
>
> Also (and this might be not for me to understand), if you are:
>
>> doubtful whether changing the wording of the 1588 standard will
>> actually have a positive effect on the world or not
>
> then why pressure them in the first place to make this change?
>
The expectation is that the standards committee will change the terms
one way or another in the future.
If we assume that the terms master and slave will be removed, and do not
like many of the alternative proposals, it makes sense to try and
influence them to choose proposals we do find more suitable.
Doing nothing may increase the probability that the standards committee
chooses terms that Richard clearly dislikes: (leader/follower, etc).
> Thanks,
> -Vladimir
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On Thu, Aug 20, 2020 at 11:07:09AM -0700, Richard Cochran wrote:
> On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote:
>
> > What if the terms on which IEEE 1588 settles are not the terms in your
> > mind ("source"/"sink")?
>
> Because linuxptp is widely deployed, what we do could very well
> influence the committee work.
>
Aren't there simpler ways to influence the 1588 working groups, like
sending them a direct email? I don't think a significant number of them
are subscribed to linuxptp-devel@lists.sourceforge.net.
Which begs the question, if you already had your mind set on a
particular list of euphemisms, and you weren't actually looking for a
second opinion from this group, why send this RFC patch at all? You can
commit changes to linuxptp without peer review at any time.
Also (and this might be not for me to understand), if you are:
> doubtful whether changing the wording of the 1588 standard will
> actually have a positive effect on the world or not
then why pressure them in the first place to make this change?
Thanks,
-Vladimir
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On Thu, Aug 20, 2020 at 07:50:29PM +0100, Richard Hill wrote: > the word 'Slave' needs to be dropped ASAP. > Waiting for the official committee might be like watching paint dry. > Sorry for being a bit thick here, but where is this sudden urgency coming from? It's been like this for many, many years. It is in the realm of things that could have been better in hindsight, but don't really make any difference. > But what is wrong with 'Master' - ie Master Craftsman, Master > Boatmaker, Master Baker, therefore Master Clock. And doesn't it > correctly describe what it's function is ? What do you mean what's wrong with it? The same thing that is wrong with 'slave', of course. Which is one meaning of it. "But words have more than one meaning", I hear you say? Yes, sure, here is what the Oxford Learner's Dictionary has to say about the word 'slave': 3. (specialist) a device that is directly controlled by another one. https://www.oxfordlearnersdictionaries.com/definition/english/slave_1 So, there you go. It is illogical to be offended by the word 'slave' but not by 'master'. -Vladimir ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
but rather replace "slave" with "sink" starting right away. > But what is wrong with 'Master' - ie Master Craftsman, Master Boatmaker, > Master Baker, > therefore > Master Clock. And doesn't it correctly describe what it's function is ? My plan is leave the "master" term in place for now. 'For now'? I've not seen a term mentioned that comes anywhere close to being as good as the current term. If it isn't broke, don't fix it ? ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 rather replace "slave" with "sink" starting right away. > But what is wrong with 'Master' - ie Master Craftsman, Master Boatmaker, > Master Baker, > therefore > Master Clock. And doesn't it correctly describe what it's function is ? My plan is leave the "master" term in place for now. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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.
But what is wrong with 'Master' - ie Master Craftsman, Master Boatmaker, Master
Baker,
therefore
Master Clock. And doesn't it correctly describe what it's function is ?
-Original Message-
From: Richard Cochran [mailto:richardcoch...@gmail.com]
Sent: Donnerstag, 20. August 2020 19:07
To: Vladimir Oltean
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 widely deployed, what we do could very well
influence the committee work.
> Will there be a third set of names for clocks
> and ports?
For anything that affects protocol correctness, then we'll map the
internal terms to the official ones. However, if I'm not wrong, the
strings "master" and "slave" are not part of protocol at all.
> What about a sort of internationalization support in linuxptp, then
> anybody could call "master" and "slave" whatever they feel like.
That won't work for program identifiers.
Thanks,
Richard
___
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 RFC 0/1] Introduce inclusive terminology
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 widely deployed, what we do could very well
influence the committee work.
> Will there be a third set of names for clocks
> and ports?
For anything that affects protocol correctness, then we'll map the
internal terms to the official ones. However, if I'm not wrong, the
strings "master" and "slave" are not part of protocol at all.
> What about a sort of internationalization support in linuxptp, then
> anybody could call "master" and "slave" whatever they feel like.
That won't work for program identifiers.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On Thu, Aug 20, 2020 at 08:25:39AM -0700, Richard Cochran wrote:
>
> I expect that the change in the IEEE standard and in the industry is
> coming.
So, yes, the IEEE 1588 committee has changed terminology before
("time-aware bridge" -> "time-aware relay") and may do so again, to
remove words that are out of fashion today. Then linuxptp could follow
suite, as it always has, supporting a new 1588 revision with a new set
of knobs.
What I don't get is where is the need for linuxptp to "take the lead" on
this topic?
> I will not enter a bike shedding debate about whether leader/follower
> sounds better or not. I have picked source/sink because that makes
> most sense to me.
What if the terms on which IEEE 1588 settles are not the terms in your
mind ("source"/"sink")? Will there be a third set of names for clocks
and ports?
What about a sort of internationalization support in linuxptp, then
anybody could call "master" and "slave" whatever they feel like.
> However, it certainly won't hurt anybody to change the terms, and it
> is easy to do.
But if you need to mention during every email reply that you're not
really up for bikeshedding, this might in fact prove your free time is
hurt more than you intended to by finding replacement terms that please
everyone. That, in fact, is the whole problem. There's nothing
defendable about the word "slave", it's just what the IEEE 1588
standards committee used.
Thanks,
-Vladimir
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 it, aren't you? ;^) > I mean, yes, a slave is not only somebody who works for a master, but > somebody who does so for free and against their will. Whereas digital > entities don't really have a will, and therefore the term is > inappropriately used. In that sense, I think 'subordinate' is the word > you're looking for. Simple replacement and not as extravagant as > 'sheep'. My suggestion of "sheep" was meant to be sarcastic! > That being said, 'master'/'slave' is a well-established technical > terminology which has little to do with human slavery, mind you. I appreciate this point... more below... > I think you're going to have some difficulty fixing up config-visible > options such as 'slaveOnly' (without breaking deployments, which you > mentioned as one goal), so I'm not really sure what's the point, if > "words of dubious moral value" are not completely purged from the code > base. So it is clear that the configuration will need to be stay in place for the present, but it can be gradually replaced. My idea is to add "sinkOnly" as an alias and then eventually replace "slaveOnly" with whatever the revision of the published standard mandates. > In the end I believe it's a balance between what problems this change is > solving, vs what problems it's creating. At least in my mind, I don't associate the "loaded" terms with slavery when used in the context of computer networking. I am also doubtful whether changing the wording of the 1588 standard will actually have a positive effect on the world or not. However, it certainly won't hurt anybody to change the terms, and it is easy to do. Thus I am willing to make the change. I expect that the change in the IEEE standard and in the industry is coming. The Linux kernel has already amended its coding style guidelines. For this project, I want to take the initiative and switch to terminology that at least makes sense to me. After all, I will be the one who will have to stare at the source code for years to come, and if I see "leader/follower", for example, it will drive me crazy. If I follow through on this change, then it will be a top-down decision. However, I put up this as an RFC in order to allow people to air their opinions on the topic and gauge the community's response. You brought up the point of whether to make the change at all, and I think that is a valid question, but it is a different question from the choice of the replacement terminology. I will not enter a bike shedding debate about whether leader/follower sounds better or not. I have picked source/sink because that makes most sense to me. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
Let's take it easy on one another. Initially it looks it is going towards humanoid rights, but it is different than that (more than machines' will). More towards sensitivities of the users/admin who'd read/use such terms day in/out and associated sensibilities. Unless it comes from standard, different people can choose similar but may not the same terms, and in this project contributors can take initiative & settle on something (doc, messages etc). Regards, Jagmeet On Thu, Aug 20, 2020 at 6:34 PM 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 it, aren't you? > > I mean, yes, a slave is not only somebody who works for a master, but > somebody who does so for free and against their will. Whereas digital > entities don't really have a will, and therefore the term is > inappropriately used. In that sense, I think 'subordinate' is the word > you're looking for. Simple replacement and not as extravagant as > 'sheep'. > > That being said, 'master'/'slave' is a well-established technical > terminology which has little to do with human slavery, mind you. > I think you're going to have some difficulty fixing up config-visible > options such as 'slaveOnly' (without breaking deployments, which you > mentioned as one goal), so I'm not really sure what's the point, if > "words of dubious moral value" are not completely purged from the code > base. > > In the end I believe it's a balance between what problems this change is > solving, vs what problems it's creating. > > Thanks, > -Vladimir > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- Best Regards, ~ Jagmeet Singh Hanspal ~ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 it, aren't you? I mean, yes, a slave is not only somebody who works for a master, but somebody who does so for free and against their will. Whereas digital entities don't really have a will, and therefore the term is inappropriately used. In that sense, I think 'subordinate' is the word you're looking for. Simple replacement and not as extravagant as 'sheep'. That being said, 'master'/'slave' is a well-established technical terminology which has little to do with human slavery, mind you. I think you're going to have some difficulty fixing up config-visible options such as 'slaveOnly' (without breaking deployments, which you mentioned as one goal), so I'm not really sure what's the point, if "words of dubious moral value" are not completely purged from the code base. In the end I believe it's a balance between what problems this change is solving, vs what problems it's creating. Thanks, -Vladimir ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 / sink are ok too, and maybe a > super-source as GM? That is an interesting possibility. I had also thought about "ultimate source" for GM, but it sounds a bit weird to me. For now, my plan is to start replacing "slave" with "sink", leaving "master" alone until the sink term is established. Maybe leaving the term "master" in place will find acceptance socially. It would preserve the port role abbreviations M and S. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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. Anyways, source / sink are ok too, and maybe a super-source as GM? On Wed, Aug 19, 2020, 22:12 Richard Cochran wrote: > 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 leader! > > When synchronized, a clock does not "follow" but rather matches > exactly with small adjustments. So I guess that means leader/matcher? > > And as far as sheep dogs go, the dogs are not the leaders, but rather > the farmer. Maybe we should use the terms shepard/sheep? > > In any case, this is just the kind of bikeshedding discussion that I > want to avoid. Just to be clear, I will not accept leader/follower > because it simply sounds silly. > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
Hi, Personally I prefer leader/followers over source/sink. Source remind me of source code. And sink remind me of where our water goes after we use them. Client/server is good as well. Erez From: Jagmeet Singh Hanspal Sent: Wednesday, 19 August 2020 06:00 To: Richard Cochran Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology Few suggestions: AVB uses end-stations and relays, as well as initiator/responder as the context maybe, like: - PTP End Instance: The AVB talkers and listener end-stations. It may also be a GM. - PTP Relay Instance: Could be inside a bridge, a router, or a multiport end-station. - PTP .1AS initiator: The node that has initiated the Peer-to-Peer delay mechanism. - PTP .1AS responder: The peer-node that is responding to the P2P delay request. And Source/Sink or Client/Server may also be ok, in the documentation. The master/slave etc will have to be replaced in the IEEE 1588 and GM etc all the way to ITU-T telecom standards. The term, “slave” has the negative connotations, rather a “follower” that chooses its leader or role-model (GM -> RM) and looks-up to follow its lead. Anyways, even in the IEEE standard (like Richard mentioned), a master is not employing slaves, instead, it is the follower that is "choosing" who it needs to consider a leader and subsequently follow it, so in our conversations, we are starting to use these terminologies instead. Regards, Jagmeet On Wed, Aug 19, 2020 at 3:26 AM Richard Cochran mailto:richardcoch...@gmail.com>> wrote: 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 simply leaving the original name as a deprecated > alternative name with an explanation. That is what I was thinking, too. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net<mailto:Linuxptp-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-devel=02%7C01%7Cerez.geva.ext%40siemens.com%7C1d1f02a547f94263c49c08d843f492f1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637334064998468858=D7MDFG6DWSk6Nl7VwYkKZr3IBSRRQSREMTK3QzpN0oE%3D=0> -- Best Regards, ~ Jagmeet Singh Hanspal ~ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
A sheep herder dog is leading the sheep. And yet it is all over the place. Leading does not mean you are a head on behind. It means that all the reset are following you. Some might be a head and slowing. Some might be behind and being pushed by the leader. I short. It means that they are follows the leader. Erez -Original Message- From: Richard Cochran Sent: Wednesday, 19 August 2020 17:20 To: Geva, Erez (ext) (DI PA CI R 3) Cc: jagmeet.hans...@gmail.com; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology 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 silly for a synchronization protocol, if you ask me. > Source remind me of source code. > > And sink remind me of where our water goes after we use them. :) Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 leader! When synchronized, a clock does not "follow" but rather matches exactly with small adjustments. So I guess that means leader/matcher? And as far as sheep dogs go, the dogs are not the leaders, but rather the farmer. Maybe we should use the terms shepard/sheep? In any case, this is just the kind of bikeshedding discussion that I want to avoid. Just to be clear, I will not accept leader/follower because it simply sounds silly. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
P.S. The sink goes in one direction. -Original Message- From: Geva, Erez (ext) (DI PA CI R 3) Sent: Wednesday, 19 August 2020 18:14 To: richardcoch...@gmail.com Cc: jagmeet.hans...@gmail.com; linuxptp-devel@lists.sourceforge.net Subject: RE: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology A sheep herder dog is leading the sheep. And yet it is all over the place. Leading does not mean you are a head on behind. It means that all the reset are following you. Some might be a head and slowing. Some might be behind and being pushed by the leader. I short. It means that they are follows the leader. Erez -Original Message- From: Richard Cochran Sent: Wednesday, 19 August 2020 17:20 To: Geva, Erez (ext) (DI PA CI R 3) Cc: jagmeet.hans...@gmail.com; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology 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 silly for a synchronization protocol, if you ask me. > Source remind me of source code. > > And sink remind me of where our water goes after we use them. :) Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 silly for a synchronization protocol, if you ask me. > Source remind me of source code. > > And sink remind me of where our water goes after we use them. :) Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
Few suggestions: AVB uses end-stations and relays, as well as initiator/responder as the context maybe, like: - PTP End Instance: The AVB talkers and listener end-stations. It may also be a GM. - PTP Relay Instance: Could be inside a bridge, a router, or a multiport end-station. - PTP .1AS initiator: The node that has initiated the Peer-to-Peer delay mechanism. - PTP .1AS responder: The peer-node that is responding to the P2P delay request. And Source/Sink or Client/Server may also be ok, in the documentation. The master/slave etc will have to be replaced in the IEEE 1588 and GM etc all the way to ITU-T telecom standards. The term, “slave” has the negative connotations, rather a “follower” that chooses its leader or role-model (GM -> RM) and looks-up to follow its lead. Anyways, even in the IEEE standard (like Richard mentioned), a master is not employing slaves, instead, it is the follower that is "choosing" who it needs to consider a leader and subsequently follow it, so in our conversations, we are starting to use these terminologies instead. Regards, Jagmeet On Wed, Aug 19, 2020 at 3:26 AM Richard Cochran wrote: > 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 simply leaving the original name as a deprecated > > alternative name with an explanation. > > That is what I was thinking, too. > > Thanks, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > -- Best Regards, ~ Jagmeet Singh Hanspal ~ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
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 simply leaving the original name as a deprecated > alternative name with an explanation. That is what I was thinking, too. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On 8/18/2020 1:43 PM, Richard Cochran wrote: > There is an industry wide effort underway to replace historically and > culturally loaded terms like master/slave with neutral alternatives. > The IEEE 1588 committee will most likely amend the standard, but so > far no consensus on the new terminology has been reached. > > Most of the proposed alternative terms are, IMHO, either awful > sounding or just plain silly. There is a window of opportunity for > this project to take the lead in recommending terminology that is, at > the same time, both culturally neutral and technically more accurate. > > The original designation of the PTP port roles made little sense in > the first place. Under the institution of slavery, the role of a > slave is to perform work for the master. In a PTP network it is the > "master" port that serves the slaves, the opposite of what the terms > suggest. > > The information flowing through a PTP network may best be described as > a time signal. As any EE will tell you, a signal flows from its > source to one or more sinks. Thus we can trace the time signal in a > PTP network as it flows from a given time source to a time sink. > > The approach I'm considering is to start today with the human readable > program help, after 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. > 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 simply leaving the original name as a deprecated alternative name with an explanation. > Thanks, > Richard > > > Richard Cochran (1): > Convert usage messages to time source/sink terminology. > > phc2sys.c | 10 +- > ptp4l.c | 2 +- > 2 files changed, 6 insertions(+), 6 deletions(-) > This gets a +1 from me! Thanks, Jake ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
On 8/18/20, Richard Cochran wrote: > There is an industry wide effort underway to replace historically and > culturally loaded terms like master/slave with neutral alternatives. ... > The information flowing through a PTP network may best be described as > a time signal. As any EE will tell you, a signal flows from its > source to one or more sinks. Thus we can trace the time signal in a > PTP network as it flows from a given time source to a time sink. Brilliant! -Dale ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
