Daniel P. Berrange wrote:
But client apps have to munge the path before opening it. I must say I'm still finding this a little wierd as an XML design.
Looking at the type=pty case, the XML has no path, but is filled in with the path that the client can open - QEMU is just opening /dev/ptmx. If giving QEMU a real TTY, then the XML contains the path that QEMU itself should open and there's nothing a client can open since the client side is a real physical serial cable or linux virtual tty. So no real consistent approach there.
I like the idea of openpty() on client and passing an fd like LXC does. I've submitted a patch to add support for that to bhyve: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=384757+0+current/freebsd-virtua... But I don't know how long that will take to get landed. And then it'll also make some time to be MFC to -STABLE, so I guess it will not be available in a near future.
Looking at this nmdm driver
+ * <serial type="nmdm"> + * <source path="/dev/nmdm0A"/> + * <target port="1"> + * </serial>
We could just go with the device prefix eg
<source path='/dev/nmdm0'/>
and let clients append 'B' before opening the device and append 'A' on bhyve command line. That feels like it is exposing the FreBSD private impl in the XML though. ie if some other OS implemented a similar nmdm concept, we can't guarantee they'd pick A & B as device names.
Yeah. And it not only exposes internals, but looks strange from user's point of view: I guess it could be not obvious for a user that he needs to specify some device name that will never exist.
So I wonder if we should just include both paths ? eg
<source deva='/dev/nmdm0A' devb='/dev/nmdm0B'/>
and declare that whatever is in 'deva' side is the hypervisor's dev and 'devb' is the client's path.
The FreeBSD driver would sanity check to make sure both devices match up though.
That's the only way not to expose internals, I think. And actually this way of expressing devices doesn't require it to be nmdm at all, it could be pty devices created with 'socat -d -d pty,raw,echo=0 pty,raw,echo=0' (or some similar tool), but I'm not sure how to add a general validation that these devices match. Roman Bogorodskiy