On Wed, Sep 3, 2014 at 8:59 AM, Alberto Ruiz <aruiz(a)redhat.com> wrote:
On Wed, 2014-09-03 at 07:52 -0400, Josh Boyer wrote:
> On Wed, Sep 3, 2014 at 7:30 AM, Alberto Ruiz <aruiz(a)redhat.com> wrote:
> > Hello everyone
> >
> > I wanted to get some feedback as to whether it would be
> > acceptable/desirable to add whatever available graphics and IO drivers
> > available for the most common hypervisors out there other than
> > KVM/Spice.
> >
> > My idea is that it should be possible to run Fedora Workstation in any
> > desktop virtualization solution out of the box as long as the drivers
> > are acceptable for us in terms of licensing. So VirtualBox is the
> > easiest shot, and a pretty popular one on Windows and Mac users as it's
> > (mostly) FOSS and free of charge, but it'd be nice if we could add
> > others like Parallels or VMWare (I am investigating the
> > availability/licensing situation of those as we speak).
> >
> > I would appreciate any feedback or concerns about this proposal.
>
> We don't allow out-of-tree modules in Fedora. Also, VirtualBox is
> pathologically broken. They refuse to have a stable
> userspace<->kernel ABI so whenever they do a new release it can wind
> up breaking things and requiring a rebuild of everything. Lastly, the
> drivers aren't of great quality to begin with and crash rather often.
> The kernel team has been asked to carry VB before and we refuse to do
> so.
Sure, I understand and concede that VBox does a shitty job wrt their
drivers, but on the other hand it is one of the most popular desktop
virtualization solutions, it is pretty much the only way to test a Linux
desktop OS on top of Windows and Mac that doesn't require a license.
There are other repos that provide it. People are already enabling
those repos for everything else that is highly useful but not provided
by Fedora.
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).
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.
It's also a pretty terrible experience when they do get it to build
and load and it crashes their kernel.
As per the API/ABI stability, that shouldn't be an issue as long
as we
provide it ourselves right?
Um... if you're ignoring the fact that it's crappy and crashes a lot
on it's own even when it is kept up to date that might be somewhat
true. However, with my kernel maintainer hat on, I'm asserting we
aren't going to provide it.
I wasn't aware of the out-of-tree modules, is there somewhere I
can read
about the rationale behind this policy?
http://fedoraproject.org/wiki/Packaging:Guidelines#No_External_Kernel_Mod...
is the guideline, but it's short on rationale.
Briefly, 1) we aren't staffed for it, 2) it encourages crappy behavior
on the part of the module authors by providing disincentive to getting
it upstream, 3) it's a maintenance hassle, 4) we typically already
have alternatives (this is particularly true in the case of virt), 5)
it's yet another entry in an already rapidly expanding test matrix
that has to be checked off (which goes back to item 1), etc etc.
I consider myself to be fairly open to many things. Carrying
virtualbox modules out-of-tree when the authors refuse to even submit
them upstream for review and have no intention of ever doing so is not
one of those things. This is one of the few items where I simply say
no.
josh