From: Lennart Poettering <mzxreary@0pointer.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Alexander Graf <graf@amazon.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Babis Chalios <bchalios@amazon.es>, Theodore Ts'o <tytso@mit.edu>,
"Cali, Marco" <xmarcalx@amazon.co.uk>,
Arnd Bergmann <arnd@arndb.de>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
Christian Brauner <brauner@kernel.org>,
linux@leemhuis.info, regressions@lists.linux.dev
Subject: Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID updates"
Date: Mon, 29 Apr 2024 11:04:21 +0200 [thread overview]
Message-ID: <Zi9ilaX3254KL3Pp@gardel-login> (raw)
In-Reply-To: <Ziujox51oPzZmwzA@zx2c4.com>
On Fr, 26.04.24 14:52, Jason A. Donenfeld (Jason@zx2c4.com) wrote:
> I don't think adding UAPI to an individual device driver like this
Does vmgenid really qualify as "an individual device driver"? It's a
pretty generic software interface, implemented by various different
VMMs these days. It is also the only interface I am aware of that
actually exists and would provide the concept right now?
if this was really hyperv specific, then I'd agree it's just an
"individual device driver". But it's widely implemented, for example a
trivial command line switch in qemu.
Hence, for something this generic, and widely deployed with multiple
backend implementations I think we can say it's kinda more of a
subsystem and less of an individual driver, no?
> is a good approach especially considering that the virtio changes we
> discussed some time ago will likely augment this and create another
> means of a similar notification. And given that this intersects with
> other userspace-oriented work I hope to get back to pretty soon, I
> think introducing some adhoc mechanism like this adds clutter and
> isn't the ideal way forward.
If one day a virtio-based equivalent shows up, then I'd be entirely
fine with supporting this in userspace directly too , because virtio
too is a generic thing typically implemented by multiple VMM
backends. From my userspace perspective I see little benefit in the
kernel abstracting over vmgenid and virtio-genid (if that ever
materializes), as a systemd person I am not asking for this kind of
abstraction (in case anyone wonders). A generic ACPI device such as
vmgenid is entirely enough of "generic" for me.
The way we would process the event in userspace in systemd (from a
udev rule) is so generic that it's trivial to match against two
generic interfaces, instead of just one.
And even if there's value in a generic abstraction provided by the
kernel over both vmgenid and a future virtio-based thing: the kernel
patch in question was a *single* line, and our hookup in userspace
could easily be moved over when the day comes, because it's really not
a rocket science level interface. It's a single parameterless event,
how much easier could things get?
I understand that how this all happened wasn't to everyones wishes,
but do we really have to make all of this so complex if it could just
be so simple? Why delay this further, why go back again given the
event, the interface itself is such an utter triviality? Do we really
make such a threatre around a single line change, a single additional
uevent, just because of politics?
Lennart
--
Lennart Poettering, Berlin
next prev parent reply other threads:[~2024-04-29 9:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 11:48 [PATCH] Revert "vmgenid: emit uevent when VMGENID updates" Jason A. Donenfeld
2024-04-18 12:46 ` Greg Kroah-Hartman
2024-04-22 7:51 ` [REGRESSION] " Alexander Graf
2024-04-23 1:21 ` Jason A. Donenfeld
2024-04-23 6:56 ` Alexander Graf
2024-04-23 12:23 ` Lennart Poettering
2024-04-26 11:33 ` Alexander Graf
2024-04-26 12:52 ` Jason A. Donenfeld
2024-04-26 13:43 ` Babis Chalios
2024-04-26 20:05 ` Alexander Graf
2024-04-29 9:04 ` Lennart Poettering [this message]
2024-05-03 10:14 ` Babis Chalios
2024-04-26 14:20 ` Linux regression tracking (Thorsten Leemhuis)
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=Zi9ilaX3254KL3Pp@gardel-login \
--to=mzxreary@0pointer.de \
--cc=Jason@zx2c4.com \
--cc=arnd@arndb.de \
--cc=bchalios@amazon.es \
--cc=brauner@kernel.org \
--cc=graf@amazon.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=regressions@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=xmarcalx@amazon.co.uk \
/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.