On 09.09.20 13:37, David Hildenbrand wrote:
On 09.09.20 13:24, Michael Ellerman wrote:
> David Hildenbrand <david(a)redhat.com> writes:
>> On 09.09.20 09:17, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
>>>> We soon want to pass flags, e.g., to mark added System RAM resources.
>>>> mergeable. Prepare for that.
>>> What are these random "flags", and how do we know what should be
>>> to them?
>>> Why not make this an enumerated type so that we know it all works
>>> properly, like the GPF_* flags are? Passing around a random unsigned
>>> long feels very odd/broken...
>> Agreed, an enum (mhp_flags) seems to give a better hint what can
>> actually be passed. Thanks!
> You probably know this but ...
> Just using a C enum doesn't get you any type safety.
> You can get some checking via sparse by using __bitwise, which is what
> gfp_t does. You don't actually have to use an enum for that, it works
> with #defines also.
Yeah, we seem to be using different approaches. And there is always a
way to mess things up :)
gfp_t is one (extreme) example, enum memblock_flags is another example.
I tend to prefer an enum in this particular case, because it's simple
and at least tells the user which values are expected.
Gave it another try, looks like mhp_t (like gfp_t) is actually nicer.
David / dhildenb