Re: RFC: towards systemd socket activation in q-s-d

[Daniel P . Berrangé]

On Tue, Jan 31, 2023 at 12:17:07PM +0100, Kevin Wolf wrote:
> Am 30.01.2023 um 15:58 hat Daniel P. Berrangé geschrieben:
> > > I'm at a point where I can take a shot at implementing this, but want
> > > some feedback on whether it is better to try to shoehorn a generic
> > > solution into the existing @fd member of the SocketAddressType union,
> > > or whether it would be better to add yet another union member
> > > @systemd-fd or some similar name to make it explicit when a command
> > > line parameter wants to refer to an fd being passed through systemd
> > > socket activation LISTEN_FDS and friends.
> > 
> > I don't think we should change SocketAddress at all, just use the
> > @fd member that already exists, by fixing its semantics to always
> > take an alphanumeric FD name and deprecate the use of pure numeric
> > FD numbers.
> 
> So you're suggesting that socket activation FDs automagically show up as
> named FDs in QEMU?

Yep.

> It's just a gut feeling, but it feels a bit like one of those convenient
> shortcuts that we later regretted. So far named FDs are those that the
> user explicitly created using QMP. Implicitly adding in additional ones
> from another source might be trying to treat two different things the
> same - you could even consider them being from two different namespaces.
> 
> This is why I would have considered a new SocketAddress variant the safe
> default.

I would say that both 'getfd' and 'LISTEN_FDS' are explicitly controlled
by the user who owns the QEMU process. The former case the user has to
talk QMP, the latter case the user has to configure systemd units (or
an compatible impl). In both cases the user gets a free choice overing
the names associated with the FDs, though systemd gives some default
naming if the user doesn't specify a choice themselves.

> > Currently the socket code has an annoying structural connection
> > to the monitor code, because the monitor is tracking the passed
> > in FDs.
> 
> Do we intend socket activation FDs do work with the same operations as
> named FDs created with 'getfd'? In particular, I suppose 'closefd' would
> still make sense, and referring to the FD should work in the same way,
> too. This might be an argument in favour of treating it as a named FD
> like you suggest, because then the only different thing about it is that
> it magically shows up with a name coming from systemd rather than QMP.

Yeah, closefd and anything else that consumes thue result of 'getfd'
ought to continue to work.

> > It would be nice to separate this by introducing some dedicated
> > APIs for handling named FDs. The monitor can feed named FDs into
> > this from getfd, and the CLI can feed named FDS into this from
> > activation.   The socket code can then use these named FD handling
> > APIs and thus isolate/detach itself from the monitor.
> 
> That structure would make sense to me, even without adding socket
> activation.
> 
> Do we have places where we would potentially use the file descriptor in
> other ways than referring to it in a SocketAddress(Legacy)? If we do,
> then covering socket activation at the file descriptor level is pretty
> much a requirement.

getfd works in combination with socket FDs and thus SocketAddress.

We also have the add-fd QMP command which passes in file/block/char
based FDs that populate the /dev/fdset/NN  namespace, and thus used
by qemu_open().  Socket activation wouldn't overlap with this, since
as its name suggests the passed FDs are only targetting stream based
FDs, aka sockets or named FIFOs.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|