From: Arnd Bergmann <arnd@arndb.de>
To: kvm-devel@lists.sourceforge.net
Subject: Re: [kvm-devel] [RFC] Stable kvm userspace interface
Date: Thu, 11 Jan 2007 08:34:43 +0100
User-Agent: KMail/1.9.5
Cc: Jeff Garzik <jeff@garzik.org>, Avi Kivity <avi@qumranet.com>,
       Andrew Morton <akpm@osdl.org>,
       linux-kernel <linux-kernel@vger.kernel.org>
References: <45A39A97.5060807@qumranet.com> <45A39D0D.7090007@garzik.org>
In-Reply-To: <45A39D0D.7090007@garzik.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Message-Id: <200701110834.43800.arnd@arndb.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1328
Lines: 30

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.

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/