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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Jun 13, 2017 at 05:00:15PM +0200, Michael Thayer wrote:
> 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.

Yes, please look at the size, you have 7k lines total for the whole
thing, how many could you possibly be sharing?

7k is really a trivial number of lines for a driver, well under half of
the size of the 8250 UART driver[1], making your driver 1/2 as complex
and difficult to maintain as a serial port driver :)

It's really not that much code at all you are quibbling over here, it
could have all been converted already to the correct format by either
one of us with all of the time we have spent writing emails back and
forth...

And why is the closed vbox-devel list still on the cc: here, the bounces
from it are getting annoying.

thanks,

greg k-h

[1] My standard unit of measurement, I need a short name for it one of
    these days as I use it all the time.