>>> On 08.04.16 at 16:22, <andrew.coop...@citrix.com> wrote: > On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote: >> +void vm_free_type(const void *, enum vmap_type); >> +void vunmap_type(const void *, enum vmap_type); >> +void *vmalloc_type(size_t size, enum vmap_type type, mfn_t **mfn_array); >> +void vm_init_type(enum vmap_type type, void *start, void *end); >> +void vfree_type(void *va, enum vmap_type type); > > Exposing the type (/region) parameter is quite unsafe, when mixed with > the va. What happens if someone passes in a va for one region, with a > VMAP_$other ?
Good point, and the type can really be inferred from the VA. Just that how this got done originally was a little unclean for my taste. > How likely are we to gain a 3rd region? My gut feeling is that it would > be safer to hide all of the type/region bits in vmap.c (other than > perhaps the _init() calls), and expose $VMAP_FOO_xen() functions in the API. Well, while I can't give a concrete example, I do think that it's not that unlikely for there to appear a 3rd region at some point. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
