From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [PATCH] libxl: do not assume Dom0 backend while getting nic info
Date: Mon, 5 Sep 2016 11:44:46 +0200 [thread overview]
Message-ID: <20160905094446.GK21245@mail-itl> (raw)
In-Reply-To: <20160905093915.GC18255@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 1795 bytes --]
On Mon, Sep 05, 2016 at 10:39:16AM +0100, Wei Liu wrote:
> On Mon, Sep 05, 2016 at 11:26:04AM +0200, Marek Marczykowski-Górecki wrote:
> > Fill backend_domid field based on backend path.
> >
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
>
> Acked-by: Wei Liu <wei.liu2@citrix.com>
>
> I think this is a backport candidate?
Yes, certainly. If you want I can send a 4.7 version (function is in
libxl.c there).
In general, should I somehow somehow request a backport in the patch
itself? How?
> > ---
> > tools/libxl/libxl_nic.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
> > index c34b7ba..d1caa90 100644
> > --- a/tools/libxl/libxl_nic.c
> > +++ b/tools/libxl/libxl_nic.c
> > @@ -309,6 +309,18 @@ static int libxl__device_nic_from_xenstore(libxl__gc *gc,
> > else
> > nic->devid = 0;
> >
> > + rc = libxl__xs_read_checked(gc, XBT_NULL,
> > + GCSPRINTF("%s/backend", libxl_path), &tmp);
> > + if (rc) goto out;
> > +
> > + if (!tmp) {
> > + LOG(ERROR, "nic %s does not exist (no backend path)", libxl_path);
> > + rc = ERROR_FAIL;
> > + goto out;
> > + }
> > + rc = libxl__backendpath_parse_domid(gc, tmp, &nic->backend_domid);
> > + if (rc) goto out;
> > +
> > /* nic->mtu = */
> >
> > rc = libxl__xs_read_checked(gc, XBT_NULL,
> > --
> > 2.5.5
> >
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-09-05 9:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-05 9:26 [PATCH] libxl: do not assume Dom0 backend while getting nic info Marek Marczykowski-Górecki
2016-09-05 9:39 ` Wei Liu
2016-09-05 9:44 ` Marek Marczykowski-Górecki [this message]
2016-09-05 9:53 ` Wei Liu
2016-09-05 10:39 ` Ian Jackson
2016-09-05 10:53 ` Wei Liu
-- strict thread matches above, loose matches on Subject: below --
2016-09-05 9:24 Marek Marczykowski-Górecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160905094446.GK21245@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=ian.jackson@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).