public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: 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 07:37:22 -0800	[thread overview]
Message-ID: <1137080242.5397.37.camel@localhost.localdomain> (raw)
In-Reply-To: <5ae8261aff3d780b6594683c1d118bbd@cl.cam.ac.uk>

On Thu, 2006-01-12 at 15:26 +0000, Keir Fraser wrote:
> On 12 Jan 2006, at 15:14, Dave Hansen wrote:
> 
> >> This is a good set of questions. We have about half dozen files in
> >> /proc/xen right now. One is an obvious canididate to stick in /dev, as
> >> it has primarily an ioctl() interface.
> >
> > Actually, anything with an ioctl interface is probably a good cantidate
> > for a writable sysfs file.  The basic idea is that we prefer something
> > in sysfs with a discrete, unique name.  It also makes it a lot easier 
> > to
> > develop with because you can look at the values from scripts, and you
> > don't have to worry about synchronizing any headers.
> >
> > So, what kind of ioctls are we talking about?
> 
> They are pretty low level. e.g., pass-thru a raw hypercall direct to 
> xen, map another VM's pages into my address space (given a list of page 
> frames), etc. very strongly binary, and unlikely to be useful for 
> scripting.

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.

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.

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. :)

-- Dave


  reply	other threads:[~2006-01-12 15:37 UTC|newest]

Thread overview: 43+ 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 23:07 ` Greg KH
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  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:53             ` Mark Williamson
2006-01-12 15:42               ` Anthony Liguori
2006-01-12 15:57             ` Anthony Liguori
2006-01-12 17:34               ` 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 14:52           ` [Xen-devel] " Mike D. Day
2006-01-12 15:28             ` Dave Hansen
2006-01-12 15:50               ` Mike D. Day
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 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:30                       ` Greg KH
2006-01-12 17:38           ` Greg KH
2006-01-12  1:32     ` Dave Hansen
2006-01-12 10:04       ` [Xen-devel] " Keir Fraser
2006-01-12 15:14         ` Dave Hansen
2006-01-12 15:06           ` Mark Williamson
2006-01-12 15:26           ` Keir Fraser
2006-01-12 15:37             ` Dave Hansen [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=1137080242.5397.37.camel@localhost.localdomain \
    --to=haveblue@us.ibm.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=greg@kroah.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox