On Fri, Apr 08, 2016 at 11:19:24AM -0600, Jan Beulich wrote: > >>> 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.
OK, then let just expose the vmalloc_xen, and vfree_xen along with vmap_init_type. The rest will be part of the vmalloc.c file. Albeit I will leave __vmap with the type.. > > > 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
