qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-1.4 04/12] kvm: Create kvm_arch_vcpu_id() fu


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH for-1.4 04/12] kvm: Create kvm_arch_vcpu_id() function
Date: Fri, 18 Jan 2013 14:40:03 -0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Jan 18, 2013 at 09:11:42AM -0700, Eric Blake wrote:
> On 01/18/2013 07:20 AM, Eduardo Habkost wrote:
> >> Could you suggest a text for me to add please?
> > 
> > "The argument passed to KVM_CREATE_VCPU now has 'unsigned long' type
> > instead of 'int', as expected by the Linux ioctl() syscall. Maybe an int
> > works on most or all architectures supporting KVM, but it is safer to
> > use an appropriate 'unsigned long' parameter."
> 
> Interestingly enough, while the Linux syscall uses 'unsigned long', the
> POSIX definition of ioctl() uses 'int'; so the Linux kernel is already
> constrained to never use an ioctl value that doesn't fit within 'int',

Really? What about the ioctl()s that get a pointer as argument on
architectures where pointers don't fit in an int?

Do you have a pointer to the POSIX definition you are talking about?

Note that I'm talking about the the extra ioctl() argument, not the
ioctl() number (that is an unsigned int in the kernel code).


> and glibc is already responsible for ensuring that argument promotion of
> an int doesn't change the behavior of ioctl() in libc when converting it
> over to the unsigned long syscall semantics expected by the kernel.
> 
> > 
> > To find out if 'int' breaks on any architecture, I would need to check
> > the ABI specification for each architecture. I didn't do that, but I am
> > sure we should pass an unsigned long instead, if that's the type
> > expected by the kernel.
> > 
> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]