All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-s390@vger.kernel.org, virtualization@lists.linux.dev,
	kvm@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	kexec@lists.infradead.org, "Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Sven Schnelle" <svens@linux.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Vivek Goyal" <vgoyal@redhat.com>,
	"Dave Young" <dyoung@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Janosch Frank" <frankja@linux.ibm.com>,
	"Claudio Imbrenda" <imbrenda@linux.ibm.com>,
	"Eric Farman" <farman@linux.ibm.com>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH v1 07/11] fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel
Date: Fri, 22 Nov 2024 15:51:54 +0800	[thread overview]
Message-ID: <Z0A4Gl1dUINrTTUX@MiWiFi-R3L-srv> (raw)
In-Reply-To: <c353466b-6860-4ca2-a4fa-490648246ddc@redhat.com>

On 11/21/24 at 08:47pm, David Hildenbrand wrote:
> > > 
> > > That would work, but I don't completely like it.
> > > 
> > > (a) I want s390x to select NEED_PROC_VMCORE_DEVICE_RAM instead. Staring at a
> > > bunch of similar cases (git grep "config NEED" | grep Kconfig, git grep
> > > "config ARCH_WANTS" | grep Kconfig), "select" is the common way to do it.
> > > 
> > > So unless there is a pretty good reason, I'll keep
> > > NEED_PROC_VMCORE_DEVICE_RAM as is.
> > 
> > That's easy to satify, see below:
> 
> Yes, this is mostly what I have right now, except
> 
> > 
> > ============simple version=====
> > fs/proc/Kconfig:
> > config NEED_PROC_VMCORE_DEVICE_RAM
> >          def n
> 
> using "bool" here like other code. (I assume you meant "def_bool n", "bool"
> seems to achieve the same thing)

Yes, you are right. I didn't check it carefully.

> 
> > 
...... 
> > ===================
> > fs/proc/Kconfig:
> > config PROVIDE_PROC_VMCORE_DEVICE_RAM
> >          def_bool n
> > 
> > config NEED_PROC_VMCORE_DEVICE_RAM
> >          def_bool n
> > 
> > config PROC_VMCORE_DEVICE_RAM
> >          def_bool y
> >          depends on PROC_VMCORE
> >          depends on NEED_PROC_VMCORE_DEVICE_RAM
> >          depends on PROVIDE_PROC_VMCORE_DEVICE_RAM
> > 
> > drivers/virtio/Kconfig:
> > config VIRTIO_MEM
> >          select PROVIDE_PROC_VMCORE_DEVICE_RAM if PROC_VMCORE
> >                                                ~~~~~~~~~~~~~~
> > 
> > arch/s390/Kconfig:
> > config S390
> >          select NEED_PROC_VMCORE_DEVICE_RAM if PROC_VMCORE
> >                                             ~~~~~~~~~~~~~~
> > ========================
> > 
> > One last thing I haven't got well, If PROC_VMCORE_DEVICE_RAM has had
> > dependency on PROC_VMCORE, can we take off the ' if PROC_VMCORE' when
> > select PROVIDE_PROC_VMCORE_DEVICE_RAM and NEED_PROC_VMCORE_DEVICE_RAM?
> 
> We could; it would mean that in a .config file you would end up with
> "NEED_PROC_VMCORE_DEVICE_RAM=y" with "#PROC_VMCORE" and no notion of
> "PROC_VMCORE_DEVICE_RAM".

Fair enough. I didn't think of this. Then keeping it is obvisouly
better. Thanks.

> 
> I don't particularly like that -- needing something that apparently does not
> exist. Not sure if there is a best practice here, staring at some examples I
> don't seem to find a consistent rule. I can just drop it, not the end of the
> world.
> 
> 
> Did you get to look at the other code changes in this patch set? Your
> feedback would be highly appreciated!

Will try. While I may not have valuable input about virtio-mem code.



  reply	other threads:[~2024-11-22  7:52 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25 15:11 [PATCH v1 00/11] fs/proc/vmcore: kdump support for virtio-mem on s390 David Hildenbrand
2024-10-25 15:11 ` David Hildenbrand
2024-10-25 15:11 ` [PATCH v1 01/11] fs/proc/vmcore: convert vmcore_cb_lock into vmcore_mutex David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-11-15  9:30   ` Baoquan He
2024-11-15 10:03     ` David Hildenbrand
2024-11-20  8:16       ` Baoquan He
2024-11-20  8:56         ` David Hildenbrand
2024-10-25 15:11 ` [PATCH v1 02/11] fs/proc/vmcore: replace vmcoredd_mutex by vmcore_mutex David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-11-15  9:32   ` Baoquan He
2024-11-15 10:04     ` David Hildenbrand
2024-11-20  8:14       ` Baoquan He
2024-10-25 15:11 ` [PATCH v1 03/11] fs/proc/vmcore: disallow vmcore modifications after the vmcore was opened David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-11-22  9:16   ` Baoquan He
2024-11-22  9:30     ` David Hildenbrand
2024-11-25 14:41       ` Baoquan He
2024-11-29 10:38         ` David Hildenbrand
2024-12-03 10:42           ` Baoquan He
2024-12-03 10:51             ` David Hildenbrand
2024-10-25 15:11 ` [PATCH v1 04/11] fs/proc/vmcore: move vmcore definitions from kcore.h to crash_dump.h David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-11-15  9:44   ` Baoquan He
2024-11-15  9:59     ` David Hildenbrand
2024-11-20  9:42       ` Baoquan He
2024-11-20 10:28         ` David Hildenbrand
2024-11-21  4:35           ` Baoquan He
2024-11-21 15:37             ` David Hildenbrand
2024-10-25 15:11 ` [PATCH v1 05/11] fs/proc/vmcore: factor out allocating a vmcore memory node David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-11-20  9:45   ` Baoquan He
2024-10-25 15:11 ` [PATCH v1 06/11] fs/proc/vmcore: factor out freeing a list of vmcore ranges David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-11-20  9:46   ` Baoquan He
2024-10-25 15:11 ` [PATCH v1 07/11] fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-11-20 10:13   ` Baoquan He
2024-11-20 10:48     ` David Hildenbrand
2024-11-20 14:05       ` Baoquan He
2024-11-20 14:39         ` David Hildenbrand
2024-11-21  4:30           ` Baoquan He
2024-11-21 19:47             ` David Hildenbrand
2024-11-22  7:51               ` Baoquan He [this message]
2024-11-22  7:31   ` Baoquan He
2024-11-22  9:47     ` David Hildenbrand
2024-10-25 15:11 ` [PATCH v1 08/11] virtio-mem: mark device ready before registering callbacks in kdump mode David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-10-25 15:11 ` [PATCH v1 09/11] virtio-mem: remember usable region size David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-10-25 15:11 ` [PATCH v1 10/11] virtio-mem: support CONFIG_PROC_VMCORE_DEVICE_RAM David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-10-25 15:11 ` [PATCH v1 11/11] s390/kdump: virtio-mem kdump support (CONFIG_PROC_VMCORE_DEVICE_RAM) David Hildenbrand
2024-10-25 15:11   ` David Hildenbrand
2024-11-04  6:21 ` [PATCH v1 00/11] fs/proc/vmcore: kdump support for virtio-mem on s390 Baoquan He
2024-11-04  6:21   ` Baoquan He
2024-11-15  8:46 ` Baoquan He
2024-11-15  8:55   ` David Hildenbrand
2024-11-15  9:48     ` Baoquan He

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=Z0A4Gl1dUINrTTUX@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=svens@linux.ibm.com \
    --cc=thuth@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.com \
    /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.