[libvirt] [PATCH] bhyve: add console support through nmdm device

[Roman Bogorodskiy]

  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140317/878a2a24/attachment-0001.sig>