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.
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 you have my signed-off-by. Is that enough, or would you like
me to add it to the patch?
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.
Regards and thanks
Michael
Regards,
Hans--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
