From: Anthony Liguori <aliguori@us.ibm.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>,
lkml <linux-kernel@vger.kernel.org>,
xen-devel@lists.xensource.com, "Mike D. Day" <ncmike@us.ibm.com>,
Greg KH <greg@kroah.com>
Subject: Re: [Xen-devel] Re: [RFC] [PATCH] sysfs support for Xen attributes
Date: Thu, 12 Jan 2006 09:49:02 -0600 [thread overview]
Message-ID: <43C67A6E.3060708@us.ibm.com> (raw)
In-Reply-To: <1137080242.5397.37.camel@localhost.localdomain>
Dave Hansen wrote:
>The ppc64 hypervisor does something like this today in a couple of
>places. It is kinda a mess. I think that putting a generic, binary
>firmware interface leads to having a bit of a crutch. It basically lets
>the userspace software stack bypass Linux and talk directly to the
>hypervisor. It also means that you have to have a very specialized
>software stack for each hypervisor or virtualization type, which is very
>bad.
>
>This pushes things out to userspace, which is generally good. But, it
>is pushing behavior and "hardware" knowledge out there, too. The
>hardware knowledge, especially, is something that we usually try to
>encapsulate.
>
>
The Xen virtual hardware is exposed in the normal way (there is a Xen
bus so Xen devices show up under that).
>Also things like inter-partition page sharing, and partition migration
>are used in other hypervisors. I think it is essential to get common
>interfaces to those things.
>
>
In very, very different ways though.
>One last thing... When you say "very strongly binary" do you mean, "are
>implemented now as very strongly binary", or "absolutely 100% have to be
>horribly strongly binary"? They are two quite different things. :)
>
>
To expose the hypercalls to userspace via sysfs (or another high level
interface) would require a whole bunch of complex code to encode the
hypercalls and decode there results. I'm not sure having a common
interface is a compelling argument to justify this kernel-level
complexity since one can just standardize on a userspace library
(something like http://www.libvir.org).
I do agree we need a common interface though...
Regards,
Anthony Liguori
>-- Dave
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <aliguori@us.ibm.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: "Mike D. Day" <ncmike@us.ibm.com>,
xen-devel@lists.xensource.com,
lkml <linux-kernel@vger.kernel.org>, Greg KH <greg@kroah.com>
Subject: Re: Re: [RFC] [PATCH] sysfs support for Xen attributes
Date: Thu, 12 Jan 2006 09:49:02 -0600 [thread overview]
Message-ID: <43C67A6E.3060708@us.ibm.com> (raw)
In-Reply-To: <1137080242.5397.37.camel@localhost.localdomain>
Dave Hansen wrote:
>The ppc64 hypervisor does something like this today in a couple of
>places. It is kinda a mess. I think that putting a generic, binary
>firmware interface leads to having a bit of a crutch. It basically lets
>the userspace software stack bypass Linux and talk directly to the
>hypervisor. It also means that you have to have a very specialized
>software stack for each hypervisor or virtualization type, which is very
>bad.
>
>This pushes things out to userspace, which is generally good. But, it
>is pushing behavior and "hardware" knowledge out there, too. The
>hardware knowledge, especially, is something that we usually try to
>encapsulate.
>
>
The Xen virtual hardware is exposed in the normal way (there is a Xen
bus so Xen devices show up under that).
>Also things like inter-partition page sharing, and partition migration
>are used in other hypervisors. I think it is essential to get common
>interfaces to those things.
>
>
In very, very different ways though.
>One last thing... When you say "very strongly binary" do you mean, "are
>implemented now as very strongly binary", or "absolutely 100% have to be
>horribly strongly binary"? They are two quite different things. :)
>
>
To expose the hypercalls to userspace via sysfs (or another high level
interface) would require a whole bunch of complex code to encode the
hypercalls and decode there results. I'm not sure having a common
interface is a compelling argument to justify this kernel-level
complexity since one can just standardize on a userspace library
(something like http://www.libvir.org).
I do agree we need a common interface though...
Regards,
Anthony Liguori
>-- Dave
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
next prev parent reply other threads:[~2006-01-12 15:49 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-11 17:17 [RFC] [PATCH] sysfs support for Xen attributes Mike D. Day
2006-01-11 17:19 ` Arjan van de Ven
2006-01-11 17:56 ` Stephen Hemminger
2006-01-11 18:45 ` Dave Hansen
2006-01-11 18:45 ` Dave Hansen
2006-01-11 23:07 ` Greg KH
2006-01-12 0:23 ` Mike D. Day
2006-01-12 0:23 ` Mike D. Day
2006-01-12 0:57 ` Greg KH
2006-01-12 1:49 ` Mike D. Day
2006-01-12 1:49 ` Mike D. Day
2006-01-12 2:17 ` [Xen-devel] " Mark Williamson
2006-01-12 7:10 ` Greg KH
2006-01-12 14:44 ` [Xen-devel] " Mike D. Day
2006-01-12 14:44 ` Mike D. Day
2006-01-12 14:53 ` [Xen-devel] " Mark Williamson
2006-01-12 15:42 ` Anthony Liguori
2006-01-12 15:57 ` Anthony Liguori
2006-01-12 15:57 ` Anthony Liguori
2006-01-12 17:34 ` [Xen-devel] " Greg KH
2006-01-12 18:44 ` Anthony Liguori
2006-01-12 17:43 ` Greg KH
2006-01-12 9:10 ` Dave Hansen
2006-01-12 9:10 ` Dave Hansen
2006-01-12 14:52 ` [Xen-devel] " Mike D. Day
2006-01-12 15:28 ` Dave Hansen
2006-01-12 15:28 ` Dave Hansen
2006-01-12 15:50 ` [Xen-devel] " Mike D. Day
2006-01-12 15:50 ` Mike D. Day
2006-01-12 12:54 ` Gerd Hoffmann
2006-01-12 12:54 ` Gerd Hoffmann
2006-01-12 13:21 ` Arjan van de Ven
2006-01-12 14:42 ` Gerd Hoffmann
2006-01-12 17:39 ` Greg KH
2006-01-12 18:53 ` Anthony Liguori
2006-01-12 18:55 ` Arjan van de Ven
2006-01-12 18:59 ` Anthony Liguori
2006-01-12 18:59 ` Anthony Liguori
2006-01-12 19:11 ` Mike D. Day
2006-01-12 19:11 ` Mike D. Day
2006-01-12 19:31 ` Greg KH
2006-01-12 19:08 ` Greg KH
2006-01-12 19:18 ` Mike D. Day
2006-01-12 19:18 ` Mike D. Day
2006-01-12 19:30 ` Greg KH
2006-01-12 17:38 ` Greg KH
2006-01-12 1:32 ` Dave Hansen
2006-01-12 1:32 ` Dave Hansen
2006-01-12 10:04 ` [Xen-devel] " Keir Fraser
2006-01-12 10:04 ` Keir Fraser
2006-01-12 15:14 ` [Xen-devel] " Dave Hansen
2006-01-12 15:14 ` Dave Hansen
2006-01-12 15:06 ` [Xen-devel] " Mark Williamson
2006-01-12 15:06 ` Mark Williamson
2006-01-12 15:26 ` [Xen-devel] " Keir Fraser
2006-01-12 15:37 ` Dave Hansen
2006-01-12 15:37 ` Dave Hansen
2006-01-12 15:49 ` Anthony Liguori [this message]
2006-01-12 15:49 ` Anthony Liguori
2006-01-11 23:31 ` Pavel Machek
2006-01-12 19:01 ` Greg KH
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=43C67A6E.3060708@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=greg@kroah.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ncmike@us.ibm.com \
--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.