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
