[help] problem with `tools/xenstore/xs.c: xs_talkv()`

[help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 778 bytes --]

Hi all,

    In  xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function,  there are
several lines as follow:

 437        mutex_lock(&h->request_mutex);



 438



 439        if (!xs_write_all(h->fd, &msg, sizeof(msg)))



 440                goto fail;



 441



 442        for (i = 0; i < num_vecs; i++)



 443                if (!xs_write_all(h->fd, iovec[i].iov_base,
iovec[i].iov_len))


 444                        goto fail;



 445



 446        ret = read_reply(h, &msg.type, len);



 447        if (!ret)



 448                goto fail;



 449



 450        mutex_unlock(&h->request_mutex);


The above seems to tell me that after writing to h->fd , the read_reply
invoking read_message which immediatelly  read from hd->fd?
What did it mean by this?


Thanks

[-- Attachment #1.2: Type: text/html, Size: 3721 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 1428 bytes --]

On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> wrote:

> Hi all,
>
>     In  xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function,  there are
> several lines as follow:
>
>  437        mutex_lock(&h->request_mutex);
>
>
>
>  438
>
>
>
>  439        if (!xs_write_all(h->fd, &msg, sizeof(msg)))
>
>
>
>  440                goto fail;
>
>
>
>  441
>
>
>
>  442        for (i = 0; i < num_vecs; i++)
>
>
>
>  443                if (!xs_write_all(h->fd, iovec[i].iov_base,
> iovec[i].iov_len))
>
>
>  444                        goto fail;
>
>
>
>  445
>
>
>
>  446        ret = read_reply(h, &msg.type, len);
>
>
>
>  447        if (!ret)
>
>
>
>  448                goto fail;
>
>
>
>  449
>
>
>
>  450        mutex_unlock(&h->request_mutex);
>
>
> The above seems to tell me that after writing to h->fd , the read_reply
> invoking read_message which immediatelly  read from hd->fd?
> What did it mean by this?
>
>
> Thanks
>

If hd->fd refers to a socket descriptor, it's understandable that writing
and then imediatelly reading, in which case the fd is returned by
get_handle(xs_daemon_socket(), flags).

But when fd is retrived by get_handle(xs_domain_dev(), flags), it means to
write to a file and then read from the same file imediatelly.
Dose it have something to do with the internal communication protocol?!

Thanks for replying.

[-- Attachment #1.2: Type: text/html, Size: 6237 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[Ian Campbell]

On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote:
> 
> 
> On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> wrote:
>         Hi all,
>          
>             In  xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function,
>          there are several lines as follow: 
>         
>         
>          437        mutex_lock(&h->request_mutex);
>         
>         
>                                                            
>          438
>         
>         
>                                                            
>          439        if (!xs_write_all(h->fd, &msg, sizeof(msg)))
>         
>         
>                                                               
>          440                goto fail;
>         
>         
>                                                            
>          441
>         
>         
>                                                            
>          442        for (i = 0; i < num_vecs; i++)
>         
>         
>                                                            
>          443                if (!xs_write_all(h->fd,
>         iovec[i].iov_base, iovec[i].iov_len))
>         
>         
>              
>          444                        goto fail;
>         
>         
>                                                            
>          445
>         
>         
>                                                            
>          446        ret = read_reply(h, &msg.type, len);
>         
>         
>                                                            
>          447        if (!ret)
>         
>         
>                                                           
>          448                goto fail;
>         
>         
>                                                            
>          449
>         
>         
>                                                            
>          450        mutex_unlock(&h->request_mutex);  
>         
>         
>         
>         
>         The above seems to tell me that after writing to h->fd , the
>         read_reply invoking read_message which immediatelly  read from
>         hd->fd?
>         What did it mean by this?
>         
>         
>         
>         
>         Thanks
> 
> If hd->fd refers to a socket descriptor, it's understandable that
> writing and then imediatelly reading, in which case the fd is returned
> by get_handle(xs_daemon_socket(), flags).
> 
> 
> But when fd is retrived by get_handle(xs_domain_dev(), flags), it
> means to write to a file and then read from the same file imediatelly.
> Dose it have something to do with the internal communication
> protocol?! 

Yes, the xenstore protocol involves both writing messages and reading
replies, but that seems trivially obvious so I'm afraid I really have no
idea what your question is nor what is confusing you. Perhaps describing
in more detail what you are trying to achieve will help?

Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions might also
help you consider what it is you are asking.


> 
> 
> Thanks for replying.
> 
> 
> 
> 
> 
> 



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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 2944 bytes --]

On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote:
> >
> >
> > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> wrote:
> >         Hi all,
> >
> >             In  xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function,
> >          there are several lines as follow:
> >
> >
> >          437        mutex_lock(&h->request_mutex);
> >
> >
> >
> >          438
> >
> >
> >
> >          439        if (!xs_write_all(h->fd, &msg, sizeof(msg)))
> >
> >
> >
> >          440                goto fail;
> >
> >
> >
> >          441
> >
> >
> >
> >          442        for (i = 0; i < num_vecs; i++)
> >
> >
> >
> >          443                if (!xs_write_all(h->fd,
> >         iovec[i].iov_base, iovec[i].iov_len))
> >
> >
> >
> >          444                        goto fail;
> >
> >
> >
> >          445
> >
> >
> >
> >          446        ret = read_reply(h, &msg.type, len);
> >
> >
> >
> >          447        if (!ret)
> >
> >
> >
> >          448                goto fail;
> >
> >
> >
> >          449
> >
> >
> >
> >          450        mutex_unlock(&h->request_mutex);
> >
> >
> >
> >
> >         The above seems to tell me that after writing to h->fd , the
> >         read_reply invoking read_message which immediatelly  read from
> >         hd->fd?
> >         What did it mean by this?
> >
> >
> >
> >
> >         Thanks
> >
> > If hd->fd refers to a socket descriptor, it's understandable that
> > writing and then imediatelly reading, in which case the fd is returned
> > by get_handle(xs_daemon_socket(), flags).
> >
> >
> > But when fd is retrived by get_handle(xs_domain_dev(), flags), it
> > means to write to a file and then read from the same file imediatelly.
> > Dose it have something to do with the internal communication
> > protocol?!
>
> Yes, the xenstore protocol involves both writing messages and reading
> replies, but that seems trivially obvious so I'm afraid I really have no
> idea what your question is nor what is confusing you. Perhaps describing
> in more detail what you are trying to achieve will help?
>
> Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions might also
> help you consider what it is you are asking.
>
>
> >
> >
> > Thanks for replying.
> >
> >
> >
> >
> >
> >
>
>
Sorry about that, pehaps it results from my lacking of rudimentary
knowledge.
IIRC, when using socket, there are two buffers of which one is for sending
and another for receiving, so I  said 'If hd->fd refers to a socket
descriptor, it's understandable that
> writing and then imediatelly reading,'

But  when fd is retrived by get_handle(xs_domain_dev(), flags), it seems
that sender and receiver both writing to the same file, I have no idea
about the file /proc/xen/xenbus for communicating between domains?

[-- Attachment #1.2: Type: text/html, Size: 4874 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[Ian Campbell]

On Thu, 2012-08-09 at 10:42 +0100, 马磊 wrote:
> 
> 
> On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
>         On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote:
>         >
>         >
>         > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com>
>         wrote:
>         >         Hi all,
>         >
>         >             In  xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv
>         function,
>         >          there are several lines as follow:
>         >
>         >
>         >          437        mutex_lock(&h->request_mutex);
>         >
>         >
>         >
>         >          438
>         >
>         >
>         >
>         >          439        if (!xs_write_all(h->fd, &msg,
>         sizeof(msg)))
>         >
>         >
>         >
>         >          440                goto fail;
>         >
>         >
>         >
>         >          441
>         >
>         >
>         >
>         >          442        for (i = 0; i < num_vecs; i++)
>         >
>         >
>         >
>         >          443                if (!xs_write_all(h->fd,
>         >         iovec[i].iov_base, iovec[i].iov_len))
>         >
>         >
>         >
>         >          444                        goto fail;
>         >
>         >
>         >
>         >          445
>         >
>         >
>         >
>         >          446        ret = read_reply(h, &msg.type, len);
>         >
>         >
>         >
>         >          447        if (!ret)
>         >
>         >
>         >
>         >          448                goto fail;
>         >
>         >
>         >
>         >          449
>         >
>         >
>         >
>         >          450        mutex_unlock(&h->request_mutex);
>         >
>         >
>         >
>         >
>         >         The above seems to tell me that after writing to
>         h->fd , the
>         >         read_reply invoking read_message which immediatelly
>          read from
>         >         hd->fd?
>         >         What did it mean by this?
>         >
>         >
>         >
>         >
>         >         Thanks
>         >
>         > If hd->fd refers to a socket descriptor, it's understandable
>         that
>         > writing and then imediatelly reading, in which case the fd
>         is returned
>         > by get_handle(xs_daemon_socket(), flags).
>         >
>         >
>         > But when fd is retrived by get_handle(xs_domain_dev(),
>         flags), it
>         > means to write to a file and then read from the same file
>         imediatelly.
>         > Dose it have something to do with the internal communication
>         > protocol?!
>         
>         
>         Yes, the xenstore protocol involves both writing messages and
>         reading
>         replies, but that seems trivially obvious so I'm afraid I
>         really have no
>         idea what your question is nor what is confusing you. Perhaps
>         describing
>         in more detail what you are trying to achieve will help?
>         
>         Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions
>         might also
>         help you consider what it is you are asking.
>         
>         
>         >
>         >
>         > Thanks for replying.
>         >
>         >
>         >
>         >
>         >
>         >
>         
> 
> 
> Sorry about that, pehaps it results from my lacking of rudimentary
> knowledge.
> IIRC, when using socket, there are two buffers of which one is for
> sending and another for receiving, so I  said 'If hd->fd refers to a
> socket descriptor, it's understandable that
> > writing and then imediatelly reading,'
> 
> 
> But  when fd is retrived by get_handle(xs_domain_dev(), flags), it
> seems that sender and receiver both writing to the same file, I have
> no idea about the file /proc/xen/xenbus for communicating between
> domains?

/proc/xen/xenbus is a virtual device which arbitrates access to the
xenbus ring, which in turn is used to communicate with the xenstore
daemon. You could think of an fd onto this device as a socket connected
to the xenstore daemon.

Ian.


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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 2685 bytes --]

On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote:
> >
> >
> > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com> wrote:
> >         Hi all,
> >
> >             In  xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv function,
> >          there are several lines as follow:
> >
> >
> >          437        mutex_lock(&h->request_mutex);
> >
> >
> >
> >          438
> >
> >
> >
> >          439        if (!xs_write_all(h->fd, &msg, sizeof(msg)))
> >
> >
> >
> >          440                goto fail;
> >
> >
> >
> >          441
> >
> >
> >
> >          442        for (i = 0; i < num_vecs; i++)
> >
> >
> >
> >          443                if (!xs_write_all(h->fd,
> >         iovec[i].iov_base, iovec[i].iov_len))
> >
> >
> >
> >          444                        goto fail;
> >
> >
> >
> >          445
> >
> >
> >
> >          446        ret = read_reply(h, &msg.type, len);
> >
> >
> >
> >          447        if (!ret)
> >
> >
> >
> >          448                goto fail;
> >
> >
> >
> >          449
> >
> >
> >
> >          450        mutex_unlock(&h->request_mutex);
> >
> >
> >
> >
> >         The above seems to tell me that after writing to h->fd , the
> >         read_reply invoking read_message which immediatelly  read from
> >         hd->fd?
> >         What did it mean by this?
> >
> >
> >
> >
> >         Thanks
> >
> > If hd->fd refers to a socket descriptor, it's understandable that
> > writing and then imediatelly reading, in which case the fd is returned
> > by get_handle(xs_daemon_socket(), flags).
> >
> >
> > But when fd is retrived by get_handle(xs_domain_dev(), flags), it
> > means to write to a file and then read from the same file imediatelly.
> > Dose it have something to do with the internal communication
> > protocol?!
>
> Yes, the xenstore protocol involves both writing messages and reading
> replies, but that seems trivially obvious so I'm afraid I really have no
> idea what your question is nor what is confusing you. Perhaps describing
> in more detail what you are trying to achieve will help?
>
> Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions might also
> help you consider what it is you are asking.
>
>
> >
> >
> > Thanks for replying.
> >
> >
> >
> >
> >
> >
> The final read and write operations are achieved by:

read(fd, data, len);
write(fd, data, len);

Maybe my confusing lies in this point that what's the distinction between
the read and write operations on a socket file, the /proc/xen/xenbus, a
regular file?

[-- Attachment #1.2: Type: text/html, Size: 4563 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[Ian Campbell]

On Thu, 2012-08-09 at 10:50 +0100, 马磊 wrote:
> 
> 
> On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
>         On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote:
>         >
>         >
>         > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com>
>         wrote:
>         >         Hi all,
>         >
>         >             In  xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv
>         function,
>         >          there are several lines as follow:
>         >
>         >
>         >          437        mutex_lock(&h->request_mutex);
>         >
>         >
>         >
>         >          438
>         >
>         >
>         >
>         >          439        if (!xs_write_all(h->fd, &msg,
>         sizeof(msg)))
>         >
>         >
>         >
>         >          440                goto fail;
>         >
>         >
>         >
>         >          441
>         >
>         >
>         >
>         >          442        for (i = 0; i < num_vecs; i++)
>         >
>         >
>         >
>         >          443                if (!xs_write_all(h->fd,
>         >         iovec[i].iov_base, iovec[i].iov_len))
>         >
>         >
>         >
>         >          444                        goto fail;
>         >
>         >
>         >
>         >          445
>         >
>         >
>         >
>         >          446        ret = read_reply(h, &msg.type, len);
>         >
>         >
>         >
>         >          447        if (!ret)
>         >
>         >
>         >
>         >          448                goto fail;
>         >
>         >
>         >
>         >          449
>         >
>         >
>         >
>         >          450        mutex_unlock(&h->request_mutex);
>         >
>         >
>         >
>         >
>         >         The above seems to tell me that after writing to
>         h->fd , the
>         >         read_reply invoking read_message which immediatelly
>          read from
>         >         hd->fd?
>         >         What did it mean by this?
>         >
>         >
>         >
>         >
>         >         Thanks
>         >
>         > If hd->fd refers to a socket descriptor, it's understandable
>         that
>         > writing and then imediatelly reading, in which case the fd
>         is returned
>         > by get_handle(xs_daemon_socket(), flags).
>         >
>         >
>         > But when fd is retrived by get_handle(xs_domain_dev(),
>         flags), it
>         > means to write to a file and then read from the same file
>         imediatelly.
>         > Dose it have something to do with the internal communication
>         > protocol?!
>         
>         
>         Yes, the xenstore protocol involves both writing messages and
>         reading
>         replies, but that seems trivially obvious so I'm afraid I
>         really have no
>         idea what your question is nor what is confusing you. Perhaps
>         describing
>         in more detail what you are trying to achieve will help?
>         
>         Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions
>         might also
>         help you consider what it is you are asking.
>         
>         
>         >
>         >
>         > Thanks for replying.
>         >
>         >
>         >
>         >
>         >
>         >
>         The final read and write operations are achieved by:
> read(fd, data, len); 
> write(fd, data, len); 
> 
> 
> Maybe my confusing lies in this point that what's the distinction
> between the read and write operations on a socket file,
> the /proc/xen/xenbus, a regular file?

/proc/xen/xenbus is not a regular file. /proc is a virtual file system
where the files often have special and magic semantics. /proc/xen/xenbus
is effectively something like a character device, even though it isn't
actually implemented as one.

Take a look at drivers/xen/xenbus/xenbus_dev_frontend.c which is the
driver which backends /proc/xen/xenbus

Ian.


Ian.




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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 4580 bytes --]

On Thu, Aug 9, 2012 at 5:58 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-08-09 at 10:50 +0100, 马磊 wrote:
> >
> >
> > On Thu, Aug 9, 2012 at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com>
> > wrote:
> >         On Thu, 2012-08-09 at 08:07 +0100, 马磊 wrote:
> >         >
> >         >
> >         > On Wed, Aug 8, 2012 at 4:32 PM, 马磊 <aware.why@gmail.com>
> >         wrote:
> >         >         Hi all,
> >         >
> >         >             In  xen-4.1.2 src/tools/xenstore/xs.c: xs_talkv
> >         function,
> >         >          there are several lines as follow:
> >         >
> >         >
> >         >          437        mutex_lock(&h->request_mutex);
> >         >
> >         >
> >         >
> >         >          438
> >         >
> >         >
> >         >
> >         >          439        if (!xs_write_all(h->fd, &msg,
> >         sizeof(msg)))
> >         >
> >         >
> >         >
> >         >          440                goto fail;
> >         >
> >         >
> >         >
> >         >          441
> >         >
> >         >
> >         >
> >         >          442        for (i = 0; i < num_vecs; i++)
> >         >
> >         >
> >         >
> >         >          443                if (!xs_write_all(h->fd,
> >         >         iovec[i].iov_base, iovec[i].iov_len))
> >         >
> >         >
> >         >
> >         >          444                        goto fail;
> >         >
> >         >
> >         >
> >         >          445
> >         >
> >         >
> >         >
> >         >          446        ret = read_reply(h, &msg.type, len);
> >         >
> >         >
> >         >
> >         >          447        if (!ret)
> >         >
> >         >
> >         >
> >         >          448                goto fail;
> >         >
> >         >
> >         >
> >         >          449
> >         >
> >         >
> >         >
> >         >          450        mutex_unlock(&h->request_mutex);
> >         >
> >         >
> >         >
> >         >
> >         >         The above seems to tell me that after writing to
> >         h->fd , the
> >         >         read_reply invoking read_message which immediatelly
> >          read from
> >         >         hd->fd?
> >         >         What did it mean by this?
> >         >
> >         >
> >         >
> >         >
> >         >         Thanks
> >         >
> >         > If hd->fd refers to a socket descriptor, it's understandable
> >         that
> >         > writing and then imediatelly reading, in which case the fd
> >         is returned
> >         > by get_handle(xs_daemon_socket(), flags).
> >         >
> >         >
> >         > But when fd is retrived by get_handle(xs_domain_dev(),
> >         flags), it
> >         > means to write to a file and then read from the same file
> >         imediatelly.
> >         > Dose it have something to do with the internal communication
> >         > protocol?!
> >
> >
> >         Yes, the xenstore protocol involves both writing messages and
> >         reading
> >         replies, but that seems trivially obvious so I'm afraid I
> >         really have no
> >         idea what your question is nor what is confusing you. Perhaps
> >         describing
> >         in more detail what you are trying to achieve will help?
> >
> >         Reading http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions
> >         might also
> >         help you consider what it is you are asking.
> >
> >
> >         >
> >         >
> >         > Thanks for replying.
> >         >
> >         >
> >         >
> >         >
> >         >
> >         >
> >         The final read and write operations are achieved by:
> > read(fd, data, len);
> > write(fd, data, len);
> >
> >
> > Maybe my confusing lies in this point that what's the distinction
> > between the read and write operations on a socket file,
> > the /proc/xen/xenbus, a regular file?
>
> /proc/xen/xenbus is not a regular file. /proc is a virtual file system
> where the files often have special and magic semantics. /proc/xen/xenbus
> is effectively something like a character device, even though it isn't
> actually implemented as one.
>
> Take a look at drivers/xen/xenbus/xenbus_dev_frontend.c which is the
> driver which backends /proc/xen/xenbus
>
> Ian.
>
>
> Ian.
>
>
>
>
I didn't find the xenbus_dev_frontend.c by `` find / -name "*xenbus*"
2>/dev/null `` command.

[-- Attachment #1.2: Type: text/html, Size: 9380 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[Ian Campbell]

On Thu, 2012-08-09 at 11:21 +0100, 马磊 wrote:

> I didn't find the xenbus_dev_frontend.c by `` find / -name "*xenbus*"
> 2>/dev/null `` command.

Look in the upstream Linux kernel source.

In some older kernels it is 
drivers/xen/xenbus/xenbus_dev.c

Ian.


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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[Ian Campbell]

On Thu, 2012-08-09 at 11:28 +0100, Ian Campbell wrote:
> On Thu, 2012-08-09 at 11:21 +0100, 马磊 wrote:
> 
> > I didn't find the xenbus_dev_frontend.c by `` find / -name "*xenbus*"
> > 2>/dev/null `` command.
> 
> Look in the upstream Linux kernel source.
> 
> In some older kernels it is 
> drivers/xen/xenbus/xenbus_dev.c

Also please try using a search engine to answer these questions. This
driver is trivially found with google.

Ian.



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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 634 bytes --]

On Thu, Aug 9, 2012 at 6:31 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-08-09 at 11:28 +0100, Ian Campbell wrote:
> > On Thu, 2012-08-09 at 11:21 +0100, 马磊 wrote:
> >
> > > I didn't find the xenbus_dev_frontend.c by `` find / -name "*xenbus*"
> > > 2>/dev/null `` command.
> >
> > Look in the upstream Linux kernel source.
> >
> > In some older kernels it is
> > drivers/xen/xenbus/xenbus_dev.c
>
> Also please try using a search engine to answer these questions. This
> driver is trivially found with google.
>
> Ian.
>
>

> By the way, which driver use the socket file as  backend ?...

[-- Attachment #1.2: Type: text/html, Size: 1447 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[Ian Campbell]

On Thu, 2012-08-09 at 11:49 +0100, 马磊 wrote:

>         By the way, which driver use the socket file as  backend ?...

You mean who uses the unix domain socket interface to xenstored?

libxenstore can optionally use this if it happens to be running in the
same domain as the daemon. Otherwise it will use the /proc/xen/xenbus
method.

Please, try (harder) to use grep, google etc to find the answers to
these things, you are asking a lot of questions which you really ought
to be able to answer by studying the code a bit.

Ian.


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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 1013 bytes --]

On Thu, Aug 9, 2012 at 7:00 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-08-09 at 11:49 +0100, 马磊 wrote:
>
> >         By the way, which driver use the socket file as  backend ?...
>
> You mean who uses the unix domain socket interface to xenstored?
>
> libxenstore can optionally use this if it happens to be running in the
> same domain as the daemon. Otherwise it will use the /proc/xen/xenbus
> method.
>
> Please, try (harder) to use grep, google etc to find the answers to
> these things, you are asking a lot of questions which you really ought
> to be able to answer by studying the code a bit.
>
> Ian.
>
>
I got xen source code from  http://www.xen.org/download/index_4.1.2.html .
when using `xl restore`，xc_evtchn_alloc_unbound will raise this error: xc:
error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1 (3 = No such
process): Internal error.
what does this mean and what does such process refer to?
Looking forward to your reply.
Thanks.

[-- Attachment #1.2: Type: text/html, Size: 1529 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[Ian Campbell]

On Wed, 2012-12-26 at 09:53 +0000, 马磊 wrote:

> 
> I got xen source code from
> http://www.xen.org/download/index_4.1.2.html .
> when using `xl restore`，xc_evtchn_alloc_unbound will raise this
> error: xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1
> (3 = No such process): Internal error.
> what does this mean and what does such process refer to?

"No such process" is what strerror(3) returns for ESRCH. In this case it
won't be a process which is not found but most likely it is the event
channel. (this misuse of terminology is a symptom of reusing the POSIX
errno numbers in the hypercall interface)

Ian.


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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 1338 bytes --]

On Wed, Jan 2, 2013 at 10:34 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Wed, 2012-12-26 at 09:53 +0000, 马磊 wrote:
>
> >
> > I got xen source code from
> > http://www.xen.org/download/index_4.1.2.html .
> > when using `xl restore`，xc_evtchn_alloc_unbound will raise this
> > error: xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1
> > (3 = No such process): Internal error.
> > what does this mean and what does such process refer to?
>
> "No such process" is what strerror(3) returns for ESRCH. In this case it
> won't be a process which is not found but most likely it is the event
> channel. (this misuse of terminology is a symptom of reusing the POSIX
> errno numbers in the hypercall interface)
>
> Ian.
>
>
Thanks for your kindness!

    I looked into the functions for logging, in this case,  `3 = No such
process` was from `errno` and the ` HYPERVISOR_event_channel_op failed:
-1 ` was from hypervisor-level error(src/xen/common/event_channel.c).
In my option, that's to say, error number of -1 was caused by hypervisor;
but what was the error number of 3 caused by,  dom0?
Do both the two error numbers refer to the description defined in errno.h
or else hypervisor has its own error description?

    I run `xl restore` in sudo mode, it had no reason for `EPERM`.

[-- Attachment #1.2: Type: text/html, Size: 3086 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 2382 bytes --]

On Fri, Jan 4, 2013 at 11:55 AM, 马磊 <aware.why@gmail.com> wrote:

>
>
> On Wed, Jan 2, 2013 at 10:34 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
>
>> On Wed, 2012-12-26 at 09:53 +0000, 马磊 wrote:
>>
>> >
>> > I got xen source code from
>> > http://www.xen.org/download/index_4.1.2.html .
>> > when using `xl restore`，xc_evtchn_alloc_unbound will raise this
>> > error: xc: error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1
>> > (3 = No such process): Internal error.
>> > what does this mean and what does such process refer to?
>>
>> "No such process" is what strerror(3) returns for ESRCH. In this case it
>> won't be a process which is not found but most likely it is the event
>> channel. (this misuse of terminology is a symptom of reusing the POSIX
>> errno numbers in the hypercall interface)
>>
>> Ian.
>>
>>
> Thanks for your kindness!
>
>     I looked into the functions for logging, in this case,  `3 = No such
> process` was from `errno` and the ` HYPERVISOR_event_channel_op failed:
> -1 ` was from hypervisor-level error(src/xen/common/event_channel.c).
> In my option, that's to say, error number of -1 was caused by hypervisor;
> but what was the error number of 3 caused by,  dom0?
> Do both the two error numbers refer to the description defined in errno.h
> or else hypervisor has its own error description?
>
>     I run `xl restore` in sudo mode, it had no reason for `EPERM`.
>

Besides, the error `ESRCH` is raised by
src/xen/common/event_channel.c:evtchn_bind_interdomain

160-static long evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind)



 161{



 162    struct evtchn *lchn, *rchn;



 163    struct domain *ld = current->domain, *rd;



 164    int            lport, rport = bind->remote_port;



 165    domid_t        rdom = bind->remote_dom;



 166    long           rc;



 167



 168    if ( rdom == DOMID_SELF )



 169        rdom = current->domain->domain_id;



 170



 171    if ( (rd = rcu_lock_domain_by_id(rdom)) == NULL )



 172        return -ESRCH;

but in actually, the error `xc_evtchn_alloc_unbound will raise this error: xc:
error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1 (3 = No such
process): Internal error.` I mentioned above is
caused by src/xen/common/event_channel.c:evtchn_alloc_unbound

[-- Attachment #1.2: Type: text/html, Size: 13375 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[Ian Campbell]

On Fri, 2013-01-04 at 03:55 +0000, 马磊 wrote:

> 
>     I looked into the functions for logging, in this case,  `3 = No
> such process` was from `errno` and the ` HYPERVISOR_event_channel_op
> failed: -1 ` was from hypervisor-level
> error(src/xen/common/event_channel.c).
> In my option, that's to say, error number of -1 was caused by
> hypervisor; but what was the error number of 3 caused by,  dom0?
> Do both the two error numbers refer to the description defined in
> errno.h or else hypervisor has its own error description?

This is just the usual Unix idiom where system calls (and by extension
the ioctl used to make hypercalls) fail by returning -1 (which has no
particular meaning other than "an error occurred") and set errno to
something more specific (3 in this case, indicating ESRCH).

Please see the errno(3) man page.

Ian.


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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[马磊]

[-- Attachment #1.1: Type: text/plain, Size: 1172 bytes --]

On Fri, Jan 4, 2013 at 5:17 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Fri, 2013-01-04 at 03:55 +0000, 马磊 wrote:
>
> >
> >     I looked into the functions for logging, in this case,  `3 = No
> > such process` was from `errno` and the ` HYPERVISOR_event_channel_op
> > failed: -1 ` was from hypervisor-level
> > error(src/xen/common/event_channel.c).
> > In my option, that's to say, error number of -1 was caused by
> > hypervisor; but what was the error number of 3 caused by,  dom0?
> > Do both the two error numbers refer to the description defined in
> > errno.h or else hypervisor has its own error description?
>
> This is just the usual Unix idiom where system calls (and by extension
> the ioctl used to make hypercalls) fail by returning -1 (which has no
> particular meaning other than "an error occurred") and set errno to
> something more specific (3 in this case, indicating ESRCH).
>
> Please see the errno(3) man page.
>
> Ian.
>
> Does the xen hypervisor set the errno to something specific when xen
encounter an error?
Where are the hypervisor error descriptors and dom0 error descriptors
 defined respectively?

[-- Attachment #1.2: Type: text/html, Size: 1596 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [help] problem with `tools/xenstore/xs.c: xs_talkv()`

[Ian Campbell]

On Fri, 2013-01-04 at 11:38 +0000, 马磊 wrote:
> 
> 
> On Fri, Jan 4, 2013 at 5:17 PM, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
>         On Fri, 2013-01-04 at 03:55 +0000, 马磊 wrote:
>         
>         >
>         >     I looked into the functions for logging, in this case,
>          `3 = No
>         > such process` was from `errno` and the `
>         HYPERVISOR_event_channel_op
>         > failed: -1 ` was from hypervisor-level
>         > error(src/xen/common/event_channel.c).
>         > In my option, that's to say, error number of -1 was caused
>         by
>         > hypervisor; but what was the error number of 3 caused by,
>          dom0?
>         > Do both the two error numbers refer to the description
>         defined in
>         > errno.h or else hypervisor has its own error description?
>         
>         
>         This is just the usual Unix idiom where system calls (and by
>         extension
>         the ioctl used to make hypercalls) fail by returning -1 (which
>         has no
>         particular meaning other than "an error occurred") and set
>         errno to
>         something more specific (3 in this case, indicating ESRCH).
>         
>         Please see the errno(3) man page.
>         
>         Ian.
>         
> Does the xen hypervisor set the errno to something specific when xen
> encounter an error?

No, errno handling is a function of the libc. Please use google to
lookup how system calls and errno etc work on a Linux system.

> Where are the hypervisor error descriptors and dom0 error descriptors
>  defined respectively?

Did you try grepping for them?

The Xen ones are in the Xen source tree. The dom0 ones are in the Linux
(or your dom0 kernel) source tree. I believe the Xen ones are a subset
of the Linux ones and that the numbers are consistent.

Ian.


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