On Thu, Jun 12, 2014 at 10:11:19AM +0530, Aneesh Kumar K.V wrote: > Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> writes: > > > We don't need explicit 'CMA:' prefix, since we already define prefix > > 'cma:' in pr_fmt. So remove it. > > > > And, some logs print function name and others doesn't. This looks > > bad to me, so I unify log format to print function name consistently. > > > > Lastly, I add one more debug log on cma_activate_area(). > > > > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> > > > > diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c > > index 83969f8..bd0bb81 100644 > > --- a/drivers/base/dma-contiguous.c > > +++ b/drivers/base/dma-contiguous.c > > @@ -144,7 +144,7 @@ void __init dma_contiguous_reserve(phys_addr_t limit) > > } > > > > if (selected_size && !dma_contiguous_default_area) { > > - pr_debug("%s: reserving %ld MiB for global area\n", __func__, > > + pr_debug("%s(): reserving %ld MiB for global area\n", __func__, > > (unsigned long)selected_size / SZ_1M); > > Do we need to do function(), or just function:. I have seen the later > usage in other parts of the kernel. Hello, I also haven't seen this format in other kernel code, but, in cma, they use this format as following. function(arg1, arg2, ...): some message If we all dislike this format, we can change it after merging this patchset. Until then, it seems better to me to leave it as is. > > > > > dma_contiguous_reserve_area(selected_size, selected_base, > > @@ -163,8 +163,9 @@ static int __init cma_activate_area(struct cma *cma) > > unsigned i = cma->count >> pageblock_order; > > struct zone *zone; > > > > - cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL); > > + pr_debug("%s()\n", __func__); > > why ? > This pr_debug() comes from ppc kvm's kvm_cma_init_reserved_areas(). I want to maintain all log messages as much as possible to reduce confusion with this generalization. Thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html