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

Alberto Ruiz aruiz at redhat.com
Wed Sep 3 17:28:01 UTC 2014


Okay, fair points overall, perhaps we should look at the problem the
other way around and allow for hypervisors to deploy their drivers/guest
tools in a more user friendly manner without requiring clumsy steps and
building stuff.

Maybe we can work with them ahead of time with them before each Fedora
release and convince them to have their drivers ready for each Fedora
Workstation/Cloud kernel. I used to work with them when at Sun, let's
see if the people I knew are still around...

On Wed, 2014-09-03 at 09:45 -0400, Bill Nottingham wrote:
> Alberto Ruiz (aruiz at redhat.com) said: 
> > 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?
> 
> (Intentionally ignoring the general question about out-of-tree modules to
> address this specific point; I agree with Josh on that issue in general.)
> 
> Not really - given that the ABI required at any point in time is tied to
> VirtualBox's schedule, not Fedora's.
> 
> At any point, upstream VBox can put out a new release requiring a new ABI,
> which would mean that:
> 
> a) any user that upgrades VBox would be broken until Fedora puts out an
>   update for all supported releases to match
> b) any user that hasn't upgraded VBox but upgrades Fedora with the new
>   modules from a) would be broken until they upgrade VBox
> 
> If you have two tightly-coupled components of a shifting ABI, the best
> solution will alway be for users to get both components from the same place,
> not to split them across distribution channels; since we obviously can't
> ship the VirtualBox app, that means the best way to ensure existing vbox
> users is to have them get the modules from vbox.  Shipping the vbox modules
> in Fedora would be optimizing the onboarding experience for some vbox users
> at the expense of the ongoing user experience of using vbox.
> 
> It's a similar situation for why Firefox just started bundling xulrunner.
> 
> Bill
> 
> 
> 
> > 
> > I wasn't aware of the out-of-tree modules, is there somewhere I can read
> > about the rationale behind this policy?
> > 
> > > VMWare and Microsoft actually did things properly for their
> > > hypervisors and got the kernel drivers in the upstream kernel.org
> > > tree.  I believe we already enable them in the Fedora kernels.
> > 
> > Yup, so we're fine for VMWare Fusion/Workstation, and hyper-v doesn't
> > bother me too much from a Workstation POV as it's only available on
> > Windows Server. 
> > 
> > > josh
> > 
> > -- 
> > Greetings,
> > Alberto Ruiz
> > Engineering Manager - Desktop Applications Team
> > Red Hat, Inc.
> > 
> > 
> > 
> > -- 
> > desktop mailing list
> > desktop at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/desktop

-- 
Greetings,
Alberto Ruiz
Engineering Manager - Desktop Applications Team
Red Hat, Inc.





More information about the desktop mailing list