From: Michael Ellerman <mpe@ellerman.id.au>
To: David Hildenbrand <david@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
linux-hyperv@vger.kernel.org, xen-devel@lists.xenproject.org,
linux-acpi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-s390@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Wei Liu <wei.liu@kernel.org>, Michal Hocko <mhocko@suse.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Baoquan He <bhe@redhat.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Juergen Gross <jgross@suse. com>,
Stefano Stabellini <sstabellini@kernel.org>,
Pingfan Liu <kernelfans@gmail.com>,
Nathan Lynch <nathanl@linux.ibm.com>,
Libor Pechacek <lpechacek@suse.cz>,
Anton Blanchard <anton@ozlabs.org>,
Leonardo Bras <leobras.c@gmail.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
Date: Wed, 09 Sep 2020 21:24:02 +1000 [thread overview]
Message-ID: <87eenbry5p.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <3bc5b464-3229-d442-714a-ec33b5728ac6@redhat.com>
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.
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
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: David Hildenbrand <david@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
linux-hyperv@vger.kernel.org, xen-devel@lists.xenproject.org,
linux-acpi@vger.kernel.org, linux-nvdimm@lists.01.org,
linux-s390@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Wei Liu <wei.liu@kernel.org>, Michal Hocko <mhocko@suse.com>,
Dan Williams <dan.j.williams@intel.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Baoquan He <bhe@redhat.com>,
Wei Yang <richardw.yang@linux.intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Oliver O'Halloran <oohall@gmail.com>,
Pingfan Liu <kernelfans@gmail.com>,
Nathan Lynch <nathanl@linux.ibm.com>,
Libor Pechacek <lpechacek@suse.cz>,
Anton Blanchard <anton@ozlabs.org>,
Leonardo Bras <leobras.c@gmail.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
Date: Wed, 09 Sep 2020 21:24:02 +1000 [thread overview]
Message-ID: <87eenbry5p.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <3bc5b464-3229-d442-714a-ec33b5728ac6@redhat.com>
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.
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
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: David Hildenbrand <david@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-hyperv@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Pingfan Liu <kernelfans@gmail.com>,
virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
Paul Mackerras <paulus@samba.org>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
linux-s390@vger.kernel.org, Wei Liu <wei.liu@kernel.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Dave Jiang <dave.jiang@intel.com>, Baoquan He <bhe@redhat.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Vishal Verma <vishal.l.verma@intel.com>,
linux-acpi@vger.kernel.org, xen-devel@lists.xenproject.org,
Heiko Carstens <hca@linux.ibm.com>, Len Brown <lenb@kernel.org>,
Nathan Lynch <nathanl@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Leonardo Bras <leobras.c@gmail.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Dan Williams <dan.j.williams@intel.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Juergen Gross <jgross@suse.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Libor Pechacek <lpechacek@suse.cz>,
linux-nvdimm@lists.01.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org,
Wei Yang <richardw.yang@linux.intel.com>,
Oliver O'Halloran <oohall@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
Date: Wed, 09 Sep 2020 21:24:02 +1000 [thread overview]
Message-ID: <87eenbry5p.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <3bc5b464-3229-d442-714a-ec33b5728ac6@redhat.com>
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.
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
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: David Hildenbrand <david@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-hyperv@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Pingfan Liu <kernelfans@gmail.com>,
virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
Paul Mackerras <paulus@samba.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
linux-s390@vger.kernel.org, Wei Liu <wei.liu@kernel.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Dave Jiang <dave.jiang@intel.com>, Baoquan He <bhe@redhat.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Vishal Verma <vishal.l.verma@intel.com>,
linux-acpi@vger.kernel.org, xen-devel@lists.xenproject.org,
Anton Blanchard <anton@ozlabs.org>,
Heiko Carstens <hca@linux.ibm.com>, Len Brown <lenb@kernel.org>,
Nathan Lynch <nathanl@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Leonardo Bras <leobras.c@gmail.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Dan Williams <dan.j.williams@intel.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Juergen Gross <jgross@suse.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Libor Pechacek <lpechacek@suse.cz>,
linux-nvdimm@lists.01.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org,
Wei Yang <richardw.yang@linux.intel.com>,
Oliver O'Halloran <oohall@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
Date: Wed, 09 Sep 2020 21:24:02 +1000 [thread overview]
Message-ID: <87eenbry5p.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <3bc5b464-3229-d442-714a-ec33b5728ac6@redhat.com>
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.
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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2020-09-09 11:24 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 20:10 [PATCH v2 0/7] mm/memory_hotplug: selective merging of system ram resources David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-15 2:07 ` Wei Yang
2020-09-15 2:07 ` Wei Yang
2020-09-15 2:10 ` Wei Yang
2020-09-15 2:10 ` Wei Yang
2020-09-15 7:35 ` David Hildenbrand
2020-09-15 7:35 ` David Hildenbrand
2020-09-15 7:35 ` David Hildenbrand
2020-09-15 9:06 ` Wei Yang
2020-09-15 9:06 ` Wei Yang
2020-09-15 9:15 ` David Hildenbrand
2020-09-15 9:15 ` David Hildenbrand
2020-09-15 9:15 ` David Hildenbrand
2020-09-15 9:33 ` Wei Yang
2020-09-15 9:33 ` Wei Yang
2020-09-08 20:10 ` [PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-09 7:16 ` Greg Kroah-Hartman
2020-09-09 7:16 ` Greg Kroah-Hartman
2020-09-09 7:16 ` Greg Kroah-Hartman
2020-09-09 7:16 ` Greg Kroah-Hartman
2020-09-09 7:27 ` David Hildenbrand
2020-09-09 7:27 ` David Hildenbrand
2020-09-09 7:27 ` David Hildenbrand
2020-09-09 7:27 ` David Hildenbrand
2020-09-15 2:20 ` Wei Yang
2020-09-15 2:20 ` Wei Yang
2020-09-15 2:20 ` Wei Yang
2020-09-15 7:37 ` David Hildenbrand
2020-09-15 7:37 ` David Hildenbrand
2020-09-15 7:37 ` David Hildenbrand
2020-09-15 7:37 ` David Hildenbrand
2020-09-08 20:10 ` [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-09 5:18 ` Jürgen Groß
2020-09-09 5:18 ` Jürgen Groß
2020-09-09 5:18 ` Jürgen Groß
2020-09-09 5:18 ` Jürgen Groß
2020-09-09 7:17 ` Greg Kroah-Hartman
2020-09-09 7:17 ` Greg Kroah-Hartman
2020-09-09 7:17 ` Greg Kroah-Hartman
2020-09-09 7:17 ` Greg Kroah-Hartman
2020-09-09 7:28 ` David Hildenbrand
2020-09-09 7:28 ` David Hildenbrand
2020-09-09 7:28 ` David Hildenbrand
2020-09-09 7:28 ` David Hildenbrand
2020-09-09 11:24 ` Michael Ellerman [this message]
2020-09-09 11:24 ` Michael Ellerman
2020-09-09 11:24 ` Michael Ellerman
2020-09-09 11:24 ` Michael Ellerman
2020-09-09 11:37 ` David Hildenbrand
2020-09-09 11:37 ` David Hildenbrand
2020-09-09 11:37 ` David Hildenbrand
2020-09-09 11:37 ` David Hildenbrand
2020-09-09 11:51 ` David Hildenbrand
2020-09-09 11:51 ` David Hildenbrand
2020-09-09 11:51 ` David Hildenbrand
2020-09-09 11:51 ` David Hildenbrand
2020-09-08 20:10 ` [PATCH v2 4/7] mm/memory_hotplug: MEMHP_MERGE_RESOURCE to specify merging of System RAM resources David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` [PATCH v2 5/7] virtio-mem: try to merge system ram resources David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` [PATCH v2 6/7] xen/balloon: " David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-09 5:18 ` Jürgen Groß
2020-09-09 5:18 ` Jürgen Groß
2020-09-09 5:18 ` Jürgen Groß
2020-09-08 20:10 ` [PATCH v2 7/7] hv_balloon: " David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-08 20:10 ` David Hildenbrand
2020-09-09 9:43 ` Wei Liu
2020-09-09 9:43 ` Wei Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eenbry5p.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=akpm@linux-foundation.org \
--cc=anton@ozlabs.org \
--cc=benh@kernel.crashing.org \
--cc=bhe@redhat.com \
--cc=boris.ostrovsky@oracle.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=gor@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=hca@linux.ibm.com \
--cc=jasowang@redhat.com \
--cc=jgg@ziepe.ca \
--cc=jgross@suse.com \
--cc=kernelfans@gmail.com \
--cc=kys@microsoft.com \
--cc=lenb@kernel.org \
--cc=leobras.c@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lpechacek@suse.cz \
--cc=mhocko@suse.com \
--cc=mst@redhat.com \
--cc=nathanl@linux.ibm.com \
--cc=pankaj.gupta.linux@gmail.com \
--cc=paulus@samba.org \
--cc=rjw@rjwysocki.net \
--cc=sstabellini@kernel.org \
--cc=sthemmin@microsoft.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=wei.liu@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.