Re: [PATCH v1 1/2] mm/memblock: expose only miminal interface to add/walk physmem

[David Hildenbrand]

> Am 30.06.2020 um 18:58 schrieb David Hildenbrand <david@xxxxxxxxxx>:
> 
> ï
>> 
>>> extern struct memblock memblock;
>>> @@ -114,6 +110,19 @@ int memblock_remove(phys_addr_t base, phys_addr_t size);
>>> int memblock_free(phys_addr_t base, phys_addr_t size);
>>> int memblock_reserve(phys_addr_t base, phys_addr_t size);
>>> #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
>>> +/**
>>> + * for_each_physmem_range - iterate through physmem areas not included in type.
>>> + * @i: u64 used as loop variable
>>> + * @type: ptr to memblock_type which excludes from the iteration, can be %NULL
>>> + * @p_start: ptr to phys_addr_t for start address of the range, can be %NULL
>>> + * @p_end: ptr to phys_addr_t for end address of the range, can be %NULL
>>> + */
>>> +#define for_each_physmem_range(i, type, p_start, p_end)            \
>>> +    for (i = 0, __next_physmem_range(&i, type, p_start, p_end);    \
>>> +         i != (u64)ULLONG_MAX;                    \
>>> +         __next_physmem_range(&i, type, p_start, p_end))
>>> +void __next_physmem_range(u64 *idx, struct memblock_type *type,
>>> +              phys_addr_t *out_start, phys_addr_t *out_end);
>> 
>> __next_physmem_range() is not really necessary, the
>> for_each_physmem_range() macro can use __next_mem_range() directly, but
>> I suspect it won't look nice :)
>> 
>> Can you please make __next_physmem_range() static inline if we are to
>> keep it?
> 
> The thing is, then I have to expose "physmem" to something outside
> memblock.c. That's what I wanted to avoid here. (instead, have a minimal
> interface that is sufficient enough for this special case of physmem -
> add memory during boot, walk memory after boot. Performance is not an
> issue).

... but it might do with an extern declaration within the inline function. Will have a look tomorrow, thanks!