All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: xen-devel@lists.xen.org, sstanisi@cbnco.com,
	Fabio Fantoni <fabio.fantoni@m2r.biz>,
	Anthony Perard <anthony.perard@citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	"Simon (Bo) Cao" <caobosimon@gmail.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v7 RFC 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest
Date: Wed, 18 Jun 2014 15:30:39 +0100	[thread overview]
Message-ID: <1403101839.6568.53.camel@kazak.uk.xensource.com> (raw)
In-Reply-To: <53A19AF4.1040502@eu.citrix.com>

On Wed, 2014-06-18 at 14:58 +0100, George Dunlap wrote:
> On 06/18/2014 02:49 PM, Ian Campbell wrote:
> >>>> +        ("backend_domid",    libxl_domid),
> >>>> +        ("backend_domname",  string),
> >>>> +        ("u", KeyedUnion(None, libxl_device_usb_type, "type",
> >>>> +                         [("hostdev", Struct(None, [
> >>>> +                                ("hostbus",   integer),
> >>>> +                                ("hostaddr",  integer) ]))
> >>> No need to express the host topology I think (because you can build that
> >>> from the bus,addr tuples)?
> >> I don't really follow.  You mean, we can drop 'host' from the last two
> >> elements, and just call them "bus" and "addr"?
> > Gah, I started writing one thing and then reunderstood usb and wrote
> > half another.
> >
> > What I was trying to say is that you don't need hostaddr to describe the
> > full USB topology path to the device because the (bus,addr) tuple you've
> > given already does so (because each hub effectively creates a new bus
> > number, so they all look like toplevel buses in this representation).
> 
> You seem to be saying that something is redundant, or that there's extra 
> information somewhere; but as there are only two bits of data (bus and 
> addr), and agree that I need both, I'm having a hard time telling what 
> you think is redundant / could be removed..

I'm actually saying the opposite (or rather asking for confirmation that
this is the case). i.e. one might expect that *more* information would
be needed here (i.e. the full bus topology/path to a device via multiple
hubs etc) but in fact this is not needed because the topology is not
visible in this numbering scheme (each potential fork in the path
results in a whole new bus number).

Sorry, I could have been clearer about this.

> "hostdev" is an element of the union; so the structure should unpack 
> like this:
> struct {
>    libxl_domid backend_domid;
>    char * backend_domname;
>    libxl_usb_device_type type;
>    union u {
>     struct {
>      int hostbus, hostaddr;
>     } hostdev;
>    };
> };
> 
> At the moment, "type" can only be "hostdev"; but I'm envisioning in the 
> future that "type" might be "tablet", "mouse", "keyboard", maybe 
> "mass-storage", and that the union would have more elements.

This seems sensible. You brought up dropping the hostdev prefix from the
bus and addr (because you thought I was ;-)), which seemed sensible when
you think of the code which accesses these fields i.e.
dev->u.hostdev.hostbus vs dev->u.hostdev.bus. Up to you whether you want
to repeat "host" in that.

> Does that clear things up?  Or am I totally confused? :-)

I think you are remarkably unconfused given how confusing I'm being...

Ian.

  reply	other threads:[~2014-06-18 14:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1401716658-22393-1-git-send-email-george.dunlap@eu.citrix.com>
2014-06-02 13:44 ` [PATCH v7 RFC 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest George Dunlap
2014-06-18 13:08   ` Ian Campbell
2014-06-18 13:22     ` George Dunlap
2014-06-18 13:49       ` Ian Campbell
2014-06-18 13:58         ` George Dunlap
2014-06-18 14:30           ` Ian Campbell [this message]
2014-06-18 14:47             ` George Dunlap
2014-06-02 13:44 ` [PATCH v7 RFC 2/2] xl: Add commands for usb hot-plug George Dunlap
2014-06-05 10:14 ` [PATCH v7 RFC 0/2] libxl USB prototype and design discussion Daniel P. Berrange
     [not found] ` <20140605101438.GD19077@redhat.com>
2014-06-05 15:04   ` George Dunlap
2014-06-18 12:57 ` Ian Campbell
     [not found] ` <1403096222.32540.14.camel@kazak.uk.xensource.com>
2014-06-18 13:15   ` George Dunlap
2014-06-18 14:04   ` George Dunlap
     [not found]   ` <53A19C67.3070809@eu.citrix.com>
2014-06-30 14:41     ` Simon Cao

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=1403101839.6568.53.camel@kazak.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=caobosimon@gmail.com \
    --cc=fabio.fantoni@m2r.biz \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=sstanisi@cbnco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.