Re: [Xen-devel] [PATCH v2 1/3] xen/domain_page: Convert map_domain_page_global() to using mfn_t

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.07.15 at 12:54, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/3] xen/domain_page: Convert 
> map_domain_page_global() to using mfn_t"):
>> On 13.07.15 at 18:56, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> > Surely xfree() ought to have the same prototype as free() ?
>> 
>> Why? If it were to be a full match, why wouldn't we call it free() in
>> the first place?
> 
> Is that what is supposed to differ between free and xfree ?  That
> would be a bit odd.
> 
> In the userland world, xfree is the companion to xmalloc:
> 
>   
> http://manpages.debian.org/cgi-bin/man.cgi?query=xfree&apropos=0&sektion=0&manp
>  
> ath=Debian+8+jessie&format=html&locale=en
> 
> (Although, logically speaking, xfree is unnecessary in that set.)

And I don't view the hypervisor's xmalloc() as a counterpart to the
user mode one, but as one of Linux'es kmalloc().

>> > free is declared in C99 (7.20.3.2 in my copy of TC2) as:
>> > 
>> >     void free(void *ptr);
>> > 
>> > That is, non-const.  AFAIAA this is not generally regarded as a bug.
>> 
>> Perhaps, but certainly depending on who looks at it. I for my part
>> dislike (as hinted at above) that I have to cast away const-ness in
>> order to be able to call free() without causing compiler warnings,
>> and I generally hide this in wrappers to limit such casting.
> 
> The flipside is that if free can take a const*, functions which take a
> const struct foo* can free it.  That's not what I would expect such a
> function to do.

Depends.

> Do we need to resolve this disagreement now ?

As long as no patch is pending to adjust xfree(), I don't think so.
And of course unless you request what the patch here (already
have gone in) did to be adjusted.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel