Add support to devel/libhyve-remote. (VNC Server)
AbandonedPublic
Actions

Authored by araujo on Jul 28 2017, 4:14 AM.

Details

Reviewers

tychon
jhb
jceel
gnn
bcr
rgrimes

Group Reviewers

manpages
bhyve

Summary

The libhyve-remote aims to abstract functionalities from other third party libraries such like libvncserver, freerdp and spice to be used in hypervisor implementation. With a basic data structure it is easy to implement any remote desktop protocol without dig into the protocol specification or third part libraries, you can check some of our examples.

We don't static link any third party library, instead we use dynamic linker and we load only functionalities that we believe is necessary to launch the service.

Our target is to abstract functionalities from libvncserver, freerdp and spice. Right now libhyve-remote only supports libvncserver. It is possible to launch a vnc server with different screen resolution as well as with authentication.

With this patch we implement support to bhyve use libhyve-remote that basically abstract some functionalities from libvncserver.
We can:

Enable wait state.
Enable authentication.
Enable different resolutions.
Have a better compression.

Also we add a new flag to be called with -s that is vncserver, if the libhyve-remote library is not present in the system we fallback to bhyve RFB implementation, ex.:
-s 2,fbuf,tcp=0.0.0.0:5937,w=800,h=600,password=1234567,vncserver,wait

Test Plan

Tested with (guests):

Windows10.
Fedora Workstation.
FreeBSD12.

Tested with VNC (clients):

RealVNC.
net/tigervnc.
net/tightvnc.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 10737
Build 11134: arc lint + arc unit

Event Timeline

araujo created this revision.Jul 28 2017, 4:14 AM

Herald added a subscriber: imp. · View Herald TranscriptJul 28 2017, 4:14 AM

Harbormaster completed remote builds in B10722: Diff 31295.Jul 28 2017, 4:14 AM

araujo edited the summary of this revision. (Show Details)Jul 28 2017, 4:21 AM

araujo edited the test plan for this revision. (Show Details)

araujo added reviewers: grehan, tychon, jhb.

araujo added a reviewer: jceel.Jul 28 2017, 4:25 AM

Update manpage.

Herald added a reviewer: manpages. · View Herald TranscriptJul 28 2017, 4:35 AM

araujo retitled this revision from Add support to devel/libhyve-remote. to Add support to devel/libhyve-remote. (VNC Server).Jul 28 2017, 4:36 AM

gnn accepted this revision.Jul 28 2017, 8:38 AM

This revision is now accepted and ready to land.Jul 28 2017, 8:38 AM

Small comment on the man page change.

usr.sbin/bhyve/bhyve.8
197	... provides a VNC server. or ... provides the VNC server.

Address @bcr change request.

This revision now requires review to proceed.Jul 29 2017, 3:26 AM

Harbormaster completed remote builds in B10737: Diff 31330.Jul 29 2017, 3:26 AM

OK from manpages. Thanks!

This revision is now accepted and ready to land.Jul 29 2017, 10:12 AM

I'm looking at this now. I think there will need to be some changes in the mechanics for this, and also the abstraction. I'll write up something longer with more detail.

On naming - the term "vnc" was explicitly avoided in bhyve since much of the display code could be used with any remote protocol.

This revision now requires changes to proceed.Jul 29 2017, 6:29 PM

Some high-level comments:

the shared library interface is a bit fragile, since it searches for only symbol names and seems to imply a copy of an internal data structure (the vncserver_softc struct). A better approach would be something like bhyveload, where there is a single struct that contains a version and function pointers. That should be exported to a header file (along with any other structs used in the api) and go somewhere like <bhyve/extvnc.h> or similar.
the 'enable_http' function isn't used and maybe should be removed.
the frame-buffer differencing engine has been copy-pasted into vncserver.c. A better approach might be to make the existing rfb code an implementation of the function pointers, and allow an override to an external shared library on the command line (perhaps named to allow alternate ones). The differencing engine would then just call a function pointer, allowing a single copy of the code to be used.
the hard-coded path to the ports shared library should at the minimum be a #define, and better, extracted from the command line.

There are some unnecessary style changes that create additional extraneous diffs - these should be removed.

comphuse7_gmail.com added a subscriber: comphuse7_gmail.com.Jul 12 2018, 9:03 AM

Herald added a reviewer: rgrimes. · View Herald TranscriptJul 12 2018, 9:03 AM

rgrimes added a reviewer: bhyve.Jul 12 2018, 3:00 PM

rgrimes removed a reviewer: grehan.Feb 20 2019, 6:09 PM

This revision is now accepted and ready to land.Feb 20 2019, 6:09 PM

araujo abandoned this revision.Feb 22 2019, 5:06 AM