On 09.09.20 13:24, Michael Ellerman wrote: > David Hildenbrand <david@xxxxxxxxxx> 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. Thoughts? > > 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. -- Thanks, David / dhildenb
