From: Gerd Hoffmann <kraxel@redhat.com>
To: Claudio Fontana <cfontana@suse.de>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Christian Schoenebeck" <qemu_oss@crudebyte.com>,
"Greg Kurz" <groug@kaod.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"José Ricardo Ziviani" <jose.ziviani@suse.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PATCH 0/4] modules: add support for target-specific modules.
Date: Thu, 17 Jun 2021 11:48:11 +0200 [thread overview]
Message-ID: <20210617094811.gatatv7vla2rxqgc@sirius.home.kraxel.org> (raw)
In-Reply-To: <2be72be7-5c3f-e25d-fb84-cf58b573bf27@suse.de>
Hi,
> Do we need to be able to unload modules that we previously loaded? Or is this not a realistic requirement?
Surely doable, but it's work and needs infrastructure we don't have
right now. We must be able to unregister everything modules can
register, which is only partly the case today. We need usage counters
so we can figure whenever a module is in use or not. Maybe more.
I don't see a use case justifying that work.
The linux kernel can unload modules (when enabled at build time), and
pretty much the only reason I've ever used that is device driver
development: test new driver version without reboot (as long as you
don't make a mistake which Oopses the kernel ...).
take care,
Gerd
next prev parent reply other threads:[~2021-06-17 10:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 10:15 [PATCH 0/4] modules: add support for target-specific modules Gerd Hoffmann
2021-06-10 10:15 ` [PATCH 1/4] modules: factor out arch check Gerd Hoffmann
2021-06-10 10:15 ` [PATCH 2/4] modules: check arch on qom lookup Gerd Hoffmann
2021-06-10 10:15 ` [PATCH 3/4] modules: target-specific module build infrastructure Gerd Hoffmann
2021-06-10 10:15 ` [PATCH 4/4] modules: build virtio-9p modular Gerd Hoffmann
2021-06-10 10:34 ` [PATCH 0/4] modules: add support for target-specific modules Claudio Fontana
2021-06-10 12:23 ` Gerd Hoffmann
2021-06-10 13:10 ` Gerd Hoffmann
2021-06-10 13:12 ` Claudio Fontana
2021-06-11 7:35 ` Paolo Bonzini
2021-06-11 8:29 ` Gerd Hoffmann
2021-06-11 13:03 ` Gerd Hoffmann
2021-06-11 13:17 ` Claudio Fontana
2021-06-14 22:19 ` José Ricardo Ziviani
2021-06-15 5:09 ` Gerd Hoffmann
2021-06-15 15:48 ` José Ricardo Ziviani
2021-06-16 9:28 ` Gerd Hoffmann
2021-06-16 12:23 ` Claudio Fontana
2021-06-17 5:37 ` Gerd Hoffmann
2021-06-17 7:48 ` Claudio Fontana
2021-06-17 9:48 ` Gerd Hoffmann [this message]
2021-06-17 10:07 ` Claudio Fontana
2021-06-11 17:14 ` Paolo Bonzini
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=20210617094811.gatatv7vla2rxqgc@sirius.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=cfontana@suse.de \
--cc=f4bug@amsat.org \
--cc=groug@kaod.org \
--cc=jose.ziviani@suse.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.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.