In pvops, in the function xenbus_file_write of file drivers/xen/xenfs/xenbus.c.
In the switch, there is no XS_INTRODUCE which is used to create a new domain.
These commands are eliminated here, since in default, a Domu cannot use these
commands.
static ssize_t xenbus_file_write(struct file *filp,
const char __user *ubuf,
size_t len, loff_t *ppos)
{
struct xenbus_file_priv *u = filp->private_data;
uint32_t msg_type;
int rc = len;
int ret;
LIST_HEAD(staging_q);
/*
* We're expecting usermode to be writing properly formed
* xenbus messages. If they write an incomplete message we
* buffer it up. Once it is complete, we act on it.
*/
/*
* Make sure concurrent writers can't stomp all over each
* other's messages and make a mess of our partial message
* buffer. We don't make any attemppt to stop multiple
* writers from making a mess of each other's incomplete
* messages; we're just trying to guarantee our own internal
* consistency and make sure that single writes are handled
* atomically.
*/
mutex_lock(&u->msgbuffer_mutex);
/* Get this out of the way early to avoid confusion */
if (len == 0)
goto out;
/* Can't write a xenbus message larger we can buffer */
if ((len + u->len) > sizeof(u->u.buffer)) {
/* On error, dump existing buffer */
u->len = 0;
rc = -EINVAL;
goto out;
}
ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
if (ret == len) {
rc = -EFAULT;
goto out;
}
/* Deal with a partial copy. */
len -= ret;
rc = len;
u->len += len;
/* Return if we haven't got a full message yet */
if (u->len < sizeof(u->u.msg))
goto out; /* not even the header yet */
/* If we're expecting a message that's larger than we can
possibly send, dump what we have and return an error. */
if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
rc = -E2BIG;
u->len = 0;
goto out;
}
if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
goto out; /* incomplete data portion */
/*
* OK, now we have a complete message. Do something with it.
*/
msg_type = u->u.msg.type;
switch (msg_type) {
case XS_TRANSACTION_START:
case XS_TRANSACTION_END:
case XS_DIRECTORY:
case XS_READ:
case XS_GET_PERMS:
case XS_RELEASE:
case XS_GET_DOMAIN_PATH:
case XS_WRITE:
case XS_MKDIR:
case XS_RM:
case XS_SET_PERMS:
/* Send out a transaction */
ret = xenbus_write_transaction(msg_type, u);
break;
case XS_WATCH:
case XS_UNWATCH:
/* (Un)Ask for some path to be watched for changes */
ret = xenbus_write_watch(msg_type, u);
break;
default:
ret = -EINVAL;
break;
}
if (ret != 0)
rc = ret;
/* Buffered message consumed */
u->len = 0;
out:
mutex_unlock(&u->msgbuffer_mutex);
return rc;
}
Jun Zhu
Citrix Systems UK
________________________________________
发件人: Patrick Colp [pjcolp@xxxxxxxxx]
发送时间: 2010年8月31日 下午 1:51
收件人: Ian Campbell
抄送: Jun Zhu (Intern); Tim Deegan; dgdegra@xxxxxxxxxxxxx;
xen-devel@xxxxxxxxxxxxxxxxxxx
主题: Re: [Xen-devel] Re: [PATCH] libxl: fix xenstore connection when run in domU
Which XenBus driver is this? In Linux? I've certainly had no issues
running a Mini-OS XenStore stubdom (at least not in regards to missing
things like XS_INTRODUCE).
Patrick
On 31 August 2010 03:44, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Tue, 2010-08-31 at 11:32 +0100, Jun Zhu (Intern) wrote:
>>
>> If xenstore runs in a seperate domain, it must use xenbus dev to
>> communicate. If so, the xenstore commands in Xenbus driver are not
>> complete. For example, it does not contain XS_INTRODUCE now.
>
> IIRC Diego's original xenstore-stubdom patch series from way back when
> (posted to the list by Diego and again later by Alex Zeffertt) included
> patches to the kernel side xenbus driver to resolve issues like this.
>
> Ian.
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home