On 09/14/15 11:22, Ian Campbell wrote: > On Fri, 2015-09-11 at 17:28 +0200, Laszlo Ersek wrote: >> > [...] >> For me that's not so clear-cut. OVMF is frequently used as a UEFI >> development environment (it's better to brick a virtual machine than >> your physical dev platform...) > > One flip side to this is that people often virtualize in order to continue > running their older platforms and applications, because upgrading them > would be difficult for whatever reason. > > There's an obvious tension between that and the desire to use OVMF as a > development platform, but it seems to me that the developers are the ones > who can more readily be expected to mess with the defaults.
Good points! >> , so upstream should embrace new UEFI >> features reasonably early, unless there are *grave* regressions. >> >> One example I named was the properties table feature (new in UEFI-2.5). >> It would break Windows 7. Given the large number of users running >> Windows 7 on OVMF (mainly for GPU passthrough), such a regression would >> be serious. >> >> Breaking Debian Wheezy's and BITS's GRUB is also bad, but the former is >> very old (and has a clear upgrade path) > > Debian Wheezy is not very old, it's only a year older than RHEL7 (May 2013 > vs June 2014) and only a bit older than two years in absolute terms. It is > also the subject of an LTS effort, which extends its lifetime to 2018. (*) > For comparison Windows 7 (which you argue regressing would be serious) was > released in 2009 and there have been two major Windows releases since then. (**) > Given that and with consideration between the desire to run older platforms > vs. a development environment it seems to me that Debian Wheezy has not yet > reached the threshold for being ignored or for saying to users "you must > now upgrade". I believe I could argue against both (*) and (**), but it would not be productive. :) Instead, what matters is the (now) clear, significant user demand for turning off PcdSetNxForStack by default. I'll send a followup patch for my series to that end. And, sorry about the inconvenience the regression may have caused, of course ;) Thanks! Laszlo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
