Re: [Xen-devel] [PATCH v8 6/8] docs: documentation about static shared memory regions

[Julien Grall <julien.grall@xxxxxxx>]

On 10/30/18 6:58 PM, Stefano Stabellini wrote:
> Hi Ian,
>
> I am replying here, but I am addressing also your other emails. This is
> v8 of the series, the first version was sent in Aug 2017, and the design
> document, including the master/slave terminology, was accepted even
> before that.
>
> At this stage I am only looking for minor suggestions for improvements.
> I am not going to address a v1-style review at this point.
>
>
> On Tue, 30 Oct 2018, Ian Jackson wrote:
> > > diff --git a/docs/man/xl-static-shm-configuration.pod.5 
> > > b/docs/man/xl-static-shm-configuration.pod.5
> > > new file mode 100644
> > > index 0000000..81ff3f1
> > > --- /dev/null
> > > +++ b/docs/man/xl-static-shm-configuration.pod.5
> > ...
> > > +* Uniquely identified by a string that is no longer than 128 characters, which
> > > +is called an B<identifier> in this document.
> > > +
> > > +* Backed by exactly one domain, which is called a B<master> domain, and all
> > > +the other domains who are also sharing this region are called B<slave>s.
> > Would it be possible to rename these concepts ?  Nowadays it is
> > generally preferable to avoid master/slave terminology.  Perhaps
> > `owning' and `borrowing' domains ?  I'm not sure exactly what the
> > precise relationship is.  It would be good to explain that by
> > explaining what the semantic difference is between the roles of the
> > owning and borrowing domains.
> I completely agree with you here, and getting rid of the master/slave
> terminology would be nice, in retrospect, it was not a good choice. But
> this is v8 of the series, and as discussed a few times, we encourage
> reviewers to avoid this kind of requests at this stage.
While I agree that the design document has been accepted in Aug 2017,
the last things we want is adding more potentially offensive naming in 
Xen. It should not take too much to do the renaming (I am happy to help 
here).
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel