Re: [REGRESSION] Re: [PATCH] Revert "vmgenid: emit uevent when VMGENID updates"

[Alexander Graf <graf@amazon.com>]

Hey Jason,

On 29.04.24 11:04, Lennart Poettering wrote:
> 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?


Friendly ping again. We would really like to have a constructive 
technical conversation and collaboration on how to make forward progress 
with VM clone notifications for user space applications that hold unique 
data and hence need to learn about VM clone events, outside of any 
randomness semantics.


Thanks,

Alex





Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597