On 01/21/2013 06:14 AM, Andreas Färber wrote: >> glibc is already responsible from converting the 'unsigned long >> int' of the user declaration back into the 'unsigned int' that the >> kernel expects for the second argument. The third argument (when >> present), is generally treated as a pointer (of size appropriate >> for the architecture). Although there _might_ be an ioctl that >> uses it directly as an integer instead of dereferencing it as a >> pointer, those would be the exceptions to the rule. > > So ... do we have a conclusion what to put into the commit message? :) > > It looks to me as if kvm-all.c:kvm_vm_ioctl() is using void*. I like > unsigned long but maybe uintptr_t would be more correct then?
uintptr_t feels more correct - the 3rd (vararg) argument through the ioctl() syscall is always retrieved using the same size as void*. > > Or should kvm_vm_ioctl() be fixed to use something else instead? > Eric's int would be a semantic change for the 64-bit platforms, no? My discussion about 'int' vs. 'unsigned long' was in regards to the second argument KVM_CREATE_VCPU, which your patch does not change (perhaps my fault for jumping in on a conversation mid-thread without actually reading your original patch, which I have now done). That is, KVM_CREATE_VCPU as a constant is always 32 bits (kernel constraint), widened out to unsigned long when passed to the glibc function (due to the glibc signature disagreeing with POSIX), then narrowed back down to 32 bits when forwarded to the kernel syscall. Meanwhile, your patch is fixing the third argument from 'int' to a wider type, which is necessary for passing that value through varargs when the receiving end will retrieve the same argument via a void* variable. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
