[RFC] non-KVM graphics/IO drivers in our default install media

[Chris Murphy]

On Sep 3, 2014, at 6:59 AM, Alberto Ruiz <aruiz at redhat.com> wrote:
> 
> To be fair I mostly care about the graphics drivers, I/O is not a big
> deal. The performance/experience of a GL enabled+autoresize guest vs. an
> llvmpipe one is more than noticeable (specially if you're running on
> battery).

Making them easier to install would be nice. But the experience it is to build them manually is on the bottom half of my icky things list. Until just now I haven't even bothered to go looking for it in rpmfusion, but it's there:
http://download1.rpmfusion.org/free/fedora/releases/20/Everything/x86_64/os/repoview/VirtualBox-guest.html

That's ancient. To support F21's Xorg we need to build from VBoxGuestAdditions_4.3.15-95180 which is not available as part of the currently available VirtualBox 4.3.14. But for that matter, VirtualBox doesn't even list Fedora 20 as supported with vbox4.3.14. So it's kinda confusing.


> The problem here is that they don't keep up with Fedora Workstation
> kernels so the user always ends up having to install all the build
> dependencies and run their clumsy .run script and wait for everything to
> be built, installed and then restart the vm. Which is a pretty terrible
> experience.
> 
> As per the API/ABI stability, that shouldn't be an issue as long as we
> provide it ourselves right?
> 
> I wasn't aware of the out-of-tree modules, is there somewhere I can read
> about the rationale behind this policy?

I wouldn't want it to be any other way even if the policy could be changed. Tainted kernels makes kernel testing almost pointless for half wits like myself. And besides it's much simpler for user reporting and developer acceptance of kernel bug reports that clearly indicate a not tainted kernel prior to running into a problem, rather than having to deduce whether tainting is related to the problem. I think the effort is better spent, even if it's a shorter dead end, to find out VirtualBox upstream's rationale for not following proper in-tree development, the same kernel development process their competitors comply with.


Chris Murphy