Re: [Xen-devel] Driver domains communication protocol proposal

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: [Xen-devel] Driver domains communication protocol 
proposal"):
> Ah, so what you're calling "vdi" in this case is a thing into which
> vbd's can plug -- what we might call the backend "node" for a
> particular disk image?

Yes.

> So we have:
> 
> [A] <--> [B] <--> { [C], [D], [E] }
> 
> Where:
> * A is the actual disk image on stable storage somewhere
> * B is the instance of the code that can access A and provide access
> to VMs which connect to it (not persistent)
> * C D and E are instances of code running inside the guest which
> connect to B and provide a block device to the guest OS which looks
> like A (again not persistent)
> 
> Is that correct?

Yes.

> I think calling A a "virtual disk image" makes the most sense; reusing
> that name for B is a bad idea given that it's already used for A in
> XenServer terminology.  (Jonathan, correct me if I'm wrong here.)

Right.

> I think that calling C D and E "vbd"s also makes sense.
> 
> So we just need to have a good name for the running instance of a
> blockback process / thread / whatever that accesses a particular VDI.
> Virtual disk provider (VDP)? Block back instance (BBI)?  Virtual block
> backend (VBB)?

Anything with "backend" in it is probably wrong because in general C,
D and E are backend/frontend pairs.

The thing that B has that A (the vdi) hasn't is that B has done all
the preparatory work necessary for accessing the vdi apart from
anything that involves exclusivity.

"nonexclusive image context" aka "nic" ? :-)
"nonexclusive image handle" aka "nih" :-)
"preparatory exclusive (not) image session" ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel