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 _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
