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

[Kevin Wolf <kwolf@redhat.com>]

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?

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.

> 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.

> 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.

Kevin