WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH v3] xen_console: support the new extended xenstor

To: Alexander Graf <agraf@xxxxxxx>
Subject: [Xen-devel] Re: [PATCH v3] xen_console: support the new extended xenstore protocol
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Thu, 30 Jun 2011 15:24:58 +0100
Cc: "peter.maydell@xxxxxxxxxx" <peter.maydell@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 30 Jun 2011 07:21:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E0C66EE.3050700@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1309345967-14397-1-git-send-email-stefano.stabellini@xxxxxxxxxxxxx> <4E0C66EE.3050700@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Thu, 30 Jun 2011, Alexander Graf wrote:
> On 06/29/2011 01:12 PM, stefano.stabellini@xxxxxxxxxxxxx wrote:
> > From: Stefano Stabellini<stefano.stabellini@xxxxxxxxxxxxx>
> >
> > Since CS 21994 on xen-unstable.hg and CS
> > 466608f3a32e1f9808acdf832a5843af37e5fcec on qemu-xen-unstable.git, few
> > changes have been introduced to the PV console xenstore protocol, as
> > described by the document docs/misc/console.txt under xen-unstable.hg.
> >
> >  From the Qemu point of view, very few modifications are needed to
> > correctly support the protocol: read from xenstore the "output" node
> > that tell us what the output of the PV console is going to be.
> > In case the output is a tty, write to xenstore the device name.
> >
> > Changes in v2:
> >
> > - fix error paths: free malloc'ed strings and close the xenstore
> > connection before returning;
> >
> > - remove useless snprintf in xenstore_store_pv_console_info if i == 0.
> >
> > Changes in v3:
> >
> > - replace xs_daemon_open/xs_daemon_close with xs_open/xs_close.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@xxxxxxxxxxxxx>
> > ---
> >   hw/xen.h         |    1 +
> >   hw/xen_console.c |   16 +++++++++-----
> >   xen-all.c        |   60 
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   3 files changed, 71 insertions(+), 6 deletions(-)
> >
> > diff --git a/hw/xen.h b/hw/xen.h
> > index d435ca0..dad0ca0 100644
> > --- a/hw/xen.h
> > +++ b/hw/xen.h
> > @@ -50,6 +50,7 @@ qemu_irq *xen_interrupt_controller_init(void);
> >   int xen_init(void);
> >   int xen_hvm_init(void);
> >   void xen_vcpu_init(void);
> > +void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
> >
> >   #if defined(NEED_CPU_H)&&  !defined(CONFIG_USER_ONLY)
> >   void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size);
> > diff --git a/hw/xen_console.c b/hw/xen_console.c
> > index 519d5f5..e81afcd 100644
> > --- a/hw/xen_console.c
> > +++ b/hw/xen_console.c
> > @@ -179,8 +179,9 @@ static void xencons_send(struct XenConsole *con)
> >   static int con_init(struct XenDevice *xendev)
> >   {
> >       struct XenConsole *con = container_of(xendev, struct XenConsole, 
> > xendev);
> > -    char *type, *dom;
> > +    char *type, *dom, label[32];
> >       int ret = 0;
> > +    const char *output;
> >
> >       /* setup */
> >       dom = xs_get_domain_path(xenstore, con->xendev.dom);
> > @@ -194,11 +195,14 @@ static int con_init(struct XenDevice *xendev)
> >           goto out;
> >       }
> >
> > -    if (!serial_hds[con->xendev.dev])
> > -   xen_be_printf(xendev, 1, "WARNING: serial line %d not configured\n",
> > -                      con->xendev.dev);
> > -    else
> > -        con->chr = serial_hds[con->xendev.dev];
> > +    output = xenstore_read_str(con->console, "output");
> > +    /* output is a pty by default */
> > +    if (output == NULL) {
> > +        output = "pty";
> 
> Not sure I understand. Why would a pty be the default? stdio makes a lot 
> more sense, no?

ptys are always been the default in the xen world. Besides qemu is
always executed by the toolstack, so stdio might be used for something
else...


> > +    }
> > +    snprintf(label, sizeof(label), "xencons%d", con->xendev.dev);
> > +    con->chr = qemu_chr_open(label, output, NULL);
> > +    xenstore_store_pv_console_info(con->xendev.dev, con->chr);
> >
> >   out:
> >       qemu_free(type);
> > diff --git a/xen-all.c b/xen-all.c
> > index 6099bff..3fd04ef 100644
> > --- a/xen-all.c
> > +++ b/xen-all.c
> > @@ -737,6 +737,66 @@ static void cpu_handle_ioreq(void *opaque)
> >       }
> >   }
> >
> > +static int store_dev_info(int domid, CharDriverState *cs, const char 
> > *string)
> > +{
> > +    struct xs_handle *xs = NULL;
> > +    char *path = NULL;
> > +    char *newpath = NULL;
> > +    char *pts = NULL;
> > +    int ret = -1;
> > +
> > +    /* Only continue if we're talking to a pty. */
> > +    if (strncmp(cs->filename, "pty:", 4)) {
> 
> What's wrong with !pty?

Nothing wrong, we don't need to write anything back to xenstore in that
case.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel