Re: [libvirt] [PATCH] bhyve: add console support through nmdm device
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-vir...
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
Attachments:
- attachment.sig (application/pgp-signature — 488 bytes)