[vbox-dev] [PATCH] staging: vboxvideo: Add vboxvideo to drivers/staging

[Hans de Goede]

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.thayer at 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