WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH, RFC 1/4] linux: add new (replacement) mmap-batch

To: "Ian Campbell" <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH, RFC 1/4] linux: add new (replacement) mmap-batch ioctl
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 11 Jan 2010 15:42:04 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 11 Jan 2010 07:42:31 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1263222777.16526.1512.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4B4B48A0020000780002912C@xxxxxxxxxxxxxxxxxx> <1263222777.16526.1512.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Ian Campbell <Ian.Campbell@xxxxxxxxxx> 11.01.10 16:12 >>>
>On Mon, 2010-01-11 at 14:49 +0000, Jan Beulich wrote:
>>  #define IOCTL_PRIVCMD_MMAPBATCH                                        \
>>         _IOC(_IOC_NONE, 'P', 3, sizeof(privcmd_mmapbatch_t))
>> +#define IOCTL_PRIVCMD_MMAP_BATCH                               \
>> +       _IOC(_IOC_NONE, 'P', 4, sizeof(privcmd_mmap_batch_t)) 
>
>Distinguishing the old vs new ioctl by only a _ in the middle seems a
>bit horrid. MMAPBATCH2 would at least be less prone to confusion...

Otoh it clearly tells that the two are very similar...

>Why not take the opportunity to make the ioctl (and hypercall?)
>interface 32 vs 64 agnostic by unconditionally using 64 bit sizes?

That's not common practice for structures containing pointers
afaict, and wouldn't be nice for the pointer type of 'arr' (would
double the array size on 32-bits for no reason, and would require
extra checking anyway).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel