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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
