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

Hans de Goede hdegoede at redhat.com
Mon Jun 26 16:20:06 GMT 2017


On 15-06-17 12:29, Michael Thayer wrote:
> 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 understand your concerns, I've been discussing this with my manager
and the plan is for me to start working on this, so that I can get a
feeling how much work this will actually be and then we will see from



More information about the vbox-dev mailing list