[vbox-dev] Additions: linux/drm: Change vbox_*.c to kernel coding style set 2

[Michael Thayer]

Hello Hans,

Sorry for the long delay.  I am working on too many things in parallel
(though I suspect you have a few too!)

14.06.2017 16:52, Michael Thayer wrote:
> Hello Hans,
> 
> 14.06.2017 15:36, Hans de Goede wrote:
> [Discussion of converting vboxvideo to kernel coding style.]
>> Given Sean Paul's comments on the dri-devel list, I plan to also
>> convert the files which in the staging submission sit under the
>> osindepdent dir to the kernel coding style.
>>
>> If you want I can submit a patch switching the drm code in svn
>> over to use the cleaned-up files rather then the shared ones,
>> that way it will stay relatively close the code going upstream
>> and it should be easier to keep things in sync.
[...]
> I still have to talk to my colleagues to decide what we will do, but a
> patch would certainly be of interest if that doesn't create too much
> effort for you.  Let's at least try to see that we get a good logical
> mapping between the two (not necessarily file for file, but at lease
> function for function and structure for structure).

After talking to my colleagues I decided to keep our driver as it is
(possibly with a compatibility layer analogous to VBoxVideoIPRT.h, but
in reverse this time) as long as I can do that without the difference to
the in-kernel version getting too big.  If I ever feel that the
difference to the in-kernel driver is causing more extra work than we
save through the shared code I will switch to using the code from the
kernel (it would be nice if it stayed under MIT licence) and drop our
dependency on the shared code.

I am curious to know if you have plans for the RHEL kernel (is that an
official way to refer to it?)  Do you plan to keep the version of the
driver there up-to-date with our version or stick to what you was
current when the kernel was released?  Obviously I would prefer keeping
it up-to-date (again, you could save yourself porting time by using our
one, which we test against Red Hat kernels, and in which we will
integrate fixes from the current kernel version).  If not we will
recommend that the user switches to our Additions version.

Regarding your suggestion for providing a script to uninstall
distribution-provided Additions, so far the reaction from other
packagers has not been overwhelming, so I am thinking of going back to
your first suggestion - just making our installer aware of the most
important (as decided by us) distributions which provide Additions and
knowing how to deal with them.  With the added twist that we would not
attempt to install our version on distributions known to keep their
version up-to-date.

[...]

Regards
Michael
-- 
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