Hi,
On 09-06-17 12:40, Michael Thayer wrote:
Hello,
09.06.2017 12:21, Hans de Goede wrote:
Hi,
On 09-06-17 12:07, Greg Kroah-Hartman wrote:
On Fri, Jun 09, 2017 at 11:58:31AM +0200, Hans de Goede wrote:
This commit adds the vboxvideo drm/kms driver for the virtual graphics
card used in Virtual Box virtual machines to drivers/staging.
Why drivers/staging? This driver is already being patched into the kernel
by several distros, thus it is good to get this driver upstream soon, so
that work on the driver can be easily shared.
Last time I looked, the user/kernel api was a horrid C++ structure mess,
and I couldn't tease apart the needed pieces to get everything to even
build properly. I'm glad to see this go in, but is that userspace api
going to stay solid? What happens when we find bugs (and odds are,
there are lots of them) with that api?
Note this submission is not the vboxguest driver, which has its own
API (that is next on my todo list) this is just the drm/kms driver which
only uses the standard drm/kms interfaces to userspace and nothing virtual
box specific AFAIK.
I think that Greg is referring to the host kernel modules which implement our
hypervisor. They do indeed require an exact match between driver and
user-space. It does not apply to vboxguest.
Ok.
Sorry if I caused confusion with my:
"Up until now this has never been done because of userspace ABI stability
concerns surrounding the guest drivers. I've been talking to VirtualBox
upstream about mainlining the guest drivers and VirtualBox upstream has
agreed to consider the userspace ABI stable and only extend it in a backwards
compatible manner."
paragraph in the cover letter, that mostly applies to the vboxguest
driver, which still needs a lot of work before I consider it even
ready for staging.
I guess that means I will get to answer your questions from above when I
submit the vboxguest driver. All I can say for now is that we will need to
deal with any userspace ABI bugs in case by case manner, while trying to
maintain backward compatibility wherever possible.
Can I get some signed-off-by from teh virtual box developers here that
they are ok with this work happening?
Michael, can you reply with your S-o-b please ?
I haven't gone through your patch yet, but on the assumption that it matches
what is in our repository plus the white-space changes you sent last night
It matches what is currently in vbox upstream svn + the coding-style
changes I sent + removing all #if LINUX_VERSION_CODE conditionals.
you have my signed-off-by. Is that enough, or would you like me to add it to
the patch?
Replying to this mail with: "Signed-off-by: Michael Thayer
<michael.tha...@oracle.com>"
is enough.
A small comment regarding the Kconfig text - I would appreciate it if it
mentioned why it is recommended to build it as a module - namely, so that the
driver can be upgraded without upgrading the kernel (which makes sense in a
virtual machine, where you often explicitly want to be running older software).
And on the other hand, someone who doesn't need that might also appreciate
knowing that it doesn't apply to them.
Ok I will update the text with a followup patch (or in v2 of this patch
if a v2 is necessary).
Regards,
Hans
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
