Messages in this thread | | | Subject | Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends | From | David Hildenbrand <> | Date | Wed, 9 Sep 2020 13:51:41 +0200 |
| |
On 09.09.20 13:37, David Hildenbrand wrote: > On 09.09.20 13:24, Michael Ellerman wrote: >> David Hildenbrand <david@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 passed >>>> 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.
-- Thanks,
David / dhildenb
| |