Hi!
> >>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
>
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
Jeff Garzik wrote:
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
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
des
Arnd Bergmann wrote:
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.
The inode-per-vm and inode-per-vcpu approach sort-of-implies a
nonmountable special filesystem, so with the proposed change, we'll b
Arnd Bergmann wrote:
On Tuesday 09 January 2007 14:37, Avi Kivity wrote:
struct kvm_vcpu_area {
u32 vcpu_area_size;
u32 exit_reason;
sigset_t sigmask; // for use during vcpu execution
Since Jeff brought up the point of 32 bit compatibility:
When this structure is shared b
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
On Tuesday 09 January 2007 14:37, Avi Kivity wrote:
> struct kvm_vcpu_area {
> u32 vcpu_area_size;
> u32 exit_reason;
>
> sigset_t sigmask; // for use during vcpu execution
Since Jeff brought up the point of 32 bit compatibility:
When this structure is shared between 64 bit kernel an
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.
I don't see how the procfs or sysfs models fit kvm. wrt compat code,
the current kvm abi (also ioctl based) is 32/64 bi
On Tue, 9 Jan 2007, 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.
I guess ioctl is not as important now if the API is now always talking to
one VM.
- James
--
J
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.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
I had originally hoped to get this in for 2.6.20. It now looks like .20
will have a shorter cycle than usual, and the mmu took a bit longer than
expected, so it's more realistic to aim for 2.6.21.
The current kvm userspace interface has several deficiencies:
- open("/dev/kvm") returns a diffe
12 matches
Mail list logo
