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

[Greg Kroah-Hartman]

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.

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