[PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

[Michael Thayer]

13.06.2017 15:59, Greg Kroah-Hartman wrote:
> On Tue, Jun 13, 2017 at 03:45:14PM +0200, Michael Thayer wrote:
>> 13.06.2017 14:48, Greg Kroah-Hartman wrote:
>> [Discussion of vboxvideo coding style.]
>>> Once your code is accepted into the main kernel tree, why would you
>>> continue to work in an out-of-tree repo anyway?  That's ripe for
>>> disaster, what's keeping you from just working with the in-tree version?
>>
>> One of our use cases is customers running older operating systems,
>> including legacy Linux distributions.  However those customers would
>> still like the most up-to-date guest drivers possible without updating
>> the kernel.  Updating drivers without updating the kernel is not a
>> scenario of interest to upstream kernel developers, which is why we will
>> continue to maintain the out-of-tree repository (which is actually the
>> VirtualBox repository, where the OS-independent code is shared with
>> drivers for other platforms).  The end result is not unlike what Red Hat
>> does when it does back-ports to its stable kernels.
> 
> When Red Hat backports upstream drivers to older kernels, they do not do
> so in a way that is a different coding style or anything like that.
> They take the existing code, apply some rules and modifications to it,
> and complete the backport.  Some drivers can be done "automagically"
> using some good transformation tools that people have developed.
> 
> In fact, its even easier to do this if the code is upstream.  Just keep
> a local copy of the latest upstream version, with a "linux_backport.h"
> type file to handle the api changes.  Lots of people do that, and I
> myself did it for many years while working on different driver
> subsystems that had to ship in older kernels.
> 
> Here's one example of this type of a file that I helped work on:
> 	https://github.com/gregkh/greybus/blob/master/kernel_ver.h
> that covered 5-6 different driver subsystems having to track all kernel
> versions from 3.10 to the latest 4.9 release (at that point in time, the
> code got merged upstream.)
> 
> Feel free to copy the same idea for your code, if it's applicable, other
> drivers do this for their "customers" as well.
> 
> Note, none of this requires "os abstractions" on the upstream code at
> all, nor does it require a different coding style at all, that would
> just hinder development and cause massive problems when trying to
> determine what changed upstream.

The reason we have OS abstraction is that we share code between drivers
for different platforms.  There is always going to be code in a driver -
mainly the actual programming of the hardware - which needs to work the
same way on different platforms, but which is not likely to be shared
with other drivers on the same platform.  I personally think that this
is a sensible thing to do, and a discussion that is worth having, in
this case how to reap the benefits (for Linux too) of sharing among
platforms without imposing significant costs on the Linux kernel; but I
do agree that this driver is too small to be worth having a long
argument about.

Regards
Michael

> This isn't the first time we've done this, some of us have a bit of
> experience in operating system development :)
> 
> thanks,
> 
> greg k-h
> 
-- 
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