Thread (7 messages) 7 messages, 4 authors, 2020-09-09

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

flat view

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2020-09-09 11:31:39
Also in: linux-acpi, linux-mm, linux-s390, linuxppc-dev, lkml, nvdimm, virtualization, xen-devel

David Hildenbrand [off-list ref] writes:
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.

Or you can wrap the flag in a struct, the way atomic_t does, and then
the compiler will prevent passing plain integers in place of your custom
type.

cheers
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help