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 a
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 interfac
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'l
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
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/6
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
-
Take Surveys. Earn Cash. Influence the Future of IT
J
11 matches
Mail list logo
