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-virtualization 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
Attachment:
pgpCVJq3QglxA.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list