|
|
|
|
|
|
|
|
|
|
xen-devel
Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1
Adam Heath wrote:
Er, no. The blkback allocates it's own id, which is passed around between
them.
The blkback them maps the id into a handle structure, which then has a void
*data(or a union, if you want) that maintains a pointer to a filename, or
reference to a block device, then a function dispatch table that knows how to
handle the requests.
Are you suggesting this is how it should work?
In xen-unstable, the control tools communicate through a ring-queue (a
fixed length queue with a maximum message size of 60) to the device
backends and frontends. They do not map any memory (besides the ring
queue).
The virtual block device creation process looks something like this:
1) control tools send a create message through the ring queue to the backend
2) for each virtual block device, control tools send a
BLKIF_BE_VBD_CREATE message to the backend
This message is fixed length (see
/usr/include/xen/io/domain_controller.h--blkif_be_vbd_create_t) and has
two fields for the backend device number (pdevice) and the frontend
device number (vdevice).
When the frontend boots up, it sends the control tools a series of
messages. One of those message contains a share memory handle which the
controls then pass to the backend. The backend maps this memory address
and the frontend and backend use this memory area to do the actual
operations of the block device.
The control tools can only communicate with the backend (right now) via
the ring queue. You can't assume that the tools are in the same domain
as the backend (so you can't just do an ioctl or something to the kernel).
If you wanted to support passing files, you would have to extend the
blkif_be_vbd_create_t structure to communicate a filename. This is the
problem.
Regards,
Anthony Liguori
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), (continued)
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Andrew Warfield
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Anthony Liguori
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Adam Heath
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Mark Williamson
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Adam Heath
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Mark Williamson
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Anthony Liguori
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]),
Anthony Liguori <=
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Adam Heath
- Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Anthony Liguori
Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2]), Philip R Auld
|
|
|
|
|