On 09.09.20 13:37, David Hildenbrand wrote: > 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. > Gave it another try, looks like mhp_t (like gfp_t) is actually nicer. -- Thanks, David / dhildenb _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
