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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

George Dunlap writes ("Re: [PATCH v8 6/8] docs: documentation about static 
shared memory regions"):
> > On Oct 31, 2018, at 3:35 PM, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
> > wrote:
> > On Wed, 31 Oct 2018, Ian Jackson wrote:
> >> But we need to know what the new terminology should be.  Is `owner'
> >> and `borrower' a good pairing ?  `Borrow' is perhaps not quite right
> >> because it implies that the original owner no longer has it while it's
> >> borrowed.  OTOH Rust has read-only borrows which work similarly so
> >> borrowing in a way that doesn't exclude the original has at least some
> >> precedent...
... 
> > Other options I could think of:
> > 
> > proprietor / renter
> > benefactor / dependent

IMO these are definitely worse.

> > But I think owner/borrower is the best choice -- also considering that
> > "own" and "borrow" are taught in very basic English classes, anybody
> > should understand them well.

Right.

> master / slave was never the right image, because the non-owning domains 
> aren’t being controlled by the owning domain.  But neither really is 
> “borrower” — borrowing implies that the original owner doesn’t have it for 
> some period of time.

See my comments about Rust.  I think this is OK,

> Given that you have one owner and a number of other domains that use it at 
> the same time, it’s a lot more like a pub or a cafe than an apartment or 
> loan.  So “server / client” is probably the most accurate picture; if that’s 
> considered too confusing, maybe “provider / consumer”, or something like that.

Server/client implies that the owner does something active to handle
the client's wishes, whereas actually the owner just sits there and
the borrowers help themselves (well, libxl helps them).

Provider/consumer is OK but `consumer' can suggest the thing is used
up.  I think `borrower' is better than `consumer'.  `Owner' definitely
seems right for the owner side.

I think the final decision is up to Stefano.

Ian.

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