[vbox-dev] [PATCH] Fix for Guest "OS type" future-compatibility
klaus.espenlaub at oracle.com
Fri Jun 26 13:13:38 UTC 2015
On 26.06.2015 14:51, Alexey Eromenko wrote:
> I would like to have this patch evaluated, and possibly included into v5.0.
I see absolutely no urgency. This patch (or hopefully a better variant
of it, I already said that I'm not keen on silent data loss) can be done
at any time, e.g. when a truly workable solution for the guest OS type
handling has been devised. Doing it now is simply a hack, at a time
where we can't spend the necessary care on finding a proper solution for
this non-trivial issue.
> Why ? Because this is a pre-requirement for unattended installs.
Your solution to unattended install requires a level of guest OS
distinction which makes our current design explode. However, that's the
opposite of a justification for making hasty changes.
> And it will allow unattended VM to be run, if users later downgrade
> from VirtualBox 6.0 to 5.0.
> my potential plan is this:
> VBox A supports unattended Fedora 20/21/22
> VBox A+1 supports unattended Fedora 22/23/24 (removes previous Fedora support)
> VBox A+2 supports unattended Fedora 24/25/26 (removes previous Fedora support)
It's a separate questions which guest OS versions are supported for
unattended installation, but if that pattern would be applied to what
guest OSes are generally included in the official list, it's a terrible
idea. I will veto removal of guest OS types, because it can have
consequences which are hard to predict, e.g. for API clients.
> So this patch will allow to add or remove various OS type support at will.
> And it will allow future OSes to be run on VirtualBox 5.0.0, without
> changes (VBox downgrade).
No, it does NOT achieve this goal in a maintainable way. Dropping
unattended install support for no longer relevant OSes is a topic to
discuss later, once we see how much maintenance burden it brings.
First we need a sustainable design behind guest OS type handling, and
then we can evaluate the options (in 5.0 we have more, and we'll add
more as time passes) of making the necessary changes.
> As for CPU instructions, I think if the host CPU supports them, it
> should be enabled/passed on to the guest.
Talking is cheap. Sorry if that sounds rude, but it's Oracle which would
have to take the consequences of "make all instructions available to the
guest", and in this case it would mean months of work, delaying 5.0
without a visible advantage for the entire user base.
More information about the vbox-dev