LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Lang <david.lang@digitalinsight.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: kvm-devel@lists.sourceforge.net, Jeff Garzik <jeff@garzik.org>,
	Avi Kivity <avi@qumranet.com>, Andrew Morton <akpm@osdl.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [kvm-devel] [RFC] Stable kvm userspace interface
Date: Thu, 11 Jan 2007 09:40:57 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.63.0701110935570.11166@qynat.qvtvafvgr.pbz> (raw)
In-Reply-To: <200701110834.43800.arnd@arndb.de>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1742 bytes --]

On Thu, 11 Jan 2007, Arnd Bergmann wrote:

> On Tuesday 09 January 2007 14:47, Jeff Garzik wrote:
>> Can we please avoid adding a ton of new ioctls?  ioctls inevitably
>> require 64-bit compat code for certain architectures, whereas
>> sysfs/procfs does not.
>
> For performance reasons, an ascii string based interface is not
> desireable here, some of these calls should be optimized to
> the point of counting cycles.

why is this? most of the API that is being discussed is run once when the VM is 
being setup.

there may be some calls that are performance sensitive, but for things like 
seperating the page tables, the cost of doing the work will swamp any ASCII 
conversion costs.

David Lang

> Sysfs also does not fit the use case at all, and procfs only
> makes sense if you really want to keep all information about the
> guest as part of the process directory it belongs to.
>
> I still think that in the long term, we should migrate to
> new system calls and a special file system for kvm, which
> might be non-mountable. Those will of course have the same
> 32 bit compat problems as the ioctl approach, but so far,
> Avi has kept a good watch on avoiding these problems.
>
> As long as we think the interface is likely to change (which it
> certainly is right now), I believe that ioctl is the right
> interface. We can think about retiring it when the interface has
> stabilized enough to be converted to syscalls.
>
> 	Arnd <><
> -
> 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/
>

  parent reply	other threads:[~2007-01-11 17:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-09 13:37 Avi Kivity
2007-01-09 13:47 ` Jeff Garzik
2007-01-09 14:02   ` [kvm-devel] " James Morris
2007-01-09 14:11   ` Avi Kivity
2007-01-11  7:34   ` [kvm-devel] " Arnd Bergmann
2007-01-11  8:03     ` Avi Kivity
2007-01-11  8:26     ` Jeff Garzik
2007-01-11  8:32       ` Avi Kivity
2007-01-12 11:19       ` Pavel Machek
2007-01-11 17:40     ` David Lang [this message]
2007-01-11  7:26 ` Arnd Bergmann
2007-01-11  8:02   ` Avi Kivity

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=Pine.LNX.4.63.0701110935570.11166@qynat.qvtvafvgr.pbz \
    --to=david.lang@digitalinsight.com \
    --cc=akpm@osdl.org \
    --cc=arnd@arndb.de \
    --cc=avi@qumranet.com \
    --cc=jeff@garzik.org \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [kvm-devel] [RFC] Stable kvm userspace interface' \
    /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

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