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 >
