[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Replace GSource with AioContext for chardev
From: |
Paolo Bonzini |
Subject: |
Re: Replace GSource with AioContext for chardev |
Date: |
Tue, 14 Apr 2020 12:54:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
On 14/04/20 12:27, Daniel P. Berrangé wrote:
> Ignoring back compat, what would be our ideal CLI syntax ?
>
> Current syntax is
>
> -chardev socket,id=charnet1,path=/tmp/vhost1.sock
> -netdev vhost-user,chardev=charnet1,id=hostnet1
>
> Should we have an option that expresses a "SocketAddress" struct on the
> CLI ?
>
> -socket type=unix,path=/tmp/vhost1.sock,id=sock0
> -netdev vhost-user,socket=sock0,id=hostnet1
I think this should be just a "-object socket" that under the covers
creates a QIOChannel. There are also ideas of switching "-chardev" to
"-object"; we could do the reverse of Marc-André's suggestion, and have
"chardev=" take both a "chardev-foo" object or a QIOChannel object
(converting the latter to a socket-based chardev).
IOW, the new "-object socket" QOM type can act as both a chardev or a
QIOChannel factory. The C side of that should not be hard.
Paolo
> IIUC, Marc-André is suggesting that we carry on using -chardev, but
> detect when it is a socket chardev, and then ignore chardev APIs and
> create a QIOChannel. I can see some appeal in this as it provides a
> way to get all existing usage switched over, but I feel uneasy about
> sticking with -chardev forever, if we're not actually using a chardev.
>
> We could do the magic -chardev -> -socket conversion though, for a
> short period of time to ease the transition.
>
> We would have to
>
> 1. Introduce the new -socket and add "socket=$id" to devices that need it
> 2. Deprecate -chardev with type != socket, with no repacement intended
> 3. Deprecate -chardev with type == socket, translating to -socket
> ...wait 2 releases...
> 4. Delete support for "chardev=$id" from devices with "socket=$id"
>
> The hardest part is probably deciding exactly which set of devices can
> be restricted to only sockets, and which must have the full range of
> chardev backends available.
>
> Regards,
> Daniel
>