On 05/13/2010 07:26 PM, Benjamin Herrenschmidt wrote: > On Thu, 2010-05-13 at 17:19 -0700, Yinghai Lu wrote: > >> #endif >> diff --git a/arch/x86/mm/lmb.c b/arch/x86/mm/lmb.c >> index 37a05e2..0dbe05b 100644 >> --- a/arch/x86/mm/lmb.c >> +++ b/arch/x86/mm/lmb.c >> @@ -117,3 +117,30 @@ void __init lmb_to_bootmem(u64 start, u64 end) >> lmb.reserved.cnt = 0; >> } >> #endif >> + >> +void __init lmb_add_memory(u64 start, u64 end) >> +{ >> + lmb_add_region(&lmb.memory, start, end - start); >> +} > > I completely fail the point of doing such a minor argument conversion > as an exported function, with a naming that would cause certain > confusion with the existing lmb_add(). > > In any case, the above should be done at the call sites. Just call > lmb_add(start, end-start). You also aren't consistent since you do the > similar conversion using the _area suffix below, but not above. > >> +void __init lmb_reserve_area(u64 start, u64 end, char *name) >> +{ >> + if (start == end) >> + return; >> + >> + if (WARN_ONCE(start > end, "lmb_reserve_area: wrong range [%#llx, %#llx]\n", start, end)) >> + return; >> + >> + lmb_add_region(&lmb.reserved, start, end - start); >> +} > > You seem to be fond of gratuituous bloat... > >> +void __init lmb_free_area(u64 start, u64 end) >> +{ >> + if (start == end) >> + return; >> + >> + if (WARN_ONCE(start > end, "lmb_free_area: wrong range [%#llx, %#llx]\n", start, end)) >> + return; >> + >> + lmb_free(start, end - start); >> +} > > And here again. > > If you -really- think there's value in the prototype conversions, then > make those _area() variants static inlines, group the well together in > the .h with a clear explanation saying something like "it's more > practical for some arch to use start/end rather than start/size". > > I personally don't see why you are doing that tho. make the rebase more easy. previous version is using those api. also will add some debug print out with them -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html