On Sat, Mar 15, 2014 at 04:30:01PM +0400, Roman Bogorodskiy wrote:
> nmdm is a FreeBSD driver which allows to create a pair of tty
> devices one of which is passed to the guest and second is used
> by the client.
>
> This patch adds new 'nmdm' character device type and implements
> domainOpenConsole() for bhyve driver based on that.
> static int
> +bhyveBuildConsoleArgStr(const virDomainDef *def, virCommandPtr cmd)
> +{
> +
> + virDomainChrDefPtr chr = NULL;
> +
> + if (!def->nserials)
> + return 0;
> +
> + chr = def->serials[0];
> +
> + if (chr->source.type != VIR_DOMAIN_CHR_TYPE_NMDM) {
> + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> + _("only nmdm console types are supported"));
> + return -1;
> + }
> +
> + /* bhyve supports only two ports: com1 and com2 */
> + if (chr->target.port > 2) {
> + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> + _("only two serial ports are supported"));
> + return -1;
> + }
> +
> + virCommandAddArgList(cmd, "-s", "31,lpc", NULL);
> + virCommandAddArg(cmd, "-l");
> + virCommandAddArgFormat(cmd, "com%d,%s",
> + chr->target.port + 1, chr->source.data.file.path);
So building the argv, the path in the XML is given to the hypervisor
> static int
> +bhyveDomainOpenConsole(virDomainPtr dom,
> + const char *dev_name ATTRIBUTE_UNUSED,
> + virStreamPtr st,
> + unsigned int flags)
> +{
[snip]
> +
> + /* nmdm(4) uses the device pair with naming schema like that:
> + *
> + * nmdm0A, nmdm0B
> + *
> + * So if domain uses nmdm0A, we have to open nmdm0B and vice versa.
> + */
> + c = chr->source.data.file.path[strlen(chr->source.data.file.path) - 1];
> + if (c == 'A')
> + console_path[strlen(console_path) - 1] = 'B';
> + else if (c == 'B')
> + console_path[strlen(console_path) - 1] = 'A';
> + else {
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.
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.
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.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list