From: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: keir.fraser@cl.cam.ac.uk, xen-devel@lists.xensource.com
Subject: Re: latest USB code including Xenidc documentation
Date: Fri, 16 Dec 2005 20:45:04 +0000 [thread overview]
Message-ID: <1134765904.5125.16.camel@localhost> (raw)
In-Reply-To: <43A31FDE.9080105@us.ibm.com>
On Fri, 2005-12-16 at 14:13 -0600, Anthony Liguori wrote:
> Harry Butterworth wrote:
>
> >I'm happy to do that for the USB driver if that's what people decide
> >they want but I'm reluctant to do it without people having first
> >considered the idea of having a higher level interdomain communication
> >API and thought about xenidc as a possible option.
> >
> >
> I think Muli's point (which I agree with) is that the question of a
> higher level interdomain communication API is orthagonal to the USB
> driver and that submitting the two at once makes it difficult to review
> because of sheer size.
To construct a good API you really need at least one example of a client
to evaluate the API against and the patches are split into two (or 17
depending) with all the xenidc stuff in one and the usb stuff in the
other.
> In fact, what I would really like to see is a before and after with the
> USB driver (one version that uses the current mechanism and uses
> xenidc). This would be a good way to evaluate how much complexity
> xenidc introduces/removes from the drivers. xenidc is a big decision
> because it means yet another rewrite of all the device drivers (we've
> gone through how many in the past year already :-)).
We could have saved most of those rewrites if we'd had some open
discussion about the requirements and the approach earlier on.
Xenidc can coexist with the current code so an immediate rewrite of the
other drivers isn't a pre-req.
Now that the driver interface in the tree is more stable I can do an
example of the USB driver with all the xendic code merged into it and
factored out as much as possible for comparison.
I'm kind of surprised that it doesn't seem to be possible to have a
discussion at a higher level of abstraction than the code itself which
seems painfully inefficient to me but then I'm new to open source so I
expect it will all make sense eventually :-)
Thanks for your help.
Harry.
>
> Regards,
>
> Anthony Liguori
>
> >
> >
> >>Cheers,
> >>Muli
> >>
> >>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
--
Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
next prev parent reply other threads:[~2005-12-16 20:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-16 16:51 latest USB code including Xenidc documentation Harry Butterworth
2005-12-16 17:01 ` Muli Ben-Yehuda
2005-12-16 17:23 ` Harry Butterworth
2005-12-16 17:38 ` Muli Ben-Yehuda
2005-12-16 19:00 ` Harry Butterworth
2005-12-16 20:13 ` Anthony Liguori
2005-12-16 20:45 ` Harry Butterworth [this message]
2005-12-17 8:16 ` Muli Ben-Yehuda
2005-12-19 10:54 ` Harry Butterworth
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=1134765904.5125.16.camel@localhost \
--to=harry@hebutterworth.freeserve.co.uk \
--cc=aliguori@us.ibm.com \
--cc=keir.fraser@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/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.