[vbox-dev] [PATCH] Fix for Guest "OS type" future-compatibility

[Klaus Espenlaub]

Alexey,

On 26.06.2015 14:51, Alexey Eromenko wrote:
> so...
> 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.

Klaus

> -Technologov