[vbox-dev] vboxguest [Was: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging]

[Michael Thayer]

Hello Hans,

Continuing this in a new thread without all the other recipients.

14.06.2017 17:03, Hans de Goede wrote:
> Hi,
>
> On 14-06-17 15:40, Michael Thayer wrote:
>> Hello Hans,
>>
>> 14.06.2017 15:30, Hans de Goede wrote:
>> [Discussion of vboxvideo and vboxguest driver clean-up.]
>>> As I already mentioned in previous mails on this, for the vboxguest
>>> driver
>>> my plan is to simply do a fork and remove anything related to the
>>> portability. It currently weighs in at 100000+ lines of code which is
>>> a bit
>>> much for what it does I believe I will be able to get a Linux only
>>> version
>>> of it down to a small fraction of that and the result will be a much
>>> cleaner
>>> and better driver.
>>>
>>> FWIW I've already stared looking into cleaning up the vboxguest
>>> driver and
>>> my first target is to remove all dependencies on the r0drv code.

I have been thinking about this again.  As I said before, this is your
decision to make, but I wonder whether getting vboxguest into the
upstream kernel is the most sensible approach to take, and for that
matter the best use of your time.  I do realise that Red Hat have a
policy of trying to keep their kernels (the Fedora ones at least) as
close to upstream as possible, but I presume that exceptions are
possible.  It seems to me that you are likely to expend quite a bit of
effort integrating our changes into an in-kernel version of vboxguest
with the result that most distributions will still end up with an
outdated version which needs replacing by our one.

I have been discussing Additions packaging in Debian in a different
thread on vbox-dev with Gianfranco Costamagna, who maintains the Debian
and Ubuntu Additions packages.  It seems to me that focussing on
distributions (in your case Fedora and Red Hat EL) having up-to-date
Additions versions would be a better time investment than putting
vboxguest in the kernel, and time spent rewriting it to reduce size
spent looking for ways to clean up our version (for me that is
upstream).  While that will not be as easy as with vboxvideo, which was
written from the start with a view to keeping dependencies on the rest
of VirtualBox low, there are probably still low-hanging fruit: vboxguest
is not something that one person has consistently developed, but rather
something that lots of people on the team have worked on briefly, often
as part of a larger set of work.  And of course, we would be open to
reducing dependencies where possible (possibly also something like the
compatibility header we did for vboxvideo), and towards making the
Additions easier to package.

Regarding keeping distributions up-to-date with Additions, it seems to
me that the kernels move so fast in in-support versions of Fedora that
just building the most recent version of the kernel modules whenever the
kernel is updated (possibly even as part of the kernel package) would
make sense.  EL on the other hand is slower moving and has its regularly
updated module ABI, so a separate Additions module package, updated when
we release a new version or when the kernel ABI is bumped might be
appropriate.

So as I said, just my thoughts - sorry for the length! - but do think
whether it might make sense for you.

Regards
Michael

>> Moving off-topic, but please let me know if you set up a git repository
>> for it as you did for vboxvideo.
>
> Will do.
>
>> Do you have plans (applies to
>> vboxvideo too) for how to merge changes to our code into the cleaned-up
>> code?
>
> The git repo will have an "upstream" branch which will contain the
> vboxguest
> dir from the tarbal created by the src/VBox/Additions/linux/export_modules
> script. My plan is to sync that branch regularly by coping over a fresh
> copy of that dir, then commit that as a commit on top of the previous
> sync and look at the git diff to see what changed. Then where necessary
> I will port over the changes to the cleaned up version.
>
>>Of course, I am open to patches or suggestions as to how to
>> simplify the code in our repository as long as they do not affect other
>> platforms (vboxguest builds and runs for five different operating system
>> kernels).
>>
>> Regards
>> Michael
>>
>>> Regards,
>>>
>>> Hans
>>
-- 
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