On Wed, Sep 3, 2014 at 8:59 AM, Alberto Ruiz <aruiz@xxxxxxxxxx> 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@xxxxxxxxxx> 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_Modules 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 -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
