Re: RFC: virtualbox tainting.

Josh Boyer
2011-10-07T18:10:24Z

On Fri, Oct 7, 2011 at 12:22 PM, <Valdis.Kletnieks@vt.edu> wrote:
> On Fri, 07 Oct 2011 11:16:13 EDT, Josh Boyer said:
>> In all seriousness, is there a reason these modules haven't been
>> submitted to the staging tree?  Perhaps this was attempted in the past
>> and I'm just not finding references to it.
>
> I haven't actually checked what the churn rate of the kernel side of VirtualBox is, but
> there *is* some benefit if you have a package that includes both userspace and kernel
> code, to keep them in sync.

I haven't checked either, which is why I asked Frank directly since
I'm assuming he has ;).

> Currently, VirtualBox is at 4.1.4.  Now, if they decide they need to change/fix/extend
> the API for some reason, they can just ship a 4.1.6 and be happy.  If the code is
> in-tree, then they are basically stuck with the API - they can't ship a 4.1.6 that can
> get away with assuming that all the kernel API is there.  So you have to carry around
> workarounds and test-for-features code and all that stuff.

Yeah, I'm familiar with that line of reasoning. It can be beneficial
to vbox itself, but then we have situations like this where users are
picking up that single-source package and trying to run it on distros
that change kernel versions rather frequently and that doesn't seem to
benefit anyone. The users are left with a buggy machine/vbox
instance, the distributions are left with unhappy users, and vbox is
left with unhappy users AND unhappy distribution maintainers.
(Somehow the distributions get the brunt of the blame from the users,
but I'm not going to go down that path. I'm trying to be productive.)

> I don't know - maybe the Oracle crew think the API is stable enough now that they can
> afford to do that.  But Frank would probably be the one to speak to how in/out of tree
> would affect their development/support methodology.

Yes. Which is why I asked Frank :).

josh