|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v13 17/17] net: stream: add QAPI events to report connection state
On Mon, 24 Oct 2022 13:00:09 +0200
Markus Armbruster <armbru@xxxxxxxxxx> wrote:
> Markus Armbruster <armbru@xxxxxxxxxx> writes:
>
> > Cc: Stefano Brivio
> >
> > Laurent Vivier <lvivier@xxxxxxxxxx> writes:
> >
> >> On 10/21/22 07:48, Markus Armbruster wrote:
> >>> Laurent Vivier <lvivier@xxxxxxxxxx> writes:
> >>>
> >>>> The netdev reports NETDEV_STREAM_CONNECTED event when the backend
> >>>> is connected, and NETDEV_STREAM_DISCONNECTED when it is disconnected.
> >>>
> >>> Use cases?
> >>
> >> This is asked by Stefano Brivio to allow libvirt to detect if connection
> >> to passt is lost and to restart passt.
>
> [...]
>
> >>> Could similar event signalling be useful for other kinds of netdev
> >>> backends?
> >>
> >> I was wondering, but it becomes more complicated to be generic.
> >
> > Making something complicated and generic where a simpler special
> > solution would do is the worst.
> >
> > Not quite as bad (but still plenty bad) is making a few special
> > solutions first, then replace them all with a generic solution.
> >
> > I believe we should have a good, hard think on possible applications of
> > a generic solution now.
> >
> > There is no need to hold back this series for that.
> >
> > If we conclude a generic solution is called for, we better replace this
> > special solution before it becomes ABI. Either by replacing it before
> > we release it, or by keeping it unstable until we replace it.
>
> Stefano, any thoughts on this?
Actually, to me, it already looks as generic as it can be: stream
back-ends are the only ones connecting and disconnecting.
I quickly tried to think about possible, similar events for other
back-ends:
- user: handled by libslirp, there's no connection, and probably not
much we can or want to export from libslirp itself
- tap, bridge: the closest equivalent would be interfaces changing
states, but that's something that's also externally observable with a
netlink socket, in case one needs to know. And in any case, it's
logically very different from a connection or disconnection. If we
want events for that, they should have different names
- vhost-user, vde: we could implement something similar if the need
arises, but it should logically have a different name
- l2tpv3: stateless, same as datagram-oriented socket. No states, no
events to report, I guess.
All in all, to me, NETDEV_STREAM_{,DIS}CONNECTED events here don't look
very "special" or hackish.
--
Stefano
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |