Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: David Hildenbrand <hidden>
Date: 2020-09-09 15:07:46
Also in:
linux-acpi, linux-hyperv, linux-mm, linux-s390, linuxppc-dev, lkml, nvdimm, xen-devel
On 09.09.20 13:37, David Hildenbrand wrote:
On 09.09.20 13:24, Michael Ellerman wrote:quoted
David Hildenbrand [off-list ref] writes:quoted
On 09.09.20 09:17, Greg Kroah-Hartman wrote:quoted
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:quoted
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 _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization